Claude Code Agent Teams: il futuro dello sviluppo assistito dall’AI

Nelle applicazioni su larga scala o negli ambienti enterprise, il contesto si riempie più in fretta di quanto pensi. Una decisione di design importante presa un’ora fa probabilmente non è più nel contesto, quindi devi continuare a rispiegare cose su cui il modello ha già lavorato. Stai facendo quasi tutto giusto, ma il problema è che stai chiedendo a un solo assistente di fare il lavoro di un intero team.

I Claude Code Agent Teams sono stati introdotti per cambiare questo. L’idea è che, invece di far fare tutto in sequenza a una sola sessione, avvii più agenti specializzati che condividono una lista di attività, si scrivono direttamente tra loro ed eseguono il lavoro in parallelo.

In questo articolo ti mostrerò come funzionano gli Agent Teams, che cosa fa ogni ruolo specializzato e come coordinarli su progetti software reali.

Nuovo su Claude Code? Prendi dimestichezza con le basi in un pomeriggio con il nostro corso Claude Code 101.

Cosa sono i Claude Code Agent Teams?

I Claude Code Agent Teams sono un livello di coordinamento che consente a più sessioni di Claude Code di lavorare sullo stesso progetto nello stesso momento. Una sessione assume il ruolo di team lead e crea altre sessioni, chiamate compagni di squadra, per gestire parti specifiche del lavoro.

Ogni compagno di squadra gira come un’istanza Claude Code completa e indipendente con la propria finestra di contesto. Condividono una lista di attività, rivendicano il lavoro man mano che è disponibile e si scambiano messaggi diretti quando serve coordinarsi.

L’impostazione è più di un paio di tab del terminale con Claude in esecuzione in ciascuna. In quel caso, le finestre di chat separate non vedono i progressi altrui e non possono mettersi d’accordo su chi stia facendo cosa. Un agent team, invece, dà a ogni sessione una vista condivisa del lavoro e un canale di comunicazione. Il lead mantiene tutti allineati.

In pratica, questo significa che non sei più tu a fare da staffetta tra sessioni. Il team gestisce da solo il coordinamento e tu intervieni solo per dare direzione e rivedere i risultati.

Perché esistono gli Agent Teams

Una singola sessione di Claude Code va bene finché il progetto non diventa troppo grande.

Ogni sessione di Claude Code ha una finestra di contesto, e quella finestra ha un limite. Man mano che lavori, la sessione si riempie con contenuti di file, output di comandi, discussioni di design e il tuo botta e risposta. A un certo punto, le informazioni più vecchie non rientrano più nel contesto e il modello inizia a dimenticare decisioni prese in precedenza nella stessa attività.

Ci sono tre situazioni comuni in cui questo diventa evidente:

• Repository grandi: una codebase con centinaia di file non può entrare tutta nel contesto. La sessione finisce per rileggere gli stessi file più e più volte, bruciando token per ricostruire una comprensione che aveva già.
• Progetti complessi: funzionalità trasversali, come aggiungere l’autenticazione su backend, frontend e test, richiedono al modello di gestire troppi aspetti contemporaneamente. Ognuno compete per lo spazio con tutto il resto.
• Più attività simultanee: chiedere a una sola sessione di implementare una feature, rifattorizzare un modulo, scrivere test e aggiornare la documentazione nella stessa conversazione è una ricetta per i guai.

La risposta è la stessa a cui i team umani sono arrivati decenni fa: dividere il lavoro.

Se una sessione sta raggiungendo i suoi limiti su una rifattorizzazione, assegna le modifiche al backend a un compagno, quelle al frontend a un altro e gli aggiornamenti dei test a un terzo. Ogni compagno usa solo ciò che gli serve per la sua parte di lavoro.

Lo stesso concetto si applica alla ricerca. Un’attività con tre ipotesi in competizione procede più veloce quando tre compagni indagano ciascuno una teoria in parallelo e poi confrontano gli appunti, invece di una singola sessione che le percorre in sequenza.

La specializzazione ti dà profondità e il parallelismo ti dà velocità. Ma insieme ti permettono di fare lavori su cui una singola sessione finirebbe per allucinare o impiegherebbe troppo tempo a completare.

Come funzionano i Claude Code Agent Teams

Una sessione di team attraversa cinque fasi, con l’orchestrazione gestita all’interno di Claude Code.

• Definisci l’obiettivo: Descrivi cosa vuoi in linguaggio semplice, come faresti con un junior engineer. Il lead lo legge e decide come suddividerlo.
• Delega il lavoro: Il lead crea una lista di attività condivisa e avvia i compagni, ciascuno con un nome, un ruolo e un prompt iniziale. Puoi specificare tu la struttura del team o lasciare che la definisca il lead.
• Esegui in parallelo: Ogni compagno prende in carico attività, le marca come in corso, le completa e le segna come fatte. Le dipendenze sono rispettate automaticamente; il file locking previene i conflitti. I compagni possono mandarsi messaggi diretti — non serve passare dal lead.
• Combina i risultati: Il lead raccoglie il lavoro finito, risolve i conflitti e produce un singolo output: una PR, un report, un modulo rifattorizzato o qualsiasi cosa richiedesse l’obiettivo.
• Rivedi l’esito: Tu rivedi il risultato finale come una normale pull request: leggi il diff, esegui il codice, verifica i test.

Ruoli specializzati negli Agent Teams

I ruoli danno forma a un agent team. Senza di essi, finisci con sessioni generiche che fanno lavori sovrapposti. Claude Code non fornisce un elenco fisso — definisci tu i ruoli nel brief o puntando il lead a una definizione di subagent salvata in .claude/agents/.

Planning Agent

Il planning agent scompone l’obiettivo in attività prima che venga scritto del codice. Esplora la codebase, mappa le dipendenze e produce una lista di attività autonome che un singolo compagno può completare senza continui check-in.

In pratica, spesso il team lead ricopre direttamente questo ruolo. Puoi anche far girare un compagno dedicato alla pianificazione quando il lavoro è abbastanza grande da giustificarlo.

Coding Agent

Il coding agent scrive l’implementazione. La maggior parte dei compagni saranno coding agent, ognuno responsabile di una parte distinta del lavoro — backend, frontend, database, funzionalità AI. La chiave è evitare sovrapposizioni di scope: due compagni che modificano lo stesso file si sovrascriveranno a vicenda.

I coding agent funzionano bene su modelli più economici. Molti professionisti eseguono il lead su Opus e i compagni su Sonnet, dato che l’esecuzione non richiede la stessa profondità di ragionamento del coordinamento.

Testing Agent

Il testing agent scrive ed esegue i test. Può lavorare rispetto a un contratto API concordato mentre il compagno di coding sta ancora costruendo l’endpoint — così quando il codice arriva, i test sono già pronti.

Puoi anche tenere un compagno per i test attivo per tutta la sessione, rilanciando la suite ogni volta che un coding teammate segna un task come completo.

Review Agent

Il review agent legge i diff e segnala bug, problemi di stile, casi limite mancanti e problemi di sicurezza. Suddividere la review su due compagni con lenti diverse — uno per la sicurezza, uno per le performance — funziona particolarmente bene, con il lead che combina i loro riscontri.

Se hai già scritto una definizione di subagent per il tuo progetto, il compagno ne eredita automaticamente strumenti e system prompt.

Documentation Agent

Il documentation agent scrive docstring, aggiornamenti al README e documentazione più estesa come note di architettura o reference API. È un buon candidato per essere l’ultimo compagno a girare — quando coding e test sono finiti, la forma finale del lavoro è chiara.

Perché la specializzazione migliora i risultati

Una sessione generalista deve tenere in contesto implementazione, test, documentazione e feedback di review contemporaneamente. Un compagno specializzato carica solo ciò che serve, mantenendo il suo contesto piccolo e il ragionamento focalizzato. La specializzazione semplifica anche il debug: quando qualcosa va storto, sai esattamente quale sessione controllare.

Sviluppo in parallelo con gli Agent Teams

Il parallelismo è l’intero punto di un agent team.

Quando il lead ha suddiviso il lavoro in attività e avviato i compagni, tutti girano contemporaneamente. Ogni compagno è una sessione Claude Code separata, quindi il lavoro non è in coda dietro una singola finestra di contesto. Il tempo totale per finire una feature multi-parte scende dalla somma di tutte le parti al tempo della parte più lenta.

Ecco tre combinazioni che funzionano particolarmente bene in parallelo.

• Frontend e backend in parallelo: quando costruisci una nuova feature che usa entrambi i layer, il compagno backend può creare l’endpoint API mentre il compagno frontend costruisce il componente che lo consuma. I due si coordinano con messaggi diretti. Appena il backend decide la forma della risposta, la invia al frontend e entrambi continuano a lavorare senza aspettare che l’altro finisca del tutto.
• Implementazione e test in parallelo: il compagno di coding scrive l’implementazione mentre il compagno di test scrive i test rispetto al contratto concordato. Quando il compagno di coding segna il task come completo, i test sono già pronti da eseguire. È molto più veloce della sequenza usuale di scrivere prima il codice e poi aggiungere i test alla fine.
• Documentazione e code review in parallelo: una volta che un compagno di coding finisce una parte del lavoro, il compagno per la documentazione può iniziare a scrivere docstring e aggiornamenti al README mentre il compagno di review legge il diff per bug e problemi di stile. Nessuno blocca l’altro e entrambi producono output che il lead combinerà.

Il limite riguarda i conflitti sui file. Due compagni che scrivono sullo stesso file allo stesso tempo si sovrascriveranno, quindi il lead deve dividere il lavoro per file o per modulo. Finché le parti sono pulite, puoi far girare tanti compagni in parallelo quanti la tua lista di attività supporta.

Claude Code Agent Teams per codebase grandi

Le codebase grandi sono il contesto in cui gli agent teams sono più una necessità che un nice-to-have.

Un repository con centinaia o migliaia di file non può stare in una singola finestra di contesto. Una sessione solitaria che lavora su una codebase grande spende gran parte del budget solo per riscoprire il codice.

Con gli Agent teams, ogni compagno carica solo i file rilevanti per la sua parte di lavoro, quindi la finestra di contesto per compagno rimane piccola e focalizzata. Il team nel suo insieme può ragionare sull’intero repository, ma nessuna singola sessione deve farlo da sola.

Questo conta soprattutto in tre situazioni:

• Modifiche trasversali: una rifattorizzazione che tocca dozzine di file su più moduli è difficile da gestire per una singola sessione senza perdere il filo. Suddividerla per modulo e assegnare ogni modulo a un compagno mantiene gestibile lo scope di ciascuno.
• Audit sull’intero repository: una review di sicurezza o un audit di performance su una codebase grande trae beneficio dall’eseguire più compagni in parallelo, ciascuno su una parte diversa del repo. Il lead poi combina i risultati in un unico report.
• Progetti di lunga durata: un progetto di più settimane accumula contesto che una singola sessione non può contenere. Gli agent teams ti permettono di spezzare il lavoro in checkpoint, con ciascun checkpoint assegnato a un compagno che non deve ricordare tutto ciò che è venuto prima.

C’è un costo.

Ogni compagno è una sessione Claude Code completa con la propria finestra di contesto, quindi l’uso di token scala linearmente con la dimensione del team. Un team di quattro usa circa quattro volte i token di una singola sessione per lo stesso lavoro. Alcune stime lo danno anche più alto. Lo scambio è un tempo di parete più rapido e una maggiore profondità per aspetto, che di solito ripaga su lavori che una singola sessione non potrebbe realisticamente finire.

Più il progetto è grande, più guadagni con gli Agent teams. Ma non abusarne: per una piccola correzione di bug, una singola sessione è più economica e altrettanto efficace.

Agent Teams e Claude Tag

Gli agent teams non sono l’unico ambito in cui Anthropic sta ripensando come l’AI si inserisce nei workflow di team.

Claude Tag è una funzionalità separata che porta Claude in Slack come partecipante organizzativo condiviso. Tagghi @Claude in un canale e Claude si prende in carico del lavoro usando gli strumenti della tua organizzazione e il contesto del canale. Ricorda ciò che è stato discusso, fa follow-up in autonomia e lavora sotto l’identità della tua organizzazione.

Le due funzionalità risolvono problemi di coordinamento diversi. Gli agent teams coordinano più sessioni di Claude Code sulla macchina di uno sviluppatore per un compito focalizzato. Claude Tag coordina un’identità Claude unica tra un team di persone in Slack nell’arco di giorni e settimane. Ma la direzione è la stessa: l’AI si sta spostando da strumento usato in isolamento da una singola persona a partecipante che opera dentro il workflow esistente di un team.

Questo cambia ciò in cui l’AI deve eccellere.

Un assistente singolo deve essere un forte generalista, ma un sistema coordinato deve essere un forte specialista che sa pianificare, passare il testimone, chiedere aiuto e rimanere allineato con altri agenti e umani. Gli agent teams lo fanno per i workflow di Claude Code, e Claude Tag lo rende visibile nel workflow di Slack.

Best practice per creare Agent Teams

Una buona configurazione di agent team è soprattutto una buona preparazione iniziale. Il team in sé è veloce, ma il tempo che perderai è in attività mal definite e ruoli ambigui.

Ecco alcune best practice:

• Definisci chiaramente i ruoli: ogni compagno dovrebbe avere un solo focus e un solo set di file di cui è proprietario. Quando crei un compagno, digli esattamente di cosa è responsabile, di cosa non è responsabile e quali file o moduli può toccare. Ruoli vaghi producono lavori sovrapposti e lavori sovrapposti producono conflitti in merge.

• Scomponi i task prima di parallelizzare: pianifica prima, parallelizza dopo. Fai un pass di pianificazione per suddividere il lavoro in attività con input, output e dipendenze chiari, poi consegna il piano al team per l’esecuzione. Un piano costa qualche migliaio di token, ma un team che va nella direzione sbagliata può costarne centinaia di migliaia.

• Condividi gli standard tramite CLAUDE.md: ogni compagno legge il file CLAUDE.md nella directory di lavoro quando parte, quindi metti lì le convenzioni condivise, inclusi stile del codice, layout dei file, approccio ai test e formato dei messaggi di commit.

• Inserisci checkpoint di review: controlla l’avanzamento dei compagni, reindirizza quelli fuori rotta e rivedi l’output del lead prima di accettarlo. Per i task rischiosi, richiedi l’approvazione del piano prima che qualsiasi compagno apporti modifiche. Questo costringe il compagno a mostrare prima il piano e ad aspettare l’approvazione del lead.

• Limita la dimensione del team: inizia con tre-cinque compagni per la maggior parte dei workflow. Oltre, l’overhead di coordinamento cresce più velocemente del guadagno in parallelismo.

• Evita conflitti sui file: dividi il lavoro per file o per moduli in modo che ogni compagno sia chiaramente separato. Due compagni che modificano lo stesso file si sovrascriveranno a vicenda. Se un task richiede davvero che più compagni lavorino sullo stesso file, sequenzialo invece di parallelizzarlo.

• Pre-approva le operazioni comuni: i prompt di permesso dai compagni risalgono al lead e un team con quattro compagni può generare quattro volte i prompt. Prepara la lista permissions.allow prima di avviare il team così che operazioni di routine come leggere file o eseguire test non interrompano il lavoro.

• Abbina il modello al ruolo: esegui il lead su un modello più forte come Opus, dato che il coordinamento beneficia di un ragionamento più profondo, ed esegui i compagni su Sonnet per l’esecuzione.

Ecco la versione breve: crea un piano di lavoro dettagliato, fai il brief al team come faresti con un piccolo gruppo di junior engineer, dai loro scope chiari e standard condivisi e controlla il lavoro alla fine. Più la tua impostazione si avvicina a come opera un vero team di engineering, meglio renderà l’agent team.

Claude Code Agent Team in pratica

Ecco tutto, dall’inizio alla fine.

Ti guiderò attraverso un piccolo esempio: una REST API "hello world" in FastAPI che legge un messaggio da un database SQLite, più una piccola pagina HTML che chiama l’API e mostra il risultato. L’app ha una route backend, uno strato database, un frontend statico e una documentazione nel readme, il che la rende adatta a un team di quattro persone.

Abilita gli agent teams

Gli agent teams sono una funzionalità sperimentale e sono disattivati di default. Li attivi impostando una variabile d’ambiente, o nella tua shell o nel file di impostazioni di Claude Code.

Il file delle impostazioni si trova in ~/.claude/settings.json. Aprilo e aggiungi:

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

Se preferisci non modificare il file delle impostazioni, puoi impostare la variabile nella shell prima di avviare Claude Code:

export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

Entrambi gli approcci funzionano. Una volta impostata la variabile, Claude Code riconoscerà i prompt relativi ai team e avvierà lo strato di coordinamento quando glielo chiedi.

Avvia Claude Code e fai il brief al team

Crea una directory vuota per il progetto e avvia Claude Code al suo interno:

mkdir hello-api && cd hello-api
claude

Ora fai il brief al team. Il prompt è in linguaggio naturale, ma più sei specifico su ruoli e confini, meglio lavorerà il team. Ecco il prompt per l’API hello world:

Create an agent team to build a small "hello world" REST API.

The project is a FastAPI service that returns a greeting from a SQLite
database, plus a tiny HTML page that calls the API and shows the result.
- One teammate on the database: create app/db.py with a sqlite3 connection
  to a greetings.db file. Define a get_greeting() function that returns
  the message column from the first row. On import, create the table if
  it doesn't exist and seed it with "Hello, World!" if empty.
- One teammate on the backend: build a FastAPI app in app/main.py with
  a GET /greeting endpoint that calls get_greeting() from app/db.py.
  Add permissive CORS and mount the static/ directory at the root so
  the HTML page is served from the same origin.
- One teammate on the frontend: build static/index.html as a single page
  that fetches /greeting on load, shows a spinner while loading, displays
  the greeting in a centered card on success, and shows an error message
  on failure. Inline the CSS and JavaScript.
- One teammate on docs: write README.md with installation, run, and
  open-in-browser steps, plus an API reference table. Also create
  requirements.txt with fastapi and uvicorn[standard].
Use Sonnet for each teammate. Require plan approval before any teammate
makes changes.

Tre cose da notare in questo prompt. I confini per file (app/db.py, app/main.py, static/index.html, README.md, requirements.txt) prevengono sovrapposizioni. La scelta del modello (Sonnet) mantiene gestibili i costi in token. E plan approval obbliga ogni compagno a mostrare il proprio piano prima di scrivere codice, dandoti un checkpoint per reindirizzare chi ha capito male il brief.

Guarda il team al lavoro

Dopo l’invio del prompt, il lead suddivide il lavoro in attività e avvia i compagni. Vedrai un pannello agenti comparire in basso nel terminale con una riga per ogni compagno.

Agenti creati

Ogni riga mostra il nome del compagno e cosa sta facendo. Il lead popola la lista di attività condivisa e assegna o rilascia task in base alle dipendenze. Il compagno backend aspetta lo strato database perché importa get_greeting() da lì. Il compagno per i docs aspetta finché il resto non è abbastanza avanti da poterlo descrivere con precisione.

Puoi anche vedere la lista di attività. Premi Ctrl+T per mostrarla o nasconderla. La lista mostra ogni task, il suo stato (in attesa, in corso o completato) e quale compagno lo possiede.

Sposta tra i compagni

Ogni compagno è una sessione completa di Claude Code e puoi parlare con ciascuno di loro.

Nel pannello agenti, usa le frecce su e giù per selezionare un compagno, poi premi Enter per aprire la sua trascrizione. Ora sei nella sessione di quel compagno, e tutto ciò che digiti va a lui, non al lead. È così che puoi dare a un compagno specifico contesto aggiuntivo o reimpostare il suo approccio senza coinvolgere il resto del team.

Premi Esc per tornare al lead.

Reindirizza un compagno fuori rotta

A volte un compagno fraintende il brief o si disperde su lavoro che non dovrebbe fare. Te ne accorgi controllando il suo piano durante l’approvazione o notando una deriva nei progressi nel pannello agenti.

Se usi l’approvazione del piano, il compagno si ferma dopo la pianificazione e ti mostra la proposta prima di scrivere qualsiasi file. Ecco come appare per l’agente database:

Approvazione dell’agente database

Puoi leggere lo schema e l’approccio proposti, quindi approvare o rifiutare con feedback. Se il piano manca di qualcosa, puoi rispondere con qualcosa tipo "Usa SQLAlchemy invece di sqlite3 puro" e il compagno ripianificherà.

Se noti un problema dopo che un compagno ha già iniziato a lavorare, selezionalo nel pannello agenti, premi Enter per aprire la sua sessione e mandagli un messaggio. Puoi anche premere x su un compagno selezionato per fermarlo, oppure chiedere al lead di avviare un compagno sostitutivo se quello attuale è completamente bloccato.

Concludi e rivedi

Quando tutti i compagni finiscono i task, il lead ti riporta un breve riepilogo e i comandi necessari per eseguire il progetto.

Istruzioni finali del lead

A questo punto, rivedi il lavoro. Puoi aprire i file generati nel tuo editor e leggere i diff.

Il file app/main.py generato

Puoi anche ispezionare il database che l’agente database ha creato e popolato.

La tabella greetings

Quindi installa le dipendenze, esegui uvicorn app.main:app --reload e apri http://localhost:8000 nel browser per confermare che l’intera stack funzioni end-to-end.

App finale

Se vuoi modifiche, dì al lead cosa aggiustare e lui o risolverà il problema da solo o avvierà un nuovo compagno per gestirlo. Quando sei soddisfatto del risultato, puoi chiedere al lead di fare il commit delle modifiche. Il lead spegne i compagni quando la sessione termina e la configurazione del team viene ripulita.

È tutto!

Conclusione

I Claude Code Agent Teams riguardano due cose: specializzazione e coordinamento. Ogni compagno ha la propria parte di lavoro e la propria finestra di contesto. Il lead li mantiene allineati, la lista di attività li tiene in sincronia e i messaggi diretti evitano che debbano aspettare te per fare da tramite tra sessioni.

La visione d’insieme è che lo sviluppo assistito dall’AI si sta spostando dal singolo al coordinato. Gli agent teams sono come questo cambiamento si manifesta oggi in Claude Code, e lo stesso schema compare in Claude Tag per Slack. Gli sviluppatori che si abituano ora a questo modo di lavorare passeranno meno tempo a combattere con i limiti di contesto e più tempo a produrre funzionalità reali.

Vuoi ottenere una certificazione in Generative AI? Ecco le migliori certificazioni in Generative AI nel 2026 con i migliori corsi, consigli per la preparazione e FAQ.