Agents codeurs asynchrones — stratégies de coordination efficaces

En bref

Un agent unique travaillant sur une tâche logicielle longue bute sur deux limites : la durée d’exécution et la capacité à maintenir une vue cohérente d’un dépôt complexe. Faire travailler plusieurs agents en parallèle semble naturel, mais les interférences entre leurs modifications échouent fréquemment à l’intégration. Geng et Neubig (CMU, 2026) proposent CAID, un système de coordination multi-agents inspiré des primitives git, et montrent des gains de 6 à 26 points de pourcentage sur des benchmarks de software engineering à long horizon.

Le problème : pourquoi la parallélisation naive échoue

Imaginez quatre menuisiers travaillant sur le même meuble en même temps, dans le même atelier, sans plan partagé. L’un visse une planche, l’autre la dévisse pour faire passer un fil, le troisième scie un bord parce qu’il pense que c’est trop long. Chacun travaille bien individuellement — mais l’ensemble est ruiné. Pour collaborer, ils ont besoin (1) de copies physiquement séparées de la pièce sur laquelle ils travaillent, (2) d’un plan d’assemblage explicite, (3) d’un protocole de fusion des contributions. CAID transpose cette logique aux agents codeurs.

Quand deux agents modifient le même dépôt simultanément sans mécanisme d’isolation, les conflits sont inévitables. Un agent renomme une fonction ; l’autre écrit du code qui appelle l’ancien nom. Chacun produit un résultat correct en isolation — mais l’ensemble intégré est cassé, et la correction exige souvent une révision complète d’au moins un agent, pas un simple correctif.

Les études empiriques identifient ce problème comme le principal mode d’échec des systèmes multi-agents sur des artefacts partagés [Cemri et al., 2025 ; Khatua et al., 2026]. Les approches existantes — pipelines à rôles, orchestrateurs hiérarchiques — adressent la décomposition des tâches, mais pas la coordination physique des modifications concurrentes.

CAID : trois primitives git comme fondations

CAID (Centralized Asynchronous Isolated Delegation) structure la coordination autour de trois mécanismes directement calqués sur les pratiques humaines de développement logiciel.

1. Graphe de dépendances et délégation centralisée

Avant tout dispatch, un agent manager construit un graphe de dépendances du dépôt. Chaque nœud est une unité de travail ; chaque arc indique qu’une tâche dépend d’une autre. Une tâche n’est assignée à un ingénieur que si toutes ses dépendances sont déjà intégrées dans la branche principale.

Le manager décompose le travail en groupes de tâches correspondant au nombre maximal d’ingénieurs parallèles. Les fichiers fortement interdépendants sont regroupés et confiés au même ingénieur pour réduire les risques de conflit. La communication manager → ingénieur passe par un protocole JSON structuré, pas par du texte libre — ce qui rend les frontières de responsabilité vérifiables programmatiquement.

2. Isolation par worktrees git

Chaque ingénieur travaille dans son propre git worktree, une copie physiquement isolée du dépôt. Les modifications parallèles ne peuvent pas s’écraser mutuellement. Certains fichiers partagés (ex. __init__.py) sont marqués en lecture seule pour les ingénieurs.

L’expérience montre que cette isolation physique n’est pas substituable par des instructions verbales. Dans une configuration “soft isolation” où les ingénieurs partagent un workspace et reçoivent des consignes pour éviter les conflits, les performances chutent en dessous de l’agent unique sur PaperBench (55,5% contre 57,2%). Avec les worktrees, le même système atteint 63,3%.

En clair : dire aux agents “essayez de ne pas vous marcher dessus” ne marche pas — les performances tombent SOUS l’agent unique. Donner à chaque agent sa propre copie physique du dépôt (worktree) et fusionner explicitement à la fin via git merge est la différence entre “naive parallèle qui dégrade” et “CAID qui améliore de 6 points”.

3. Intégration via git merge et auto-vérification

Quand un ingénieur termine, il commit ses modifications. Le manager fusionne vers la branche principale via git merge. En cas de conflit, c’est l’ingénieur qui a produit le commit conflictuel qui est chargé de le résoudre — il récupère la branche principale dans son worktree, résout localement, et resoumet.

Avant de committer, chaque ingénieur exécute les tests couvrant ses fichiers modifiés. Tout test raté ou exception d’exécution doit être résolu avant soumission. Cette auto-vérification distribuée évite de concentrer la charge de révision sur le manager.

Résultats mesurés

CAID est évalué sur deux benchmarks à long horizon :

• Commit0 : implémenter des bibliothèques Python (tinydb, minitorch, jinja…) depuis un squelette, avec tests unitaires. Seul le passage de tous les tests compte.
• PaperBench : reproduire les contributions principales d’un article de conférence (implémentation + exécution d’expériences).

Sur Claude Sonnet 4.5, CAID (4 ingénieurs) améliore le taux de passage de 53,1% à 59,1% sur Commit0-Lite, et de 57,2% à 63,3% sur PaperBench. Pour MiniMax 2.5, le gain sur PaperBench est de 10,4% à 36,7%.

Doubler les itérations ne suffit pas

Une question naturelle : un agent unique ne pourrait-il pas combler l’écart en ayant simplement plus de temps ? Les auteurs testent max_iterations = 100 vs 200. Le résultat est net : doubler le budget d’itérations produit des gains marginaux et, dans certains cas, dégrade les performances (le score de Claude Sonnet 4.5 sur PaperBench diminue avec 200 itérations). Les gains de CAID sur le même budget de référence sont systématiquement bien supérieurs.

La stratégie “fallback” est inefficace

Une stratégie pratique consisterait à lancer d’abord un agent unique, puis à passer au multi-agent en cas d’échec. Les données montrent que cette approche accumule les coûts des deux configurations sans gain proportionnel. Sur PaperBench avec Claude Sonnet 4.5 : l’approche séquentielle atteint 66,8% mais multiplie le temps d’exécution (3884s contre 2080s) et le coût ($12,6 contre $9,3), pour seulement 3,5 points de plus que CAID direct. Sur Commit0-Lite avec MiniMax 2.5, le score final est identique (57,0%) dans les deux cas, mais le coût total double.

En clair : la stratégie “agent unique d’abord, multi-agent en repli” ressemble à du bon sens — économe sur les cas faciles, robuste sur les cas durs. En pratique, elle cumule les coûts sans gain proportionnel. Si la tâche justifie le multi-agent, il faut commencer en multi-agent direct.

Quand utiliser CAID vs alternatives

Facteurs qui font ou défont la coordination

Le nombre d’ingénieurs n’est pas monotone

Plus d’agents n’implique pas de meilleures performances. Sur Commit0-Lite, 4 ingénieurs améliorent le score par rapport à 2, mais 8 ingénieurs le dégradent. Sur PaperBench, passer de 2 à 4 ou 8 ingénieurs n’apporte pas de gain mesurable tout en augmentant temps et coût.

Le problème avec 8 ingénieurs illustré sur le dépôt simpy est explicite : le manager assigne des fonctions différentes du même fichier events.py à plusieurs ingénieurs. Les modifications sont logiquement séparables, mais créent des conflits d’intégration au niveau fichier. Le taux de passage chute de 92,1% (N=4) à 44,3% (N=8). La leçon : le nombre d’agents doit correspondre à la modularité intrinsèque de la tâche, pas simplement être maximisé.

La délégation détermine la trajectoire

Deux runs CAID sur le même dépôt (minitorch), avec des prompts différents, produisent 8,7% et 34,3% de taux de passage. La différence tient à un seul fichier : autodiff.py, critique pour les tests dépendants. Le run 2 l’assigne explicitement ; le run 1 ne l’assigne jamais. La capacité du manager à identifier les dépendances à fort impact est décisive.

Vérification vs efficacité : un arbitrage mesurable

Trois configurations de prompt sont comparées sur un sous-ensemble de Commit0-Lite :

• Revue manager à chaque round : 60,2% de taux de passage, 3689s de runtime
• Auto-vérification par l’ingénieur : 55,1%, 2244s
• Mode efficacité prioritaire : 54,0%, 1909s

Il existe un arbitrage clair entre robustesse d’intégration et vitesse d’exécution. L’auto-vérification est un équilibre raisonnable ; la revue systématique par le manager améliore la qualité mais alourdit considérablement la coordination.

Limites

Le coût API de CAID est systématiquement plus élevé que l’agent unique, et le temps d’exécution total ne diminue pas proportionnellement à la parallélisation — l’intégration reste séquentielle et conditionnée aux tests. La délégation repose sur des heuristiques de prompt, pas sur des politiques apprises : une décomposition incorrecte produit des outputs localement corrects mais globalement inefficaces à intégrer. Le cadre reste spécifique au software engineering ; son extension à d’autres domaines (synthèse documentaire, planification) nécessiterait de redéfinir les mécanismes d’isolation et de vérification.

Ce qu’il faut retenir

• Le pattern branch-and-merge, implémenté via git worktree et git merge, est la primitive centrale qui rend la collaboration multi-agents sur artefacts partagés fiable.
• L’isolation physique (worktrees séparés) surpasse systématiquement l’isolation par instruction verbale, surtout quand les dépendances sont implicites.
• Doubler le budget d’itérations d’un agent unique ne compense pas la limite structurelle du traitement séquentiel sur des tâches à long horizon.
• Le nombre optimal d’agents est contraint par la modularité de la tâche et la capacité de délégation du manager — au-delà, les conflits d’intégration annulent les gains de parallélisme.
• La stratégie “agent unique d’abord, multi-agent en fallback” est dominée par l’exécution multi-agents directe sur coût et temps.