Come evitare che più agenti di codifica si sovrascrivano a vicenda
Eseguire un agente di codifica AI su un repository dà la sensazione di pair programming. Eseguire tre o cinque agenti sullo stesso repository può trasformarsi in una fabbrica di conflitti di merge se tutti condividono lo stesso checkout. Un agente cambia branch, un altro modifica lo stesso file, un terzo esegue un comando di pulizia e, improvvisamente, nessuno sa quale diff appartiene a quale attività.
La soluzione non è un prompt più grande. La soluzione è un workflow. Tratto gli agenti come sviluppatori junior veloci con accesso alla shell: utili, ma hanno bisogno di confini.
La versione breve
- Utilizza un worktree Git per agente.
- Utilizza un branch per attività.
- Assegna a ogni agente un confine di proprietà chiaro per file o moduli.
- Inserisci le regole condivise del repository in
AGENTS.md,CLAUDE.mdo entrambi con un symlink. - Blocca i comandi Git distruttivi a meno che un umano non li approvi.
- Esegui il merge tramite pull request con CI e protezione dei branch.
Questa è una struttura sufficiente per la maggior parte del lavoro parallelo degli agenti.
Perché un checkout condiviso fallisce
Un normale checkout Git ha un solo albero di lavoro, un solo indice e un solo branch corrente. Va bene per uno sviluppatore o un agente. Diventa complicato quando più agenti agiscono contemporaneamente.
Se l'Agente A è a metà di un refactoring di autenticazione e l'Agente B esegue git checkout main, l'area di lavoro dell'Agente A cambia sotto i suoi piedi. Se l'Agente C esegue git reset --hard, il lavoro non committato può scomparire. Anche comandi innocui come git stash pop possono mescolare modifiche non correlate.
Puoi dire agli agenti di non fare queste cose, e dovresti. Ma l'isolamento del filesystem è più forte della fiducia.
Utilizza i worktree Git per l'isolamento
I worktree Git consentono a un repository di avere più directory di lavoro collegate alla stessa cronologia. Ogni directory può trovarsi sul proprio branch, condividendo la stessa object database. Eviti il costo e la confusione di clonare il repository cinque volte, ma ogni agente ottiene comunque i propri file.
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 listQuindi avvia un agente all'interno di ogni directory. L'Agente A lavora in ../site-auth. L'Agente B lavora in ../site-billing. L'Agente C lavora in ../site-tests. Possono eseguire test, modificare file e creare commit senza modificare il checkout degli altri.
Questo è anche il pattern che Claude Code documenta per le sessioni parallele: worktree separati, branch separati e modifiche isolate. La documentazione di aiuto di Anthropic va oltre e descrive le sessioni parallele basate su worktree come un workflow comune per utenti esperti per eseguire diverse sessioni di Claude contemporaneamente.
Assegna a ogni agente una superficie di proprietà
I worktree risolvono le collisioni a livello di file. Non risolvono i conflitti a livello di prodotto. Due agenti possono ancora prendere decisioni incompatibili se l'attività è vaga.
Prima di avviare gli agenti in parallelo, divido il lavoro per proprietà. Non solo per nomi di file, ma per responsabilità.
Sei responsabile di src/auth/** e tests/auth/**.
Non modificare file al di fuori di questo ambito.
Non modificare le forme delle API pubbliche senza fermarti prima.
Esegui i test di autenticazione prima di segnalare il completamento.
Apri una PR con un riepilogo mirato.Quel prompt è noioso, ed è esattamente per questo che funziona. Gli agenti hanno bisogno di confini noiosi più che di prosa intelligente.
Le migliori divisioni avvengono lungo le linee naturali dei moduli: autenticazione, fatturazione, ricerca, documentazione, componenti UI, migrazioni, test. La peggiore divisione è dare a due agenti proprietà sovrapposte dello stesso servizio e sperare che Git lo risolva in seguito.
Utilizza AGENTS.md e CLAUDE.md come regole condivise
Le istruzioni del repository dovrebbero vivere nel repository, non solo in una finestra di chat. CLAUDE.md è la convenzione che Claude Code legge. AGENTS.md è una convenzione più generale per gli agenti di codifica. Se utilizzi entrambi gli strumenti, mantieni un'unica fonte di verità e fai puntare l'altro nome ad essa tramite symlink.
ln -s CLAUDE.md AGENTS.mdQuel file dovrebbe includere i comandi di build del repository, i comandi di test, le note di deploy, le regole di stile e qualsiasi restrizione rigida. Ad esempio: non modificare file generati, non toccare le migrazioni senza approvazione, usa npm run lint prima della consegna, o mantieni i blocchi di codice del blog su una singola riga HTML con tag <br/>.
Il punto è semplice: ogni agente dovrebbe iniziare con lo stesso contesto locale.
Rendi espliciti i comandi Git pericolosi
Non permetto agli agenti di improvvisare con Git distruttivo. Questi comandi sono utili in un terminale controllato da un umano, ma rischiosi nel lavoro autonomo:
git reset --hard
git checkout .
git clean -fd
git push --force
git stash popLa mia regola predefinita è: leggi liberamente, scrivi in modo mirato e chiedi prima di usare Git distruttivo. Gli agenti possono eseguire git status, git diff, git log e commit normali. Non dovrebbero scartare lavoro, forzare il push o spostare un altro branch a meno che l'attività non lo richieda esplicitamente.
Utilizza le pull request come punto di consegna
Non unire il lavoro degli agenti copiando file tra cartelle. Fai in modo che ogni agente produca un branch e una 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 createSu GitHub, le regole di protezione dei branch possono richiedere revisioni delle pull request, controlli di stato, cronologia lineare e code di merge. Questi controlli sono più importanti quando gli agenti possono generare codice rapidamente. La velocità è utile solo se main rimane affidabile.
Mi piacciono le piccole PR degli agenti. Un diff mirato di 200 righe è revisionabile. Un refactoring misto di 4.000 righe è dove si nascondono i bug.
Esegui il merge in ordine di dipendenza
Se l'Agente A modifica un'API e l'Agente B la utilizza, esegui prima il merge di A. Quindi, riesegui il rebase di B sul branch base aggiornato e lascia che B risolva i propri conflitti.
git fetch origin
git rebase origin/main
npm testQuesto mantiene pulito il modello mentale. L'agente che possiede il lavoro dipendente è responsabile dell'adattamento alla nuova base. Il revisore umano vede una PR coerente alla volta.
Il workflow che userei domani
- Aggiorna
main. - Crea un worktree e un branch per ogni attività dell'agente.
- Avvia ogni agente all'interno del proprio worktree.
- Assegna a ogni agente un confine di proprietà scritto.
- Fai in modo che ogni agente esegua i test pertinenti.
- Esegui il push di ogni branch e apri una PR.
- Revisiona, esegui il merge in ordine di dipendenza, quindi rimuovi i worktree completati.
git worktree remove ../site-auth
git branch -d agent/auth-refactorPiù agenti di codifica possono lavorare sullo stesso codebase. Semplicemente non dovrebbero lavorare nello stesso checkout. Usa Git per l'isolamento, le pull request per la revisione e i file di istruzioni a livello di repository per le regole condivise. Questo ti darà velocità parallela senza trasformare il repository in un mucchio di diff misteriosi.