- Il est désormais possible d’exécuter et d’orchestrer plusieurs threads d’agent en parallèle dans une même fenêtre, et la nouvelle barre latérale Threads permet de contrôler pour chaque thread la portée d’accès aux dossiers et aux dépôts tout en visualisant leur état d’exécution au même endroit
- Il est possible de combiner différents agents selon les threads, un même thread peut lire et écrire à travers plusieurs projets et dépôts, et, si nécessaire, une isolation par worktree peut aussi être appliquée thread par thread
- La disposition par défaut a aussi été réorganisée autour de la barre latérale Threads : Threads et l’Agent Panel se trouvent à gauche, tandis que le Project Panel et le Git Panel ont été déplacés à droite ; les utilisateurs existants peuvent activer cette disposition en opt-in
- Plutôt que de tout déléguer à l’IA ou de l’exclure complètement, l’accent est mis sur la façon de travailler en intervenant directement sur le code combinée aux outils d’IA pour construire des systèmes fiables et bien conçus
- La fonctionnalité est disponible immédiatement dans la dernière version de Zed et, avec un environnement à 120 fps, une architecture permettant de choisir son agent et une publication en open source, elle renforce le flux de travail permettant de gérer de gros volumes de travail d’agents dans une seule fenêtre
Fonctionnalité d’agents parallèles
- Zed permet désormais d’exécuter et d’orchestrer plusieurs agents en parallèle dans une même fenêtre
- La fonctionnalité Parallel Agents permet d’exploiter plusieurs threads simultanément
- La nouvelle barre latérale Threads permet de contrôler précisément les dossiers et dépôts auxquels chaque thread peut accéder
- Il est possible de surveiller tous les threads en cours d’exécution depuis un seul endroit
- Cette fonctionnalité fonctionne dans l’environnement 120 fps de Zed, permet d’utiliser l’agent de son choix et l’ensemble est publié en open source
De nombreux threads, une seule fenêtre
- La barre latérale Threads regroupe tous les threads par projet, ce qui facilite la gestion simultanée de plusieurs tâches d’agents
- Il est possible d’utiliser une combinaison d’agents différents selon les threads
- La sélection au niveau du thread est possible selon l’approche choose your agent
- Il est possible de travailler à travers plusieurs projets, et un même thread d’agent peut lire et écrire sur plusieurs dépôts
- Si nécessaire, une isolation par worktree peut être appliquée, avec un réglage défini thread par thread
- Depuis la barre latérale, il est possible d’exécuter immédiatement les opérations courantes comme arrêter un thread, l’archiver ou lancer un nouveau thread
- Même dans des flux complexes où plusieurs agents s’exécutent simultanément sur plusieurs projets, la barre latérale permet de garder facilement le travail organisé
Une nouvelle disposition par défaut
- Comme la barre latérale Threads devient le centre de la navigation dans les projets, l’agencement des panneaux a lui aussi été revu
- Threads est ancré à gauche par défaut, à côté de l’Agent Panel
- Le Project Panel et le Git Panel ont été déplacés à droite
- Cette disposition a été conçue pour mieux convenir à l’agentic work et permet de garder les threads d’agent au premier plan même lorsqu’on change de thread
- Si vous préférez une autre disposition, vous pouvez modifier la position d’ancrage en faisant un clic droit sur l’icône du panneau dans la barre inférieure, et l’ajuster aussi dans le Settings Editor
- Les utilisateurs existants peuvent adopter cette nouvelle disposition en opt-in
- Même si vous êtes habitué à l’ancienne disposition, il est possible que la nouvelle vous paraisse plus naturelle si vous l’essayez avant de revenir en arrière
La combinaison de l’agent et de l’éditeur
- Les façons d’utiliser l’IA peuvent aller vers des extrêmes, mais une manière de travailler qui utilise l’IA tout en gardant une implication directe dans le code convient mieux à la création de logiciels de haute qualité
- À une extrémité, il y a fully giving into the vibes
- À l’autre extrémité, il y a disabling all AI features
- La contribution d’un ingénieur logiciel ne devrait pas se mesurer au nombre de lignes de code générées, mais à la capacité à produire des systèmes fiables, bien conçus et faciles à faire évoluer
- L’agentic engineering, présenté en 2025, s’impose comme une manière de créer de meilleurs logiciels en combinant le savoir-faire humain et les outils d’IA
- software craftsmanship in the era of vibes
- Le terme se diffuse plus largement ces derniers temps
- term grow in popularity
- Les agents parallèles de Zed ont été conçus autour de ce principe, avec pour objectif d’améliorer l’expérience du travail d’agents à grande échelle
- L’équipe a testé le système pendant plusieurs jours avec des centaines de threads actifs et a mené de nombreuses itérations UX ainsi que de longues discussions internes afin d’éliminer les aspérités que les développeurs pourraient ne pas voir
- Le développement a pris plus de temps et le processus n’a pas été simple, mais le résultat permet de confier aux agents des tâches plus exigeantes sans sacrifier le craft
Pour commencer
- Parallel Agents est disponible dans la dernière version de Zed
- La barre latérale Threads peut être ouverte via l’icône en bas à gauche
- Elle peut aussi être ouverte via un raccourci clavier : sur macOS,
option-cmd-j, et sur Linux et Windows,ctrl-option-j
1 commentaires
Commentaires Hacker News
Plus j’utilise ce workflow, plus je l’apprécie. Le vrai game changer, c’est (a) de faire tourner des threads parallèles par worktree, et (b) d’avoir assez de hooks de cycle de vie pour les gérer presque comme des VM
Dans mon cas, quand je crée un worktree, je copie les fichiers de config locaux, et Postgres duplique les bases dev/test pour permettre des tests isolés. Quand je ferme le worktree, la base est supprimée aussi
Jusqu’ici, Conductor était ce que j’avais trouvé de mieux, mais au travail je suis obligé d’utiliser Copilot et le backend est imposé sur Claude/Codex, donc je ne peux pas l’utiliser. Arbor est similaire, mais le développement y est moins actif et il reste pas mal de rough edges, et l’interface graphique d’Opencode a bien un create hook mais pas de teardown
Si Zed relie aussi cette partie tout en conservant son identité de bon éditeur, je pense vraiment que ça peut changer la donne
On est en train d’ajouter davantage d’agents, et les demandes de prise en charge de Copilot et du harness OpenCode reviennent particulièrement souvent
On a aussi ajouté récemment une porte de sortie. Si vous activez Settings → Experimental → Big Terminal Mode, vous pouvez créer un nouveau terminal dans le panneau central (⌘⇧T) et utiliser l’agent de votre choix, comme Copilot ou OpenCode. Il manque encore des choses comme les notifications, donc l’expérience n’est pas encore totalement aboutie, mais ça permet d’utiliser le harness voulu en attendant l’UI officielle
Vous pouvez toujours envoyer vos retours à charlie@conductor.build
Il suffit de créer un nouveau git worktree, de copier le
.envlocal ou d’autres fichiers de config, puis de renseigner pour chaque worktree des ports et variables sans conflit. C’est surtout pour éviter les collisions sur localhost, et on peut aussi résoudre ça avec DockerOn peut aussi prévoir un script de teardown pour nettoyer le worktree après fusion dans main, et pour les tests automatisés j’utilise aussi un port de debug Chrome et un répertoire temporaire de user data différents pour chaque worktree
Du coup, je ne vois pas très bien pourquoi il faudrait une bibliothèque ou un outil dédié
https://www.visualjj.com/learn/parallel-ai-agents
Cette extension a des hooks before create / before destroy, donc on peut y mettre ce qu’on veut. De mon côté, je symlinke le fichier workspace du checkout principal, j’installe les packages et je copie aussi quelques fichiers. C’est assez pratique
Si besoin, il permet aussi une isolation par VM pour chaque worktree
https://github.com/ouijit/ouijit
Il semble clair que tout le monde se dirige maintenant vers les agents parallèles et les worktrees, donc ça m’a surpris que Zed sorte ça. Jusqu’ici, l’éditeur était vraiment au centre et l’IA restait strictement optionnelle
La force de Zed, c’est d’être indépendant de l’agent, de créer automatiquement des worktrees par dépôt pour pouvoir gérer plusieurs repositories avec un seul agent, et d’offrir une UI d’agent de grande qualité plutôt qu’un simple habillage autour d’une CLI. À ma connaissance, c’est le premier grand outil à réunir cette combinaison
Je la branche sur logfire pour voir la télémétrie, et l’impact est énorme quand il s’agit d’optimisation ou de diagnostic de bugs. Il n’y a pas encore non plus de plugins ni de skills
En revanche, le fait de pouvoir changer facilement de provider est appréciable
Le nouveau layout par défaut va exactement à l’opposé de ce que je veux
Pour moi, l’ordre devrait être arborescence du projet | éditeur de texte | vue agent | threads
Sur la plupart des laptops, on ne voit correctement que deux panneaux, et au lieu de mettre en avant un workflow à quatre panneaux, ils devraient plutôt se concentrer sur une gestion des panneaux et un changement de vue plus simples. Sauf en ultra-large, il vaudrait mieux mettre Agents dans une fenêtre séparée
J’utilise beaucoup Zed et c’est un détail configurable, mais ça me gêne parce que ça ressemble à une décision de conception assez symbolique. J’ai peur qu’ils finissent par juger l’édition moins importante et par reléguer aussi la prise en charge du mode VI
Quand on regarde le changelog, on a l’impression qu’en ce moment la plupart des efforts vont vers la partie agent, et ça m’inquiète. Si j’aime Zed, c’est parce que c’est un bon éditeur qui connaît un peu les agents, pas parce que j’ai envie qu’il pivote de plus en plus vers la gestion d’agents
Cela dit, je ne pense pas qu’ils vont la supprimer tout de suite
Pour ma part, j’évite délibérément les agents parallèles. La dette cognitive devient trop lourde, et il faut souvent réorienter en permanence l’agent pendant le travail pour qu’il reste sur une trajectoire structurellement cohérente
Les tâches complexes demandent généralement de laisser ouverte la sortie de thinking et d’interrompre ou de guider en cours de route. Sinon, le résultat est souvent mauvais et difficile à corriger, et c’est encore plus compliqué quand il faut en plus surveiller des processus parallèles
En ce moment, je traite un seul changement à la fois et je garde ce rythme jusqu’à pouvoir merger en toute confiance
À un moment, le cerveau commence juste à envoyer le signal « commit et passe à autre chose », et je dois résister à cette tentation
Je n’aime pas trop que le layout par défaut repousse le code et l’arborescence des fichiers pour faire de la place aux outils d’IA
J’adore Zed et je l’utilise tous les jours, mais si j’avais vu ce layout à la première installation, je ne l’aurais probablement pas pris au sérieux
Je pense que ça peut clairement rebuter une partie des nouveaux utilisateurs
La plupart des autres outils qui font quelque chose de similaire sont lourds, bogués et basés sur Electron
Il faut faire un clic droit sur la petite icône de panneau dans la barre du bas pour choisir la position du dock, et le clic gauche sert à afficher/masquer le panneau
Déjà maintenant, j’affiche en même temps agent, editor, files/git, et si on y ajoute un quatrième panneau, ça devient vraiment étouffant à basse résolution. J’ai bien un écran 4K, mais j’avais l’habitude d’avoir l’éditeur sur une moitié et une autre fenêtre, comme le navigateur, sur l’autre, donc ce flux où l’éditeur doit être en plein écran continue à me gêner un peu
Bien sûr, ce n’est qu’un layout par défaut, et Zed a probablement aussi un moyen de le modifier. Si on pouvait disposer les panneaux comme dans les IDE JetBrains — haut gauche / bas gauche / bas droite / haut droite — et les masquer ou afficher d’un coup, on pourrait par exemple mettre les fichiers en haut à gauche, l’agent en bas à gauche, et garder le centre principalement pour l’éditeur
Je préfère une application de style codex où l’on regroupe plusieurs projets au même endroit et où l’on peut faire du context switching sans fin
Sur macOS, ⌘B sert toujours à basculer le dock de gauche et ⌘R celui de droite
Quand on active le nouveau layout, un panneau qui était à gauche passe par exemple à droite, donc je pense quand même l’essayer pour un usage de développement plus traditionnel. On peut changer la position de dock de chaque panneau dans les paramètres
Pour moi, les agents parallèles sont l’exception, pas la règle. C’est peut-être moi le problème, mais dans ce genre de situation exceptionnelle, ouvrir quelques terminaux de plus me suffit largement
Je ne sais pas si ça doit vraiment devenir le workflow principal. Mon cerveau fonctionne mieux quand il peut creuser un seul problème en profondeur
Plus que l’exécution parallèle elle-même, ce qui compte vraiment pour moi, c’est de pouvoir passer facilement d’un thread à l’autre. Ça permet d’explorer des recherches annexes dans un thread voisin sans perturber le contexte principal d’édition
Par exemple, préparer une première ébauche de changements avant de commencer à éditer, ou checkout une branche et configurer le code avant la revue
J’ai essayé Zed et j’ai eu l’impression qu’il pouvait tout à fait devenir mon éditeur principal, mais le manque d’extensions m’a laissé sur ma faim. Il manquait des petites améliorations QoL comme TODO highlight ou TabOut, le déplacement vers un numéro de ligne n’était pas aussi simple que dans VSCode, et le filtre d’onglets mentionné dans un autre commentaire m’a aussi manqué
Et le fait de ne pas pouvoir régler la taille de police dans l’éditeur de message de commit git m’a paru bizarre
Parmi les ajouts récents, l’intégration des dev containers était vraiment excellente
Je soutiens Zed
L’UI d’agent de Zed est la plus déroutante que j’aie vue. Les icônes sont petites et ambiguës, et quand on clique sur x, parfois ça ferme l’éditeur, parfois l’agent, parfois le panneau, donc il est difficile de prévoir le résultat
J’ai voulu le réessayer à cause des nouvelles fonctionnalités, mais à cause de ce comportement imprévisible, j’ai fini par le désinstaller. En plus, opencode Go, auquel je suis abonné, n’est pas pris en charge
Warp a sorti quelque chose de similaire il y a environ une semaine, mais de mon point de vue, l’implémentation de Zed est plus logique
Ça me donne envie de redonner sa chance à Zed. J’ai cette démangeaison mensuelle du genre « et si j’essayais ce terminal / cet IDE cette fois-ci ? »
C’est peut-être simplement que je n’ai pas encore vraiment dépassé la courbe d’apprentissage, ou alors que c’est encore proche de l’alpha et que ça change souvent
La fonctionnalité Parallel agents semble conçue autour de git worktree ou de projets locaux, mais j’ai l’impression que le mode projet local brouille justement l’essentiel
Dans mon flux de développement quotidien, je suis déjà passé complètement aux workspaces jj, donc tant que Zed ne prend pas en charge jj, je n’utiliserai pas cette fonctionnalité
En plus, avec ce changement, le layout s’est retrouvé modifié de façon inattendue, et pour l’instant je ne vois même pas bien comment revenir à l’état précédent