Claude Code Projects in beta: team di agenti che pianificano e coordinano il lavoro in parallelo

Il rapporto tra i team di agenti di Claude Code e la beta dei progetti

La annuncio dei progetti riprogettati introduce un progetto organizzato attorno al lavoro in corso: un coordinatore dirige i thread, la memoria condivisa trasferisce il contesto tra di essi e una libreria raccoglie file e artefatti.

Il coordinatore ha un ruolo definito. Delimita le richieste, delega il lavoro a thread paralleli, esamina ciò che questi producono e riunisce i risultati. Ogni thread svolge il proprio lavoro in una sessione cloud di Claude Code.

I team di agenti esistevano già prima di questo lancio. Claude Code v2.1.32, rilasciata il 5 febbraio 2026, li ha introdotti come anteprima di ricerca per la collaborazione tra più agenti. Quel rilascio descriveva la funzionalità come caratterizzata da un consumo elevato di token e richiedeva una variabile d'ambiente sperimentale.

La distinzione è importante quando si leggono le istruzioni di configurazione. La funzionalità CLI di febbraio e la beta dei progetti di settembre hanno modalità di accesso documentate diverse; l'annuncio dei progetti non indica il flag CLI sperimentale come requisito di attivazione.

Per orientarsi tra queste funzionalità, centro delle guide di Claude Code offre un punto di partenza. Mantieni distinti il coordinatore del progetto, i thread cloud e i sottoagenti quando decidi quale flusso di lavoro è adatto a un'attività.

Accesso e configurazione al 21 settembre

L'accesso iniziale era limitato ad abbonati Pro e Max selezionati che utilizzavano sessioni cloud di Claude Code e non avevano progetti web o desktop esistenti. Era previsto un accesso più ampio per Pro e Max, seguito dall'accesso per Team ed Enterprise.

Il documento non stabilisce che il rilascio più ampio fosse terminato entro il 21 settembre. Un abbonamento, quindi, non dovrebbe essere considerato di per sé una prova che la beta dei progetti riprogettati fosse disponibile per un determinato account.

Cosa si configura

La configurazione del progetto inizia con un obiettivo e un repository o un contesto. Comprende l'ambiente cloud, i connettori, i plugin, le istruzioni e il modello.

Per un'attività di sviluppo, un obiettivo utile descriverebbe il risultato desiderato e i vincoli importanti durante l'implementazione. Ad esempio, potresti richiedere una funzionalità che coinvolga un'API e la relativa interfaccia, quindi specificare i criteri di accettazione e le aree del codice che richiedono particolare attenzione. È un modo suggerito per presentare il lavoro al coordinatore, non una garanzia documentata su come suddividerà la richiesta.

Puoi guidare il lavoro tramite la chat del progetto o i singoli thread, anche da un telefono. La chat del progetto offre uno spazio per dirigere il lavoro complessivo; un singolo thread offre uno spazio per guidarne una parte specifica.

Cosa resta da specificare

L'annuncio del lancio non specifica una versione minima della CLI, un limite numerico di thread simultanei o un prezzo separato per la beta. Inoltre, non stabilisce che l'accesso fosse stato completato per tutti i livelli di abbonamento idonei entro la data limite della pubblicazione.

Queste lacune sono importanti per la pianificazione. Evita di costruire un flusso di lavoro basato su un numero presunto di thread simultanei o su una data di rilascio presunta.

Come vengono eseguiti i thread paralleli e dove l'integrazione resta importante

Il coordinatore delimita la richiesta e delega il lavoro a thread paralleli. Ogni thread viene eseguito come sessione cloud di Claude Code con un proprio branch e una propria copia del repository, fornendo copie di lavoro separate per il lavoro parallelo.

I thread possono a loro volta utilizzare sottoagenti, cicli e flussi di lavoro. Il progetto ha quindi più di un livello di delega: il coordinatore dirige i thread e un thread può delegare ulteriore lavoro ai sottoagenti.

Suddividi il lavoro per risultato da consegnare

Un modo pratico per preparare una richiesta è individuare risultati da consegnare separabili. Per una funzionalità proposta, potrebbe trattarsi dell'implementazione dell'API, delle modifiche all'interfaccia e della revisione. Sono esempi di delimitazione delle attività, non una regola di scomposizione garantita.

Assegna a ogni risultato da consegnare una condizione di completamento chiara. Se due parti dipendono dalla stessa interfaccia, descrivi quel contratto condiviso nelle istruzioni del progetto, in modo che il coordinatore ne disponga quando delimita il lavoro.

Il precedente annuncio dei team di agenti di febbraio sottolineava in particolare le attività indipendenti che richiedono molta lettura, come le revisioni della base di codice. Questo orientamento resta utile quando si sceglie il lavoro da parallelizzare: considera quanto coordinamento richiede un'attività prima di suddividerla in più incarichi.

I branch separati non eliminano i conflitti

L'annuncio dei progetti lascia esplicitamente le modifiche al codice sovrapposte soggette alla risoluzione dei conflitti di merge. Branch e copie del repository separati non eliminano il lavoro di integrazione quando i thread modificano lo stesso codice.

Per questo motivo, la revisione dovrebbe includere il modo in cui gli output si integrano tra loro. Una possibile lista di controllo per la revisione consiste nel verificare che le interfacce siano coerenti, che le modifiche sovrapposte siano state conciliate e che il risultato complessivo soddisfi l'obiettivo originale.

Il documento non stabilisce un flusso di lavoro per coordinare modifiche tra più repository. Il fatto che un thread abbia una propria copia del repository non è una prova sufficiente del supporto all'orchestrazione tra repository, quindi questa capacità dovrebbe restare una questione aperta.

Memoria condivisa e libreria del progetto

I thread contribuiscono alla memoria condivisa del progetto, mentre la libreria del progetto raccoglie i file caricati e gli artefatti generati. Questi offrono due forme di contesto persistente del progetto: la memoria alimentata dai thread e una raccolta di materiali associati al lavoro.

Per gli sviluppatori, questa distinzione aiuta a organizzare gli input. Un documento di progettazione o un file di riferimento trova naturalmente posto tra i materiali del progetto; le informazioni scoperte durante lo svolgimento del lavoro possono contribuire alla memoria condivisa.

Pianifica ciò che servirà al lavoro futuro

Quando prepari un progetto, valuta quali vincoli debbano rimanere disponibili durante il lavoro. Alcuni esempi sono il comportamento previsto di un'interfaccia, le convenzioni del repository o le decisioni che influiscono su più risultati da consegnare.

Questi esempi sono raccomandazioni per organizzare un progetto. Il documento di lancio non specifica il formato esatto della memoria condivisa né garantisce che ogni dettaglio di ogni thread venga conservato.

Inoltre, non definisce i periodi di conservazione, i limiti di archiviazione o regole precise su quando le informazioni memorizzate raggiungono un altro thread. L'affermazione supportata è più circoscritta: i thread contribuiscono alla memoria condivisa e la libreria raccoglie i file caricati e gli artefatti generati.

Esamina gli artefatti generati nell'ambito della valutazione del risultato assemblato. La loro presenza nella libreria dimostra che vengono raccolti lì; da sola, non ne dimostra la correttezza.

Subagenti e precedente flusso di lavoro CLI con team di agenti

I subagenti di Claude Code supportavano lo sviluppo parallelo già prima della beta dei progetti. L'annuncio di Anthropic del 29 settembre 2025 includeva l'esempio di un subagente che sviluppava un'API backend mentre l'agente principale sviluppava il frontend.

Nei progetti riprogettati, un thread può invocare subagenti. I subagenti fanno quindi parte delle possibilità di esecuzione disponibili all'interno di un thread, mentre il coordinatore gestisce la definizione dell'ambito, la delega e l'assemblaggio a livello di progetto.

La guida ai subagenti è una risorsa complementare utile quando si pianifica questo livello interno di delega. Mantieni la sua configurazione separata dalla questione dell'accesso del tuo account alla beta dei progetti.

Il flag sperimentale della CLI ha un ambito specifico

La versione v2.1.32 di febbraio richiedeva questa variabile d'ambiente per la sua anteprima di ricerca dei team di agenti:

CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

L'annuncio dei progetti di settembre non indica questa variabile come requisito per attivare la beta. Abilitarla non va quindi presentato come un'istruzione per ottenere l'accesso ai progetti riprogettati.

Il lancio di febbraio documentava anche la possibilità di assumere direttamente il controllo tramite Maiusc+Freccia su/giù o tmux. Si tratta di comandi disponibili al lancio per il precedente flusso di lavoro con team di agenti; non si deve presumere che descrivano l'interfaccia dei progetti riprogettati.

Evita istruzioni obsolete per la configurazione dei subagenti

Di v2.1.198 del 1 luglio 2026, la /agents procedura guidata era stata rimossa. Il registro delle modifiche datato invita gli utenti a chiedere a Claude di creare o gestire subagenti, oppure a modificare .claude/agents/ direttamente.

Una guida di settembre dovrebbe usare questi metodi anziché indicare ai lettori di aprire la vecchia procedura guidata. Questo è un esempio concreto del motivo per cui le informazioni sulle versioni corredate di data sono importanti quando si combinano istruzioni per progetti, team di agenti e subagenti.

Utilizzo, scelta dei modelli ed esecuzione locale

Le sessioni di progetto parallele consumano più rapidamente i limiti di utilizzo. L'annuncio dei progetti consente agli utenti di controllare l'utilizzo del progetto e scegliere i modelli e il livello di elaborazione del coordinatore e degli agenti esecutori, ma non fornisce un moltiplicatore numerico dei costi per il lavoro parallelo.

Questo rende la definizione dell'ambito una scelta importante nella pianificazione. Prima di aggiungere thread, valuta se il lavoro contenga abbastanza parti indipendenti da giustificare l'attività aggiuntiva. Per valutare il flusso di lavoro, considera le scelte disponibili per modello e livello di elaborazione insieme alle informazioni sull'utilizzo del progetto.

La modifica dei limiti di settembre

La Avviso sui limiti settimanali di Claude Code indica che, dal 14 settembre, i limiti settimanali sono diventati permanentemente superiori del 25% rispetto ai livelli precedenti alla promozione per Pro, Max, Team ed Enterprise con tariffazione per postazione.

La precedente promozione del 50% si è svolta dal 13 maggio al 13 settembre, terminando alle 11:59 PM PT. Non modificava i limiti di cinque ore ed escludeva Free e le postazioni Enterprise con tariffazione a consumo.

Claude Code mette a disposizione questo comando CLI per controllare l'utilizzo:

/usage

La guida ai limiti di frequenza può aiutare a comprendere i concetti correlati all'utilizzo. Limiti settimanali più elevati non eliminano l'avvertenza dell'annuncio dei progetti secondo cui le sessioni parallele consumano più rapidamente i limiti.

L'esecuzione locale era ancora prevista per il futuro

L'annuncio di settembre descriveva l'esecuzione locale come una funzionalità in arrivo. Al 21 settembre, il flusso di lavoro dei progetti documentato utilizzava sessioni cloud, con la possibilità di guidare il lavoro tramite la chat del progetto o i singoli thread.

Un flusso di lavoro locale di Claude Code e la beta dei progetti cloud riprogettati vanno quindi valutati separatamente. Il documento non fornisce una data di lancio dei progetti locali né attesta il completamento della distribuzione dell'esecuzione locale.

Punti chiave

• I progetti riprogettati sono stati lanciati in beta il 17 settembre, con un coordinatore che definisce l'ambito delle richieste, delega a thread paralleli, esamina gli output e assembla i risultati.
• I team di agenti di Claude Code precedono la beta: la versione v2.1.32 ha introdotto l'anteprima di ricerca separata per la CLI il 5 febbraio.
• Ogni thread di progetto dispone di una propria sessione cloud, di un proprio branch e di una propria copia del repository; le modifiche sovrapposte richiedono comunque la risoluzione dei conflitti di merge.
• I thread contribuiscono alla memoria condivisa del progetto e una libreria raccoglie i file caricati e gli artefatti generati.
• L'accesso iniziale era limitato ad abbonati Pro e Max selezionati che soddisfacevano le condizioni annunciate. Il lavoro parallelo consuma più rapidamente i limiti e l'esecuzione locale era ancora prevista per il futuro.

FAQ

Come posso accedere alla beta dei progetti riprogettati?

L'accesso iniziale comprendeva abbonati Pro e Max selezionati che utilizzavano le sessioni cloud di Claude Code e non avevano progetti web o desktop esistenti. Era previsto un accesso più ampio per Pro e Max, seguito da Team ed Enterprise, ma il documento non attesta il completamento di una distribuzione più ampia entro il 21 settembre.

Qual è la differenza tra progetti, team di agenti e subagenti?

Un progetto riprogettato dispone di un coordinatore che dirige i thread delle sessioni cloud e ne assembla i risultati. I team di agenti sono stati introdotti in precedenza come anteprima di ricerca separata per la CLI, mentre i subagenti eseguono il lavoro delegato e possono essere invocati all'interno dei thread di progetto.

Cosa succede quando due thread modificano lo stesso codice?

Ogni thread di progetto lavora sul proprio branch e sulla propria copia del repository. Le modifiche al codice che si sovrappongono richiedono comunque la risoluzione dei conflitti di merge; l'annuncio dei progetti non promette una riconciliazione automatica.

I thread di progetto possono essere eseguiti localmente e come posso guidarli?

Al 21 settembre, la beta documentata utilizzava sessioni cloud di Claude Code e l'esecuzione locale era stata annunciata come funzionalità in arrivo. Puoi guidare il lavoro tramite la chat del progetto o i singoli thread, anche da un telefono.