Il y a un mois, ton setup de code assisté par IA c'était un agent, une conversation, un thread. Tu tapais un prompt, il suggérait la ligne suivante, tu acceptais ou refusais. Simple.
Mais un seul agent sur une seule tâche ne va pas liquider un backlog de douze items avant vendredi. Tu as besoin de parallélisme : plusieurs agents qui bossent sur plusieurs branches simultanément. La question que personne n'a posée avant de shipper : qu'est-ce qui arrive à ton historique git quand ces branches doivent fusionner ?
Dans la première moitié d'avril 2026, quatre entreprises ont livré des agents de code parallèles — chacune avec une stratégie différente pour éviter les collisions. Le 14 avril, Anthropic a redesigné Claude Code Desktop avec les Routines : des agents persistants qui tournent dans des sessions indépendantes. Le 16 avril, OpenAI a poussé une mise à jour majeure de Codex avec des agents dans des workspaces virtuels sandboxés. La vague avait commencé deux semaines plus tôt : GitHub Copilot a lancé /fleet le 1er avril, et Cursor 3 a sorti les Agent Tabs en arrière-plan le 2 avril.
Quatre outils, quatre modèles d'isolation. Voici comment chacun gère le problème du merge — et comment chacun échoue.
Cursor 3 utilise des git worktrees — des checkouts séparés par agent. Les agents ne se bloquent jamais pendant le travail. Mais Cursor reporte tous les conflits au moment du merge. Deux agents refactorisent le même module depuis des worktrees différents, et tu découvres la collision seulement en unifiant les branches — après que les deux ont construit du travail supplémentaire sur des hypothèses divergentes.
GitHub /fleet adopte l'approche last-write-wins. Leur propre blog l'indique : "Si deux agents écrivent dans le même fichier, le dernier à finir gagne — silencieusement. Pas d'erreur, pas de merge, juste un écrasement." Le travail de l'agent le plus lent disparaît sans laisser de trace. Pas de marqueurs de conflit. Pas d'avertissement.
Claude Code Routines donne à chaque agent une session totalement isolée. L'Agent A ne sait pas que l'Agent B existe. L'un ajoute une couche de cache ; l'autre restructure le flux de données dont ce cache dépend. Les deux branches passent la CI indépendamment. Ensemble, elles crashent au runtime.
OpenAI Codex offre l'isolation la plus forte : chaque agent tourne dans une VM sandboxée. Et c'est aussi la plus difficile à réconcilier — tu exportes les diffs depuis des snapshots de VM et tu résous les conflits toi-même avec du git standard. OpenAI ne livre aucun outillage de merge.
La combinatoire des collisions joue contre toi. Dans une application web typique, les modules partagés — utilitaires, types, configuration, middleware — représentent 15–25% des fichiers en nombre mais apparaissent dans le graphe d'imports de quasiment chaque feature. Dispatche trois agents sur trois features "indépendantes", et la probabilité qu'au moins deux touchent un module partagé tend vers la certitude. Et faire tourner ces agents n'est pas gratuit non plus : chaque session de code complexe consomme 50k–200k tokens, et cinq agents parallèles peuvent brûler 15–40$ par round de dispatch. Quand un conflit de merge force un re-run, tu paies le même travail deux fois.
Comme Addy Osmani l'a écrit le 26 mars : "Trois agents focalisés surpassent systématiquement un agent généraliste qui travaille trois fois plus longtemps" — mais il a prévenu que "les petites erreurs inoffensives se composent à un rythme insoutenable." Le sweet spot est fin comme une lame de rasoir. En dessous de trois agents, tu sous-exploites le parallélisme. Au-dessus de trois, l'overhead du merge dévore les gains.
Les contournements sacrifient tous le parallélisme pour lequel tu as payé. GitHub recommande d'assigner manuellement des fichiers distincts à chaque agent — tu décomposes donc l'architecture toi-même avant de dispatcher. Tu peux séquencer les agents au lieu de les paralléliser, mais ça revient au one-at-a-time avec de la cérémonie en plus. Tu peux scoper les tâches si étroitement que les agents ne se chevauchent jamais, ce qui exige de comprendre la codebase suffisamment bien pour garantir zéro intersection de fichiers. Comme Andrej Karpathy l'a écrit le 3 février : "tu n'écris pas le code directement 99% du temps, tu orchestres des agents qui le font et tu joues le rôle de superviseur."
Le goulot d'étranglement s'est déplacé. Écrire du code, c'est devenu cheap. Le merger coûte tout ce que le parallélisme t'a fait économiser. Ton tableau de dispatch, c'est six onglets de terminal, trois fenêtres de navigateur, et le pari que la branche claude/fix-auth ne contredit pas structurellement copilot/refactor-auth au niveau des types.
Le prochain outil qui gagnera la guerre des agents de code ne livrera pas des agents plus intelligents. Il livrera un orchestrateur merge-aware qui traque ce que chaque agent touche avant qu'ils finissent — pas après. D'ici là, tu exécutes le git merge le plus cher du monde à la main, une branche à la fois.
