Come Eseguire da 3 a 8 Agenti di Codifica in Parallelo Senza Perdere il Controllo

Eseguire due agenti contemporaneamente ti prende cinque minuti. Apri due terminali, assegni a ciascuno un compito e guardi il testo scorrere.

I problemi iniziano al quarto.

Non sai più quale sta aspettando una revisione, quale ha finito, quale si è bloccato dieci minuti fa mentre guardavi altrove. Scorri nel terminale sbagliato. Rilanci un compito che era già stato completato. Dopo un'ora, stai facendo il lavoro di tre agenti a mano solo per mantenere l'orientamento.

Non è un problema di potenza. È un problema di visibilità.

Il vero collo di bottiglia è la tua testa

Un agente che codifica autonomamente consegna a raffiche. Pensa per 40 secondi, scrive, si ferma, aspetta il tuo via libera. Durante quei 40 secondi puoi seguire un secondo agente. Mentre il secondo scrive, approvi il primo.

Fino a 3 agenti, il tuo cervello tiene il passo. Oltre 5, perdi il filo.

Anthropic ha pubblicato un numero significativo nei suoi documenti: i tentativi non guidati riescono circa una volta su tre. La differenza tra chi spedisce in volume e tutti gli altri non è il modello. È la struttura che mettono in atto prima di lanciare.

Quindi, prima di scalare, strutturi.

Regola uno: un agente, uno spazio di lavoro isolato

L'errore classico è mettere tre agenti sulla stessa copia del repository. Si pestano i piedi a vicenda. Uno modifica package.json, così fa un altro, e finisci con un merge che non puoi districare.

La soluzione è due parole: git worktree.

git worktree add ../project-auth feature/auth
git worktree add ../project-billing feature/billing
git worktree add ../project-export feature/export

Ogni agente lavora nella propria cartella, sul proprio branch, con i propri file. Zero collisioni. Rivedi ogni branch separatamente e fai il merge quando è pronto.

Questa è la base di ciò che i ricercatori chiamano delega isolata: un manager centrale divide il lavoro, ogni sottocompito viene eseguito nel proprio angolo, e l'integrazione avviene successivamente, con test per convalidare.

Regola due: non assegnare mai lo stesso file centrale due volte

Prima di dividere il lavoro, trova i file che diverse funzionalità dovranno toccare. Il router. Lo schema del database. La configurazione delle rotte API.

Questi file ricevono esattamente un agente. Gli altri aspettano o lavorano intorno a loro.

Assegna lo stesso routes.ts a due agenti paralleli e pagherai in conflitti di merge ciò che pensavi di guadagnare in parallelismo. Quello scambio perde ogni volta.

Regola tre: una bacheca, non dieci terminali

Qui è dove la maggior parte delle persone abbandona il multi-agente. Aprono otto schede del terminale, perdono il filo e tornano strisciando a un singolo agente.

Hai bisogno di una vista che risponda a tre domande a colpo d'occhio:

• Chi sta codificando in questo momento?
• Chi sta aspettando la mia revisione?
• Chi ha finito o si è bloccato?

Senza quella vista, il multi-agente ti costa più in carico mentale di quanto ti dia in velocità. Con essa, puoi davvero gestire 6 o 8 flussi di lavoro contemporaneamente.

Questo è esattamente il divario che AgentsRoom colma. Ogni agente ottiene la propria tessera, il proprio stato, il proprio colore. Un agente in attesa della tua risposta diventa rosso e ti avvisa. Smetti di scorrere il terminale sbagliato, guardi la bacheca e sai dove andare.

Il ritmo che funziona nella pratica

Ecco il ritmo con cui inizierei.

Inizia con due agenti, su due funzionalità che non condividono file. Abituati al ciclo revisione-poi-merge. Quel ciclo, non il codice, diventa il tuo vero lavoro.

Una volta che quel ciclo sembra fluido, passa a quattro. Mantieni una lista di priorità rigorosa di compiti ad alto impatto e fai molto affidamento sulla modalità piano: approvi il piano dell'agente prima che scriva una riga. Un piano approvato in anticipo ti risparmia una revisione dolorosa in seguito.

Il punto dolce si trova tra 3 e 8 funzionalità sullo stesso repo, con supervisione visiva. Oltre, anche con una buona bacheca, la revisione diventa il collo di bottiglia e perdi il vantaggio.

Cosa guadagni realmente

Il multi-agente è inutile per il 95% dei piccoli compiti. Per correggere un errore di battitura o aggiungere un pulsante, un singolo agente è sufficiente, ed è più veloce.

Dove cambia la tua settimana è sul grande lavoro. Avvii tre refactoring indipendenti una sera, li rivedi quando arrivano, e la mattina dopo hai tre giorni di lavoro pronti per essere uniti.

Il segreto non è il numero di agenti. È sapere sempre quale ha bisogno di te, in questo momento. Risolvi quello, e il resto seguirà.