Agents de codage parallèles avec des worktrees Git, Conductor et Antigravity 2.0

De la manipulation de terminaux à un système visuel d’organisation

Si 2025 a été l’année de l’agent IA, 2026 semble être l’année où de nombreux agents travaillent ensemble, et un ingénieur de Google avait prédit dès le début que ce serait l’année de l’orchestration des agents. Les problèmes apparaissent rapidement pour quiconque travaille exclusivement dans des terminaux. Essayer de coordonner une équipe de sous-agents travaillant en parallèle pour créer un petit jeu de montre, en utilisant des fenêtres tmux, des téléchargements de dépôts et des post-it sur l’écran pour se rappeler quelle tâche était en cours, s’est avéré être un véritable chaos cognitif.

La photo montre plusieurs bureaux macOS remplis de terminaux agy avec des post-it, ce qui donne une bonne idée de ce à quoi ressemble la gestion d’espaces de travail d’agents en parallèle sans outils adéquats.

L’idée de créer des applications à l’aide d’un système multi-agents provient d’une publication de juin 2026 montrant comment une seule instruction générait quatre agents développeurs en parallèle, permettant de produire une application fonctionnelle en moins de deux minutes. Les assistants CLI spécialisés sont utiles pour les tâches à thread unique, mais plusieurs flux d’agents concurrents, chacun disposant de sa propre branche, de son mécanisme de vérification et de son boucle de feedback, ne peuvent pas être gérés par un buffer de rappel plat. C’est pourquoi l’étape suivante a été de passer à l’application de bureau Antigravity 2.0.

L’application regroupe tout par projet, en quelque sorte comme un dossier, et affiche les threads sous chacun d’eux, du plus récent au plus ancien. Un projet personnel peut contenir un thread pour ajouter un bouton de connexion bleu avec un mot de passe caché, ainsi qu’un autre pour ajouter une route backend /checkout/ ; quant à un projet professionnel, il comprend des threads pour écrire doc/PRD.md et ajouter des tests de sécurité. Les threads peuvent être archivés, ce qui permet de les conserver après un redémarrage, et plus personne n’a besoin de notes adhésives physiques.

Lorsqu’un environnement visuel fonctionne, la question suivante concerne l’échelle. Un environnement de test isolé et un jeu simpliste sont faciles à gérer. Cette configuration permet d’étendre l’application de bureau à une simulation SRE à 12 pistes, en utilisant des worktrees Git, un orchestrateur inspiré de Rails nommé Conductor++ et un agent de conciergerie appelé Agostina.

L’illustration montre un développeur qui tente de garder sous contrôle une pile d’agents secondaires de worktree, un panettone à la main.

Le prompt qui a déclenché tout cela

L’inspiration provenait d’un prompt concis visant à créer une application de réservation de chambres d’hôtel avec une petite équipe d’agents.

Let's build a hotel room booking app [..].

First, launch the Engineering Manager agent to ... into an artifact called 'architecture.md'.

Once the design is ready, launch three agents in parallel:
1. Test Manager: Write <SPECS> to 'architecture.md'.
2. Backend Engineer: Build an API based on <SPECS> .
3. Frontend Engineer: Build a web UI based on <SPECS>  to interact with the API <details>.

[..] How to sync the 3 sub-agents [..]

Finally, spin up both components and a browser so I can test the live app.

En le lisant attentivement, on peut voir ce qu’il contient :

1. une description du produit souhaité, ici une application de réservation d’hôtels
2. une équipe de trois sous-agents
3. l’ordre et le moment de leur interaction
4. ce qui se passe à la fin, lorsque le système est mis en marche pour qu’une personne non directement impliquée l’examine
5. la chose la plus importante : un état de fichier partagé, à savoir l’artefact commun architecture.md

Le diagramme montre comment les agents interagissent dans cet exemple. Il s’agit de programmation métaprogrammative à l’état pur. L’instruction ne décrit pas le code, mais plutôt l’équipe qui le rédigera. De plus, les agents communiquent entre eux via un artefact Markdown, ce qui signifie que les spécifications elles-mêmes constituent le canal de communication.

La liste de souhaits concernant une configuration parallèle allait encore plus loin : une mise en œuvre déclenchée par les GitHub Issues (GHI), de sorte que chaque sous-agent reçoit un ticket réel.

Éléments du flux de travail

Plusieurs composants forment cette configuration.

• Intégration des problèmes. Chaque sous-agent devrait travailler sur un problème lorsqu’un tel problème existe.
• Rails pour l’IA. L’extension Conductor fournit aux agents des « rails », c’est-à-dire des limites bien définies. Un simple problème ne suffit pas toujours pour que l’agent agisse, et parfois une personne intervenant dans le processus (HITL) doit répondre aux questions difficiles, ce qui empêche les mises en œuvre de devenir négligentes, comme par exemple en affirmant « bien sûr, je voulais parler uniquement des utilisateurs authentifiés ».

git worktree. Les worktrees empêchent deux ou plusieurs agents de détériorer le même répertoire. Lorsque N agents soumettent des demandes de pull sur des branches distantes, il est également judicieux d’avoir un agent git chargé de résoudre les conflits et d’intégrer le code dans la branche principale. Ce rôle doit être prudent. Alors que l’agent X tente de déployer la fonctionnalité X, cet agent gardien reste imperturbable, constituant la dernière ligne de défense pour assurer la cohérence, car le code peut être correct mais être déployé sans que des tests ne soient exécutés ni que le journal des modifications ne soit mis à jour, et une nouvelle fenêtre de contexte permet de le détecter facilement.

Afin de réutiliser cette configuration dans différents projets, les règles et l’automatisation ont été intégrées dans une compétence d’agent open source, conductor-worktree-hitl, surnommée condutree. Ses composants principaux sont :

• git worktree pour une mise en œuvre asynchrone, avec un sous-agent par worktree et une piste Conductor.

GitHub Issues associé à Conductor pour définir des limites d’implémentation précises

Antigravity 2.0 en tant que système visuel de gestion

l’état est stocké sur disque, de sorte que le contexte de l’agent est conservé entre les exécutions ; compatible avec Conductor, mais ajoute un état basé sur des fichiers pour le lien entre les problèmes ainsi qu’un cadre expérimental de questions-réponses pour les sous-agents

optionnellement, un plugin fournissant la compétence using-git-worktrees pour automatiser l’isolation des worktrees

Il existe trois raisons pour laquelle cette compétence est présentée comme une compétence externe, plutôt que d’insérer des commandes git dans la invite du coordinateur. Premièrement, cela regroupe toute la configuration de base du espace de travail, les liens symboliques et les exclusions git dans un seul script facile à maintenir. Deuxièmement, l’invite du coordinateur reste concise et axée sur la délégation de tâches aux sous-agents et sur la résolution des questions, ce qui permet à l’agent d’éviter de se confronter à la syntaxe git. Troisièmement, d’autres développeurs peuvent intégrer cette compétence dans leurs propres répertoires sans avoir à réécrire les scripts d’intégration, ce qui leur permet de lancer des exécutions parallèles sans conflit.

Un agent doté de cette compétence apprend quatre choses :

1. comment obtenir des arbres de travail indépendants pour des tâches simultanées
2. les bonnes pratiques git, notamment le création de liens symboliques vers les dossiers de métadonnées partagés de Conductor et leur exclusion localement afin que git status reste propre
3. un protocole HITL réentrant double permettant d’afficher des commentaires sur les problèmes, de lire les registres locaux et de demander des réponses sans épuiser la quota API
4. comment effectuer des commits localement et enregistrer les validations sous forme de notes Git, sans push direct vers le serveur distant

La version 1.0 constitue une base solide, et une version 2.0 est prévue avec des liens de configuration automatiques et des scripts d’aide plus complets.

Cette illustration générée par l’IA joue sur l’idée de « trop de cuisiniers dans la cuisine » : une foule de sous-agents de codage qui créent le chaos dans une branche en l’absence d’isolation des arbres de travail.

Test de charge : un simulateur d’incidents SRE

Afin de voir jusqu’où l’exécution parallèle peut être poussée, le modèle a été appliqué à un simulateur réaliste d’automatisation SRE et de gestion d’incidents. L’objectif n’était pas des applications de démonstration, mais un système multi-agents capable d’auditer les environnements cloud et de coordonner la gestion des incidents dans plusieurs espaces de travail isolés en même temps. Avant que cela ne fonctionne sans conflits, il fallait résoudre certains problèmes liés à l’organisation des fichiers Git et à leur nommage.

• Pollution par des liens symboliques. Dans la configuration Conductor++, chaque agent parallèle dispose de son propre arbre de travail, par exemple .worktrees/telegram_incident_creation/. Comme les sous-agents renvoient des métadonnées au coordinateur, le répertoire racine conductor/ est lié symboliquement dans chaque arbre de travail à l’aide de ln -s ../../conductor conductor. Tout, sauf ce répertoire, diffère d’un arbre de travail à l’autre, et comme chaque suivi se trouve dans sa propre sous-dossier conductor, les problèmes de fusion sont très peu probables.
• La coordinatrice. La principale gestionnaire git s’appelle Agostina, une Italienne calme et organisée qui fonctionne comme une véritable machine à espresso ; elle maintient en synchronisation des subagents tels que Mario et Luigi sans qu’ils ne se gênent mutuellement. Elle est italienne exprès, et son nom ressemble un peu à Antigravity.
• Le scribe. Un agent dévoué nommé Amanuense, d’après le mot latin désignant un scribe, enregistre la création de dossiers, les modifications de code ainsi que les interactions entre agents, avec des horodatages précis, dans un fichier d’audit central, afin de savoir qui a fait quoi, quand et dans quel arbre de travail. Ce fichier a été créé pour vérifier l’efficacité de la synchronisation des subagents et pour fournir des horodatages et des journaux factuels pour les rapports.

Exécuter plusieurs agents IA sur un même répertoire exige une isolation stricte ainsi qu’un moyen de communication exempt de conflits.

Ici, Agostina résout les fusionnements provenant de Mario et Luigi, tandis qu’un troisième sous-agent jaune continue de travailler dans son propre arbre de travail.

Règles qui maintiennent le dépôt en bon état

Plusieurs décisions de conception ont eu un impact majeur.

• Aucun push direct vers le serveur distant. Si de nombreux sous-agents exécutent git push en même temps, cela provoque des conflits de verrouillage sur les références distantes et peut introduire du code non testé en production. Les sous-agents ne font des commits que sur les branches locales feature/ et écrivent des notes git récapitulatives. Seul le coordinateur peut effectuer des pushes, récupérer la branche de validation et fusionner les branches fonctionnelles.
• Protocole de questions réentrentes double. Un seul fichier questions.json global provoquerait des conflits d’écriture lorsque les sous-agents posent des questions en même temps. Au lieu de cela, chaque sous-agent enregistre sa question dans son dossier de suivi privé (conductor/tracks//metadata.json), ce qui évite complètement ces conflits. Il publie également la question en tant que commentaire dans un issue GitHub, accompagné d’une signature de suivi unique. Le script de sondage d’Agostina vérifie d’abord si un dossier local a le statut awaiting_human. S’il n’y en a pas, l’appel à l’API GitHub est complètement omis, ce qui permet d’économiser plus de 95 % de la quota allouée. Lorsqu’une réponse correspondante apparaît sur GitHub, le métadonnée local passe en état answered, ce qui déclenche l’activation du sous-agent.
• Une mémoire partagée de type wiki. Plutôt que de remplir le contexte de chaque sous-agent avec toute l’histoire du projet, le répertoire partagé conductor/ agit comme une mémoire persistante, un répertoire local structuré que les agents lisent et écrivent comme une page wiki. Cela fait écho à une idée bien connue d’Andrej Karpathy concernant la mémoire des LLM, et cela répond à l’inquiétude récurrente selon laquelle une mémoire d’agent mal gérée transforme les assistants en poissons rouges.
• Résolution en cascade des conflits. Lorsque les branches fonctionnelles terminées sont fusionnées une par une, une cascade de conflits peut survenir. La branche de Mario se fusionne sans problème dans la branche de validation, mais celle de Luigi présente des conflits. Si un humain résout les conflits de Luigi sur la branche de validation, la branche fonctionnelle originale de Luigi dans son arbre de travail reste conflictuelle et obsolète. Pour éviter cette dérive, Agostina sélectionne manuellement les corrections ou fusionne la résolution directement dans la branche de Luigi, afin que l’arbre de travail isolé reste en accord avec le code validé.
• Utiliser des demandes de pull plutôt que de faire des pushes vers main. Faire un push directement de la branche de validation fusionnée vers main permettrait de contourner les contrôles de revue, c’est pourquoi l’intégration s’effectue via une PR. Les subagents font des commits localement, Agostina fait des pulls, valide et fusionne localement, et une fois que les tests d’intégration sont réussis, elle fait un push de la branche unifiée et exécute gh pr create --title "feat: ..." --body "...". Un examinateur humain peut alors examiner les différences et les vérifications CI dans l’interface propre de GitHub. Agostina enregistre l’URL de la PR dans metadata.json du registre et affiche l’état en temps réel à l’aide de gh pr list et gh pr status.
• Terminaison en raison de conflits conceptuels. Deux pistes peuvent être logiquement incompatibles, par exemple l’une implémentant une fonctionnalité que l’autre refactore d’une manière incompatible. Si Agostina le détecte, elle peut immédiatement mettre fin à l’un des sous-agents en conflit. La annulation doit être consignée dans le dossier de cet agent, et ce dossier doit être bloqué ou lié au dossier de l’autre agent afin de conserver une trace décisionnelle claire. Cela ne s’est produit qu’une seule fois.

Le cycle de vie de l’orchestration

L’opérateur humain ne communique jamais directement avec les sous-agents. Ceux-ci fonctionnent en totale isolation au sein de leurs arbres de travail, et la personne ne s’adresse qu’au coordinateur à deux moments : au lancement de l’exécution et pour répondre aux questions transmises par l’observateur HITL.

Le diagramme de flux montre le cycle de vie de l’agent et des sous-agents en six étapes :

1. Lancement. L’opérateur démarre l’exécution.
2. Statut de lecture. Agostina audite les problèmes actifs sur GitHub ainsi que les états des pistes dans Conductor.
3. Mise en place. Elle crée des arbres de travail isolés et génère des sous-agents développeurs en parallèle.
4. Surveillant HITL. Les questions bloquées par les sous-agents sont acheminées vers l’humain, et les réponses lui sont renvoyées, ce qui maintient le cycle de feedback sécurisé et asynchrone.
5. Nettoyage. Lorsque les sous-agents terminent leur travail et ouvrent leurs PR, Agostina supprime les dossiers temporaires des arbres de travail.
6. Fusion vers main. Elle intègre les modifications et ouvre ou fusionne le PR final, avant de revenir au nettoyage pour tout travail restant. Cela peut devenir chaotique, mais les agents gèrent mieux les fusions Git que les humains.

La réponse aux questions reste fortement expérimentale, et trois approches ont été testées. L’une consiste en un pont Telegram sidecar qui fonctionne en tant que daemon en arrière-plan, envoie les questions ou les approbations de modification de base de données au téléphone du développeur via un bot Telegram, et vérifie l’arrivée des réponses.

Le diagramme montre le flux asynchrone via Telegram. Ses avantages sont une réponse et des approbations optimisées pour les appareils mobiles, un parallélisme sans conflits car les questions sont stockées dans des dossiers par voie, ce qui évite les conflits de verrouillage de fichiers, ainsi qu’une trace d’audit, puisque chaque décision est conservée dans le répertoire sous forme de JSON. La méthode la plus simple, qui consistait à communiquer avec l’agent principal via questions.json, a été abandonnée car elle ne débloquait jamais automatiquement et devait être déclenchée manuellement, bien que des hooks ou des mises à jour futures puissent y remédier.

Étude de cas : douze voies SRE en cinq heures

Le banc d’essai était une application web conçue autour d’une extension SRE. Une grande partie de ses fonctions pouvait être exécutée en parallèle : écrans UI, points de terminaison backend, un assistant de chat alimenté par un LLM, un bot Telegram, l’instrumentation OpenTelemetry ainsi que la découverte des ressources GCP.

Cette opération a fait appel à douze capacités SRE complexes, qui ont été divisées en plus de vingt problèmes concrets sur GitHub. Ensuite, le système a été lancé. En environ cinq heures, principalement sans supervision, le pipeline Conductor++ a construit, testé et fusionné l’ensemble de ces éléments dans la branche principale. Le périmètre couvrait tout, de l’installation du suivi OpenTelemetry dans Cloud Run à la création d’assistants interactifs Telegram pour les incidents et de registres permettant d’approuver les mutations en attente.

Résultats de l’intégration et de la fusion

Grâce à l’orchestration du travail en parallèle, chaque voie de développement a été créée, testée et intégrée dans main.

L’image du tableau présente l’audit de l’état final des pistes principales. Huit pistes opérationnelles supplémentaires ont également été intégrées, couvrant la taxonomie des états des incidents, la suppression et l’archivage des incidents, les liens croisés entre projets wiki, la gestion de l’état dans plusieurs environnements, le transfert de l’état vers le cloud, une interface utilisateur responsive pour le wiki, des connecteurs en temps réel vers GCP ainsi que les mutations en attente.

Deux semaines après l’exécution, on peut vérifier l’état de Conductor à l’aide d’une seule commande task-runner qui lance l’inspecteur sur le répertoire et affiche un résumé de l’espace de travail.

$ just conductor-status
python3 conductor/bin/conductor-inspector . --open --short

🔍 Inspecting Conductor Workspace: /usr/local/google/home/ricc/git/adk-sre-benjamin
📦 Product: Initial Concept
STATUS      |  PROGRESS  | RATIO |  GHI  |   AGENT    |   CHANGED   | TRACK ID                                           |  🌳
==============================================================================================================================
NEW         | ░░░░░░░░░░ |  0/25 |  #23  |            |  💻 15days   | managed_agents_sandbox_20260616                    |
NOT_READY   | ░░░░░░░░░░ |  0/17 |  #22  |            |  💻 15days   | mcp_streamline_abilities_20260616                  |
NOT_READY   | ░░░░░░░░░░ |  0/11 |  #15  |            |  💻 15days   | migrate_tf_cb_logic_20260616                       |
NOT_READY   | ░░░░░░░░░░ |   0/9 |  #21  |            |  💻 15days   | ai_engineering_practices_20260616                  |
NOT_READY   | ░░░░░░░░░░ |   0/9 |  #19  |            |  💻 15days   | workspace_agent_installation_20260616              |
NEW         | ░░░░░░░░░░ |  0/15 |  #31  | antigravity|  🐙 16days   | disable_mock_fallback_dev_20260616                 |
==============================================================================================================================
TOTAL       |            |  0/86 |       |            |              | 0 completed, 6 open (6 total)                      | 0 🌳

Le calendrier du flux de travail

Une présentation étape par étape du déroulement montre comment le coordinateur, le scribe et les sous-agents parallèles ont évité de se gêner mutuellement.

Étape 1 : initialisation des pistes et des arbres de travail

Sur l’ordinateur hôte, le coordinateur principal a préparé les espaces de travail. L’interface CLI de l’inspecteur Conductor a ensuite listé les pistes actives et les a transmises à des sous-agents désignés, l’un s’occupant des salles de guerre Discord et l’autre des mutations en attente. Un indicateur regroupant toutes les pistes permet à l’outil même d’afficher les branches et les statuts des agents pour chaque espace de travail parallèle.

./scripts/conductor-inspector /Users/ricc/git/adk-sre-benjamin --all

Voici la sortie du terminal enregistrée lors de l’initialisation.

================================================================================
  CONDUCTOR++ ACTIVE WORKTREES & TRACKS INSPECTION
================================================================================
[Track: telegram_incident_creation_20260603]
  Worktree: .worktrees/issue-29-telegram-wizard
  Branch:   feature/issue-29
  Agent:    pinocchio
  Status:   AWAITING_HUMAN (Question: "Verify Telegram Token config?")
  GHI URL:  https://github.com/palladius/adk-sre-benjamin/issues/29

[Track: unified_incident_lifecycle_observability_20260607]
  Worktree: .worktrees/issue-18-discord-warrooms
  Branch:   feature/issue-18
  Agent:    grazia
  Status:   RUNNING
  GHI URL:  https://github.com/palladius/adk-sre-benjamin/issues/18
================================================================================

Dans cette liste, le sous-agent chargé des mutations en attente est bloqué, en attendant une réponse de HITL.

Une question naturelle est de savoir si les problèmes GitHub et les pistes Conductor sont la même chose. Il s’agit de deux systèmes de stockage qui peuvent présenter des écarts. Un agent a été chargé de détecter ces écarts entre les deux.

L’aperçu affiché montre la vue d’ensemble de l’inspecteur concernant les worktrees actifs, les branches et les affectations de sous-agents. Réconcilier les deux systèmes ne nécessite qu’une instruction dans un sens ou dans l’autre. L’une consiste à demander à Conductor de créer une nouvelle piste pour chaque problème, en posant toutes les questions nécessaires une piste à la fois. L’autre consiste à s’assurer qu’il existe un problème pour chaque piste Conductor.

La vue détaillée montre une question de HITL en attente de réponse concernant les problèmes GitHub.

Étape 2 : isolation des worktrees parallèles

Chaque agent a travaillé sur sa propre branche, et le scribe a enregistré les modifications de fichiers ainsi que les événements de l’espace de travail avec aucune conflit.

Cette capture montre l’outil de suivi des fichiers du worktree pendant le développement concurrentiel.

Le suiveur de threads Antigravity affiche les tâches en cours, un spectacle qui aurait impressionné la démonstration originale à une seule commande et quatre sous-agents.

Étape 3 : sondage et direction humaine

Lorsque les agents avaient besoin de précisions, ils publiaient des problèmes que un script de sondage, poll_ghi_questions.py, analysait. Afin que la direction humaine soit compatible avec les appareils mobiles, les questions étaient transmises via le pont Telegram sidecar. L’opérateur n’avait pas besoin de rester devant un ordinateur pour consulter GitHub, car le pont envoyait chaque question sur un téléphone afin d’obtenir des approbations rapides en déplacement.

L’image d’écran montre en action le cycle de feedback relatif aux approbations et aux diagnostics.

Étape 4 : l’état final vert

Après que chaque branche fonctionnelle eut été validée et fusionnée dans l’ordre, Agostina a ouvert la demande de fusion, et l’audit final a confirmé que les douze pistes SRE avaient toutes été intégrées à la branche de production. Ont-elles toutes été parfaitement testées, y compris en ce qui concerne leurs interactions ? Pas entièrement, et c’est un sujet pour des travaux ultérieurs. Un outil de visualisation appelé Conductor At Scale transforme également un historique git générique en une animation de style arcade, avec des pistes Conductor qui explosent à l’écran en JavaScript.

Leçons tirées de cette expérience

La première leçon est de maintenir, autant que possible, la communication avec un seul agent et de confier aux sous-agents uniquement des tâches simples et prédéterminées ne nécessitant aucune interaction. Deux pratiques viennent soutenir cela.

• Minimiser le temps d’attente entre l’agent et l’utilisateur. Une commande /roastme est un bon moyen de soulever les questions difficiles dès le début afin que l’agent puisse fonctionner sans interruption, et Conductor est efficace pour collecter les questions hors ligne. Au lieu d’une question toutes les cinq minutes pendant 30 secondes, vous répondez à tout en une seule session de 30 minutes, vous allez faire du vélo et revenez avec une application terminée.

Cette capture d’écran montre /roastme en cours d’exécution dans Conductor, y compris les fautes d’orthographe.

• Préserver une relation simple entre l’agent et les sous-agents. Le jargon du secteur penche vers des hiérarchies complexes à plusieurs agents, mais en 2026, le choix le plus sûr est des tâches simples et répétables, axées sur la mise en œuvre et peu sujettes à l’ambiguïté, ce qui évite des surcoûts inutiles liés à l’orchestration.

Il existe également une taxe liée à l’orchestration. Écrire du code est peu coûteux, c’est la spécification qui compte, tandis que les tests et l’acceptation des résultats constituent le nouveau goulot d’étranglement. D’autres acteurs du domaine semblent être d’accord. Les équipes peuvent soit se placer en avance sur cette tendance, soit en être submergées.

Pour ceux qui souhaitent essayer cette approche, le point de départ est l’application de bureau Antigravity 2.0, qui offre une orchestration multitrack visuelle prête à l’emploi.