Come Scalare gli Agenti di Codifica AI in un Team di Sviluppo

Un sviluppatore con un agente di codifica è una storia di produttività. È facile da raccontare, si dimostra bene ed è genuinamente vero.

Cinque sviluppatori con venti agenti è una cosa completamente diversa. È un problema di coordinamento, e i problemi di coordinamento non vengono risolti dallo strumento che li ha creati. Questa è la parte di cui nessuno scrive, perché si presenta solo dopo la fase di entusiasmo: i guadagni individuali sono reali, arrivano immediatamente, e poi, intorno al terzo o quarto sviluppatore, il team inizia a spendere la sua nuova velocità per ripulire dopo se stesso.

Ciò che segue è l'ordine di fallimento. Non un elenco di best practice in astratto, ma la sequenza in cui le cose si rompono realmente, perché risolverle nell'ordine sbagliato fa perdere un quarto.

Cosa si rompe per primo: contesto condiviso

Ogni sviluppatore che esegue un agente sta silenziosamente insegnando la propria versione del codice sorgente.

Una persona dice al proprio agente che il progetto utilizza azioni server e mai percorsi API. Un'altra non lo menziona mai, quindi il suo agente scrive percorsi API. Un terzo lo menziona una volta, in una sessione che è terminata tre giorni fa. Nessuno ha torto, nessuno sta mentendo, e il repository ora contiene tre interpretazioni della stessa convenzione. Lo noterai nella coda di revisione, che è il posto sbagliato per notarlo: a quel punto il codice esiste.

La soluzione è noiosa ed è la cosa con il massimo leverage in questa pagina. Metti le convenzioni in un file, fai il commit del file.

CLAUDE.md per Claude Code, AGENTS.md per Codex e la maggior parte degli altri agenti CLI, e in pratica molti team mantengono un file di contesto portatile piuttosto che mantenere due file che si allontanano. Il meccanismo conta più del nome del file: le istruzioni vivono nel repository, quindi arrivano con un git pull invece di arrivare attraverso chiunque si trovasse nella stanza.

Cosa deve contenere:

• Le convenzioni che un agente non può dedurre leggendo il codice, specialmente quelle che il codice sorgente attualmente viola in alcuni punti
• I comandi: come eseguire i test, la build, il linter, e quali di essi possono essere eseguiti automaticamente
• Le parti del repo che sono pericolose da toccare, e perché
• Cosa il team non vuole: il refactoring che nessuno ha chiesto, la dipendenza che non deve essere aggiunta, il pattern da cui si sta migrando

Cosa non deve contenere, ed è qui che i team si scottano: qualsiasi cosa specifica per una macchina. Percorsi assoluti, token API personali, porte locali, l'editor preferito di qualcuno. Nel momento in cui un valore specifico per una macchina finisce in un file di contesto impegnato, ogni altro sviluppatore eredita un'impostazione che è sbagliata per loro, e gli agenti sono estremamente bravi a seguire fedelmente istruzioni che non si applicano più.

Un test utile prima di aggiungere una riga: se un compagno di squadra lo estrae, lo aiuta o lo danneggia?

Cosa si rompe per secondo: due agenti, un file

Gli agenti non negoziano. Non controllano se qualcun altro è in fase di modifica. Due agenti puntati allo stesso modulo si sovrascriveranno a vicenda, e nessuno lo menzionerà, perché dal punto di vista di ciascuno il lavoro è stato completato con successo.

Da soli, questo è invisibile. Esegui un agente alla volta, oppure ne esegui diversi e toccano cose diverse. In un team diventa strutturale, e produce la peggiore classe di bug: lavoro che scompare silenziosamente tra due esecuzioni di test verdi.

Due meccanismi lo risolvono, e vuoi entrambi.

Isolamento. Git worktrees danno a ciascun compito il proprio checkout del repository, quindi gli agenti paralleli fisicamente non possono collidere. Questa è la metà economica della soluzione e non c'è motivo di non farlo.

Proprietà. L'isolamento ferma la sovrascrittura; non ferma due persone dal risolvere lo stesso problema due volte, in due rami, in due modi incompatibili. Quella si risolve al momento dell'assegnazione, definendo ciascun compito a un insieme di file e dicendolo nel compito stesso. Non "migliora il flusso di checkout" ma "cambia il passo di pagamento, in questi tre file, non toccare il carrello".

La seconda metà è quella che i team saltano, ed è quella che determina se la fusione è una formalità o un pomeriggio.

Cosa si rompe per terzo: revisione

Tutto ciò che riguarda la revisione su scala di team deriva da un numero: quanto diff arriva all'ora.

Un sviluppatore che legge ogni riga funziona bene. Cinque sviluppatori che eseguono quattro agenti ciascuno generano più diff al giorno di quanto il team possa leggere, e l'esito onesto non è una revisione attenta, è un teatro di approvazione. Un umano che scorre un diff di novecento righe alle 18:00 produce una firma senza produrre conoscenza, che è peggio che non rivedere, perché crea un'assicurazione dove non ce n'è.

La politica che sopravvive non è "rivedi tutto" e non è "fidati degli agenti". È spostare la revisione ai due confini del lavoro: leggi il piano prima che l'agente inizi, perché un piano sbagliato eseguito perfettamente è la modalità di fallimento più costosa disponibile, poi leggi il diff in proporzione a ciò che la modifica può rompere. La copia di marketing e il CSS ricevono una scorsa. Autenticazione, pagamenti, permessi, dati personali e migrazioni vengono letti riga per riga da un umano, ogni volta, indipendentemente da quanto pulito sembri il diff.

Questo merita una propria conversazione, e l'abbiamo scritto separatamente: dovresti ancora rivedere il codice del tuo agente AI esamina i dieci segnali oggettivi che una modifica è andata male, e la tabella del raggio d'azione che i team possono adottare così com'è.

Un'aggiunta specifica per il team. Quando diversi agenti condividono un repository, la revisione ha bisogno di attribuzione: quale agente, quale compito, quale sviluppatore. Senza di essa, un diff non ha autore e la revisione si trasforma in archeologia. Questa è la cosa più utile da sistemare nella tua configurazione una volta che superi tre o quattro agenti concorrenti.

Cosa si rompe per quarto: costo, e la conversazione sul costo

La spesa di token smette di essere un dettaglio personale nel momento in cui appare su una fattura di team.

La trappola è che la fattura è mensile e aggregata, quindi la conversazione che produce è anch'essa mensile e aggregata, il che significa che produce una politica invece di una soluzione. Qualcuno propone un modello più economico per tutti. Qualcun altro propone di limitare le sessioni. Entrambi sono congetture.

La distribuzione reale è quasi mai uniforme. Ci sono un numero ridotto di sessioni lunghe, su uno o due progetti, con un contesto che è cresciuto tutto il giorno e non è mai stato ripristinato. Questo è un comportamento correggibile, e puoi correggerlo solo se puoi vedere la spesa per sessione e per progetto piuttosto che per mese. Abbiamo coperto la meccanica di questo in come controllare l'uso dei token e come ridurlo senza rallentare.

Rendi il numero visibile alle persone che lo generano, prima che diventi un argomento di gestione. Uno sviluppatore che può vedere che una sessione è costata più dell'intera giornata precedente cambia le proprie abitudini da solo, e questo non costa nulla al team politicamente.

Cosa cambia realmente nei rituali del team

Tre cose, nella nostra esperienza e in ciò che i team riportano.

Il standup passa dallo stato a sbloccare. Cosa ha fatto ciascuna persona ieri è in gran parte visibile nei rami. Ciò che vale cinque minuti è quali agenti sono bloccati, e su cosa.

I prompt diventano beni condivisi. L'istruzione che ha prodotto un buon risultato per uno sviluppatore vale di più per il team del codice che ha prodotto, ed è esattamente il tipo di cosa che evapora nella cronologia di un terminale privato. I team che mantengono una libreria di prompt condivisa nel repository smettono di riscoprire la stessa formulazione ogni settimana.

La specializzazione si sposta dalle persone ai ruoli. Una volta che gli agenti gestiscono la scrittura, la domanda interessante è chi rivede cosa, e i team tendono naturalmente ad assegnare ruoli agli agenti allo stesso modo in cui li assegnano alle persone: uno sull'implementazione, uno sulla revisione, uno sui test. Questa è l'idea dietro Agent Teams, dove un compito viene passato da un ruolo Dev a un ruolo QA con il diff, i rischi e i suggerimenti per i test allegati, e le porte di qualità sono decise dal tuo suite di test piuttosto che dall'opinione di un agente sul proprio lavoro.

La configurazione che tiene

Condensata, nell'ordine che conta:

I primi quattro non costano nulla tranne che accordo. Gli ultimi due sono il motivo per cui un team alla fine vuole qualcosa sopra il terminale: non perché i terminali siano cattivi, ma perché un terminale mostra un agente alla volta e non ti dà modo di rispondere "chi sta eseguendo cosa, su quale progetto, in questo momento".

Questo è il problema AgentsRoom per team su cui è costruito: ogni agente su ogni progetto in un'unica vista, con il suo ruolo, il suo stato e il suo costo allegati, e un compagno mobile per i momenti in cui il team non è alle proprie scrivanie. Funziona allo stesso modo con Claude Code e con Codex, il che conta più di quanto sembri: la maggior parte dei team finisce per eseguire entrambi, e una configurazione che presume un fornitore diventa silenziosamente la prossima cosa che si rompe.

Inizia con il file di contesto però. È gratuito, richiede un pomeriggio, e rimuove più attrito di qualsiasi strumento tu possa installare questo trimestre.