Comment empêcher plusieurs agents de codage de s'écraser mutuellement
Faire fonctionner un agent de codage IA sur un dépôt ressemble à du pair programming. En faire fonctionner trois ou cinq sur le même dépôt peut ressembler à une usine à conflits de fusion si tous partagent le même checkout. Un agent change de branche, un autre modifie le même fichier, un troisième exécute une commande de nettoyage, et soudain personne ne sait quel diff appartient à quelle tâche.
La solution n'est pas un prompt plus long. La solution est un workflow. Je traite les agents comme des développeurs juniors rapides avec accès au shell : utiles, mais ils ont besoin de limites.
La version courte
- Utilisez un worktree Git par agent.
- Utilisez une branche par tâche.
- Donnez à chaque agent une limite claire de propriété de fichier ou de module.
- Placez les règles partagées du dépôt dans
AGENTS.md,CLAUDE.md, ou les deux avec un lien symbolique. - Bloquez les commandes Git destructrices sauf si un humain les approuve.
- Fusionnez via des pull requests avec CI et protection de branche.
C'est suffisamment structuré pour la plupart des travaux parallèles d'agents.
Pourquoi un checkout partagé échoue
Un checkout Git normal a un arbre de travail, un index et une branche actuelle. C'est bien pour un développeur ou un agent. Cela devient compliqué lorsque plusieurs agents agissent en même temps.
Si l'Agent A est à mi-chemin d'un refactoring d'authentification et que l'Agent B exécute git checkout main, l'espace de travail de l'Agent A vient de changer sous ses pieds. Si l'Agent C exécute git reset --hard, le travail non commité peut disparaître. Même des commandes inoffensives comme git stash pop peuvent mélanger des changements non liés.
Vous pouvez dire aux agents de ne pas faire ces choses, et vous devriez. Mais l'isolation du système de fichiers est plus forte que la confiance.
Utilisez les worktrees Git pour l'isolation
Git worktrees permet à un dépôt d'avoir plusieurs répertoires de travail attachés à la même historique. Chaque répertoire peut être sur sa propre branche, tout en partageant la même base de données d'objets. Vous évitez le coût et la confusion de cloner le dépôt cinq fois, mais chaque agent obtient toujours ses propres fichiers.
git fetch origin
git worktree add ../site-auth -b agent/auth-refactor origin/main
git worktree add ../site-billing -b agent/billing-fix origin/main
git worktree add ../site-tests -b agent/test-coverage origin/main
git worktree listEnsuite, démarrez un agent dans chaque répertoire. L'Agent A travaille dans ../site-auth. L'Agent B travaille dans ../site-billing. L'Agent C travaille dans ../site-tests. Ils peuvent exécuter des tests, modifier des fichiers et créer des commits sans modifier le checkout des autres.
C'est aussi le schéma que Claude Code documente pour les sessions parallèles : worktrees séparés, branches séparées et modifications isolées. Les documents d'aide d'Anthropic vont plus loin et décrivent les sessions parallèles basées sur les worktrees comme un workflow courant pour les utilisateurs avancés afin d'exécuter plusieurs sessions Claude à la fois.
Donnez à chaque agent une surface possédée
Les worktrees résolvent les collisions au niveau des fichiers. Ils ne résolvent pas les conflits au niveau du produit. Deux agents peuvent toujours prendre des décisions incompatibles si la tâche est vague.
Avant de lancer des agents en parallèle, je divise le travail par propriété. Pas seulement par noms de fichiers, mais par responsabilité.
Vous possédez src/auth/** et tests/auth/**.
Ne modifiez pas les fichiers en dehors de cette portée.
Ne modifiez pas les formes d'API publiques sans vous arrêter d'abord.
Exécutez les tests d'authentification avant de signaler que c'est terminé.
Ouvrez une PR avec un résumé ciblé.Ce prompt est ennuyeux, c'est exactement pourquoi il fonctionne. Les agents ont besoin de limites ennuyeuses plus que de prose intelligente.
Les meilleures divisions se font le long des lignes de modules naturels : authentification, facturation, recherche, documentation, composants UI, migrations, tests. La pire division est de donner à deux agents une propriété chevauchante du même service et d'espérer que Git s'en chargera plus tard.
Utilisez AGENTS.md et CLAUDE.md comme règles partagées
Les instructions du dépôt doivent vivre dans le dépôt, pas seulement dans une fenêtre de chat. CLAUDE.md est la convention que Claude Code lit. AGENTS.md est une convention plus générale pour les agents de codage. Si vous utilisez les deux outils, gardez une source de vérité et créez un lien symbolique vers l'autre nom.
ln -s CLAUDE.md AGENTS.mdCe fichier doit inclure les commandes de build du dépôt, les commandes de test, les notes de déploiement, les règles de style et toutes les restrictions strictes. Par exemple : ne pas modifier les fichiers générés, ne pas toucher aux migrations sans approbation, utiliser npm run lint avant la remise, ou garder les blocs de code de blog sur une seule ligne HTML avec des balises <br/>.
Le but est simple : chaque agent doit commencer avec le même contexte local.
Rendez les commandes Git dangereuses explicites
Je ne laisse pas les agents improviser avec des Git destructeurs. Ces commandes sont utiles dans un terminal contrôlé par un humain, mais risquées dans un travail autonome :
git reset --hard
git checkout .
git clean -fd
git push --force
git stash popMa règle par défaut est : lire librement, écrire de manière ciblée, et demander avant d'utiliser des commandes Git destructrices. Les agents peuvent exécuter git status, git diff, git log, et des commits normaux. Ils ne devraient pas jeter de travail, forcer le push, ou déplacer une autre branche à moins que la tâche ne l'exige explicitement.
Utilisez les pull requests comme point de remise
Ne fusionnez pas le travail de l'agent en copiant des fichiers entre les dossiers. Faites en sorte que chaque agent produise une branche et une pull request.
git status
git diff
npm test
git add src/auth tests/auth
git commit -m auth-refactor
git push origin agent/auth-refactor
gh pr createSur GitHub, les règles de protection de branche peuvent exiger des revues de pull request, des vérifications de statut, un historique linéaire et des files d'attente de fusion. Ces contrôles sont plus importants lorsque les agents peuvent générer du code rapidement. La vitesse n'est utile que si main reste digne de confiance.
J'aime les petites PR d'agents. Un diff ciblé de 200 lignes est révisable. Un refactoring mixte de 4 000 lignes est là où se cachent les bugs.
Fusionnez dans l'ordre des dépendances
Si l'Agent A modifie une API et que l'Agent B consomme cette API, fusionnez A en premier. Ensuite, rebasez B sur la branche de base mise à jour et laissez B résoudre ses propres conflits.
git fetch origin
git rebase origin/main
npm testCela maintient le modèle mental clair. L'agent qui possède le travail dépendant est responsable de s'adapter à la nouvelle base. Le réviseur humain voit une PR cohérente à la fois.
Le workflow que j'utiliserais demain
- Mettez à jour
main. - Créez un worktree et une branche par tâche d'agent.
- Démarrez chaque agent dans son propre worktree.
- Donnez à chaque agent une limite de propriété écrite.
- Faites en sorte que chaque agent exécute les tests pertinents.
- Poussez chaque branche et ouvrez une PR.
- Revoyez, fusionnez dans l'ordre des dépendances, puis supprimez les worktrees terminés.
git worktree remove ../site-auth
git branch -d agent/auth-refactorPlusieurs agents de codage peuvent travailler sur la même base de code. Ils ne devraient simplement pas travailler dans le même checkout. Utilisez Git pour l'isolation, les pull requests pour la revue, et les fichiers d'instructions au niveau du dépôt pour les règles partagées. Cela vous donne une vitesse parallèle sans transformer le dépôt en un tas de diffs mystérieux.