"Sto usando Claude Code, ma man mano che la scala cresce, il contesto va in overflow e la precisione cala."
"Alla fine, sono le mie stesse mani che danno istruzioni di correzione all'AI a diventare il collo di bottiglia più grande."
Molte persone probabilmente si sono bloccate a questo punto. All'inizio ero come voi, gettavo codice, test e discussioni di progettazione tutti in un'unica sessione, guardando la precisione di Claude diminuire man mano che la cronologia si espandeva.
Quello che ho capito recentemente è che Claude Code stesso fornisce ufficialmente tre meccanismi per eseguire più sessioni in parallelo.
Inoltre, questi tre sono simili ma distinti; confonderli può causare incidenti. Al contrario, se li suddividete per ruolo, potete passare al "controllo" senza scrivere voi stessi una singola riga di codice.
Oggi organizzerò questi tre meccanismi e il modo corretto per fissare i confini dei ruoli, controllando le informazioni primarie dalla documentazione ufficiale.
Nello specifico, lo suddividerò in una configurazione in cui 8 sessioni sono disposte su tre livelli: Comando, Implementazione e Qualità.
Come bonus, userò anche le informazioni primarie per spiegare perché spiegazioni comuni come "scrivere gli ID dei ruoli in CLAUDE.md per cambiare" o "condividere la memoria con SQLite" sono leggermente fuori dal meccanismo ufficiale.
Il mio nome è tatsuki (@nobel_824).
Supporto l'utilizzo dell'AI per le piccole e medie imprese, aiutando con l'implementazione aziendale di Claude / Codex mentre uso Claude Code personalmente tutto il giorno. L'operazione parallela è un'area che tocco ogni giorno sia per lavoro che per progetti personali.
Articolo correlato: Introduzione a Vibe Coding: 6 Passi per Non Programmatori per Creare App con Claude. L'era della Produzione Interna in un Weekend
https://note.com/nobel/n/n8192ec07d689
1. Perché "Mettere Tutto in Una Sessione" Fallisce
La prima trappola è sovraccaricare una singola sessione con troppe informazioni. Non importa quanto sia intelligente il modello Claude, incontra dei limiti strutturali.
Nello specifico, si incontrano questi tre problemi:
- Contaminazione del Contesto: Quando codice di implementazione, test, cronologia di debug e discussioni di progettazione si mescolano nello stesso contesto, le basi del ragionamento diventano fangose e la precisione cala.
- Conflitto di Istruzioni: Se "implementa con priorità alla velocità" e "sii severo con la sicurezza" esistono nello stesso posto, i giudizi diventano a metà strada.
- Gonfiamento dei Token: Caricare ogni volta una cronologia massiccia è uno spreco sia di tempo che di costi.
La soluzione è l'idea di "diventare un unico comandante e allineare Claude specializzati." È simile a un CTO che ha un Tech Lead e un Backend Lead, ma la cosa importante non è l'atmosfera: è utilizzare correttamente i meccanismi ufficiali di Claude Code.
Un'azione che puoi fare oggi: Pensa alla tua sessione attuale e verifica se "implementazione", "ricerca" e "revisione" coesistono in un unico contesto. Se è così, questo è il tuo punto di partenza per suddividerle.
2. Correggere i "Tre Meccanismi Paralleli" Forniti Ufficialmente
Questo è il cuore dell'articolo. Claude Code ha tre meccanismi per il parallelismo, ognuno con un ambito diverso.
Il primo è subagent (un'AI helper che esegue in un contesto separato dalla conversazione principale). Esegue compiti secondari come ricerche o revisioni usando la propria finestra di contesto, system prompt dedicato e permessi strumentali limitati, restituendo solo un riepilogo dei risultati alla sessione principale. Il punto chiave è che i subagent vengono eseguiti all'interno della stessa sessione, riferiscono solo al principale, e i subagent non parlano tra loro (Documentazione Ufficiale).
Il secondo è agent teams (un meccanismo in cui più sessioni di Claude Code collaborano come un team). Una sessione diventa il team lead e genera compagni di squadra, collaborando tramite una lista di attività condivisa e una casella di posta. A differenza dei subagent, i compagni di squadra possono inviarsi messaggi direttamente. Questa è una funzionalità sperimentale ed è disabilitata per impostazione predefinita. Devi impostare CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 e usare Claude Code v2.1.32 o successivo (Documentazione Ufficiale).
Il terzo è git worktree (una funzionalità Git che permette più directory di lavoro dallo stesso repository). Avviando con claude --worktree feature-auth, Claude si avvia in un ambiente isolato su un ramo/directory diverso. Se ne esegui un altro in un terminale diverso, possono funzionare in parallelo senza pestarsi i file a vicenda (Documentazione Ufficiale). Quando si utilizza l'app desktop, un worktree viene creato automaticamente per ogni nuova sessione.
Ecco una tabella che confronta i tre:
Non vi confonderete se ricordate che worktree gestisce l'isolamento dei file, mentre subagent e agent team gestiscono il coordinamento del lavoro stesso.
Un'azione che puoi fare oggi: Per prima cosa, prova a digitare claude --worktree bugfix-test per familiarizzare con l'avvio di una sessione isolata. Quando hai finito dopo aver apportato modifiche, ti chiederà se mantenere o eliminare il worktree.
3. Pratica: Distribuire 8 Sessioni in una "Struttura a 3 Livelli"
Come si traducono questi tre meccanismi in 8 sessioni? Io uso una disposizione divisa in livelli Comando, Esecuzione e Qualità.
Livello Comando/Progettazione (2 Sessioni)
- Sessione 1 PM (Project Manager): Gestione del progresso generale, suddivisione dei compiti, reportistica agli umani.
- Sessione 2 Architetto: Decide la coerenza tecnica e la struttura delle directory. Richiede l'approvazione del piano per produrre progetti senza scrivere codice.
Livello Esecuzione/Implementazione (4 Sessioni)
- Sessione 3 Frontend: Creazione di componenti, modifiche all'interfaccia utente.
- Sessione 4 Backend: Implementazione degli endpoint, ottimizzazione delle query.
- Sessione 5 Infra/DevOps: Manutenzione di Docker, CI/CD.
- Sessione 6 Sicurezza: Verifiche delle vulnerabilità, rafforzamento dell'autenticazione.
Livello Qualità/Manutenzione (2 Sessioni)
- Sessione 7 QA/Reviewer: Revisioni delle PR, segnalazione di casi limite.
- Sessione 8 Technical Writer: Manutenzione di README, documentazione API.
Ci sono tre consigli per questa disposizione: Isolate le quattro sessioni del livello di implementazione con worktree in modo che non si pestino i file a vicenda. Fissate i ruoli per il livello di qualità come definizioni di subagent o compagni di squadra dell'agent team. E fate in modo che ogni sessione si scambi informazioni tramite file Markdown condivisi (note di progettazione o risultati di revisione). L'Architetto aggiorna il progetto, il livello di implementazione si muove in base a quello e il Reviewer scrive i risultati. Gli umani devono solo dare istruzioni a ogni sessione attivata da questi aggiornamenti di file.
Una nota: la linea guida ufficiale per un agent team è di 3–5 persone, quindi non infilate tutte le 8 in un unico team contemporaneamente (Documentazione Ufficiale). È più sicuro combinare sessioni isolate con worktree con un agent team di 3–5 persone e subagent secondo necessità per raggiungere un totale di 8 lavoratori.
Un'azione che puoi fare oggi: Scegli due ruoli tra gli 8 sopra che sembrano facili da separare nel tuo progetto attuale. In molti casi, Architetto e Reviewer sono i primi punti di divisione.
4. Fissa i Confini dei Ruoli con "Definizioni di Subagent", Non "CLAUDE.md"
Lasciatemi correggere un malinteso comune sull'operazione parallela. Potreste vedere spiegazioni come "Scrivi i ruoli (ID: arch, ID: dev-main...) in CLAUDE.md e cambia persona all'avvio", ma questo meccanismo in realtà non esiste.
CLAUDE.md è un file di istruzioni condiviso che Claude Code legge all'avvio. Tuttavia, la documentazione ufficiale afferma chiaramente che CLAUDE.md è "contesto, non un'impostazione forzata." Poiché viene passato come messaggio utente dopo il system prompt, la conformità rigorosa non è garantita. Se volete assolutamente fermare qualcosa, dovreste usare gli hook (Documentazione Ufficiale). Pensatelo come un forte suggerimento piuttosto che una "costituzione" assoluta.
Allora, dove si fissano i ruoli? La risposta è definizioni di subagent. Posizionando un file sotto .claude/agents/ con un nome, descrizione, strumenti disponibili e modello nel frontmatter, completate un esperto riutilizzabile. Ecco un esempio minimo:
name: security-reviewer
description: Controlla criticamente il codice dal punto di vista dell'autenticazione, della convalida dell'input e della gestione delle sessioni.
tools: Read, Grep, Bash
model: sonnet
Sei un reviewer senior di sicurezza. Concentrati sulla gestione dei token,
sulla gestione delle sessioni e sulla convalida dell'input, e segnala i risultati con livelli di gravità.
Inoltre, queste definizioni possono essere chiamate per nome come compagni di squadra negli agent team. Se chiedi di "impostare un compagno di squadra con il tipo di agente security-reviewer per controllare il modulo di autenticazione", diventa un membro che eredita gli strumenti e il modello da quella definizione (Documentazione Ufficiale). Il design ti permette di scrivere un ruolo una volta come definizione di subagent e riutilizzarlo sia come subagent che come membro del team.
Esempio di prompt da provare (far creare a Claude una definizione di ruolo):
Crea una definizione di subagent da posizionare in .claude/agents/.
Il ruolo è "un reviewer che segnala problemi di prestazioni e query N+1 nel codice di implementazione."
Includi nome / descrizione / strumenti / modello nel frontmatter,
e scrivi il corpo nella persona di un ingegnere senior.
5. Costruire un Team "Architetto-Reviewer" con gli Agent Team per Aumentare la Precisione
Una configurazione che è altamente efficace nell'operazione parallela è impostare separatamente un "creatore" e un "dubbioso". Questa non è solo teoria; la documentazione ufficiale fornisce esempi reali.
Nell'esempio ufficiale di "Revisione del Codice in Parallelo", per una singola PR, vengono impostati tre compagni di squadra per sicurezza, prestazioni e copertura dei test, ognuno che guarda da una prospettiva diversa mentre il lead integra i risultati. Inoltre, nell'esempio "Ipotesi in Competizione", a cinque compagni di squadra vengono assegnate diverse ipotesi per un bug per discutere e confutare le teorie degli altri, trattando la teoria sopravvissuta come causa principale (Documentazione Ufficiale). Poiché un singolo investigatore tende a farsi trascinare verso la prima teoria, questo approccio crea intenzionalmente conflitto per migliorare la precisione.
Potete anche implementare un'operazione in cui all'Architetto non viene "dato il permesso di scrivere codice" utilizzando le funzionalità ufficiali. Richiedendo l'approvazione del piano per un compagno di squadra, il compagno rimane in una modalità di piano di sola lettura, producendo solo progetti fino all'approvazione del lead. I criteri di approvazione possono essere scritti nel prompt del lead, come "approva solo piani che includono la copertura dei test."
Esempio di prompt da provare (impostare una struttura conflittuale in un colpo solo):
Crea un agent team per revisionare la PR #142. Imposta tre compagni di squadra:
uno per la sicurezza, uno per le prestazioni e uno per la copertura dei test.
Falli revisionare in modo indipendente e produci risultati con gravità, poi integrali alla fine.
Ci sono due modalità di visualizzazione: in-process (tutti i compagni girano nello stesso terminale, ciclano con Shift+Down) e split panes (ogni compagno in un riquadro separato; richiede tmux o iTerm2). È più semplice iniziare con in-process poiché non richiede configurazioni aggiuntive.
6. Condividi la Memoria tramite la Memoria Automatica Ufficiale (Markdown), Non "SQLite"
Quando si eseguono più sessioni, il prossimo ostacolo è "condividere la memoria tra le sessioni." Mentre a volte vengono introdotte tecniche avanzate come "memorizzare la memoria con tag in SQLite e iniettarla dinamicamente", questa non è una funzionalità standard di Claude Code. È possibile se costruisci un DB tramite MCP (Model Context Protocol), ma dovresti distinguerlo dal meccanismo di memoria fornito ufficialmente.
La memoria automatica ufficiale funziona con file markdown. All'interno di ~/.claude/projects/<progetto>/memory/, vengono posizionati file come MEMORY.md (indice) e file specifici per argomento come debugging.md, e Claude scrive su di essi mentre lavora. Le regole di caricamento sono chiare: ogni sessione legge fino alle prime 200 righe o 25KB di MEMORY.md, e Claude va a leggere i file specifici per argomento solo quando necessario. Questo è disponibile da Claude Code v2.1.59, salvato per repository (quindi condiviso tra worktree) e memorizzato localmente (Documentazione Ufficiale).
La bellezza di questo design è che "caricando sempre l'indice e recuperando i dettagli solo quando necessario", puoi mantenere pulita la finestra del contesto. Anche con migliaia di piccole regole, il contesto non verrà contaminato ogni volta fintanto che l'indice non si gonfia.
In termini di ordine, usa al massimo la memoria automatica basata su markdown ufficiale prima di provare a costruire una soluzione SQLite personalizzata.
Un'azione che puoi fare oggi: Digitare /memory durante una sessione mostra l'elenco dei file CLAUDE.md e di memoria automatica attualmente caricati. Per prima cosa, dai un'occhiata a dove e quante memorie hai.
7. Tre Insidie nell'Operazione Parallela (Costi, DB, Permessi)
Ora che capisci il meccanismo, ecco tre punti di attenzione per l'operazione.
Il primo è il costo dei token. La documentazione ufficiale afferma che poiché ogni compagno di squadra in un agent team ha un contesto indipendente, l'utilizzo dei token aumenta proporzionalmente al numero di persone. Usare 5 persone per compiti di routine comporterà una perdita di costo. Ecco perché la raccomandazione ufficiale è di 3–5 persone, notando che "tre membri focalizzati spesso battono cinque membri distratti" (Documentazione Ufficiale).
Il secondo è l'ambito di isolamento dei worktree. Un worktree è solo un meccanismo Git per la separazione dei file; database, variabili d'ambiente e servizi in esecuzione sono ancora condivisi. Se due sessioni eseguono migrazioni sullo stesso DB locale, si romperà. La documentazione ufficiale avverte di "ricordarsi di inizializzare l'ambiente di sviluppo (installare dipendenze, impostare ambienti virtuali) in ogni worktree", e se i compiti toccano il DB, è necessario separare schemi, contenitori Docker o file .env (Documentazione Ufficiale).
Il terzo sono i permessi. I compagni di squadra ereditano le impostazioni dei permessi del lead quando vengono generati. Se esegui il lead con --dangerously-skip-permissions, anche tutti i compagni di squadra saranno in quello stesso stato non confermato. Poiché l'impatto di un incidente si diffonde in parallelo, è più sicuro limitare i permessi dal lato del lead.
8. FAQ per Utenti Intermedi: Numero di Persone, Espansione e Cancelli di Qualità
Infine, alcune risposte supplementari a domande comuni.
D. Quante sessioni sono realistiche?
Una buona linea guida è la struttura a 3 livelli e 8 sessioni menzionata in precedenza. La chiave non è infilare 8 persone in un unico agent team, ma usare un team di 3–5 persone come nucleo e aggiungere sessioni worktree o subagent. Questo è in linea con le raccomandazioni ufficiali (3–5 persone per team, 5–6 compiti per compagno di squadra). Il limite ultimo è l'intervallo che puoi monitorare e guidare. Se aumenti il numero oltre ciò che puoi comandare, l'efficienza diminuirà.
D. Cosa succede se supero i subagent e gli agent team?
Se vuoi monitorare un gran numero di sessioni indipendenti da un unico posto, la pagina ufficiale dei subagent menziona un meccanismo chiamato background agents. Pensalo a strati: subagent per l'aiuto all'interno di una sessione, agent team per un team parallelo conversazionale e background agent per gestire molte sessioni indipendenti.
D. Come posso garantire la qualità?
Le raccomandazioni in CLAUDE.md sono solo "istruzioni facili da seguire." Per i controlli che vuoi assolutamente eseguire, imponili con hook. Gli agent team hanno hook come TeammateIdle, TaskCreated e TaskCompleted; restituire il codice di uscita 2 invia feedback e forza il lavoro a continuare (Documentazione Ufficiale). Questo significa che puoi applicare programmaticamente regole come "non completare finché i test non sono verdi."
Riepilogo: Da Monitor a Progettista/Delegante
Il valore di Claude Code risiede più nella capacità per una persona di controllare più Claude specializzati che nel solo scrivere codice più velocemente. Ecco i punti chiave:
Non confondere i tre meccanismi: i subagent restituiscono risultati, gli agent team sono team conversazionali e i worktree isolano i file. Dividi 8 sessioni in livelli Comando, Implementazione e Qualità; isola l'implementazione con worktree e fissa i ruoli di qualità con definizioni di subagent o agent team. Fissa i confini dei ruoli nelle definizioni di subagent piuttosto che in CLAUDE.md e applica regole assolute con gli hook. Organizza la memoria automatica basata su markdown ufficiale prima di costruire una soluzione SQLite personalizzata. Punta a 3–5 persone per team e costruisci fino a 8 lavoratori aggiungendo livelli.
3 passi da provare iniziando oggi:
- [ ] Digita
claude --worktree test-1per familiarizzare con l'avvio di una sessione isolata. - [ ] Scrivi una definizione di subagent per un ruolo di "reviewer" in
.claude/agents/e fallo revisionare la tua implementazione. - [ ] Imposta
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1e prova a eseguire una revisione PR in parallelo con tre compagni di squadra.
Il tempo che passavi a digitare costantemente istruzioni di correzione in una singola sessione si trasformerà in tempo speso a progettare e delegare ruoli. Decidere cosa lasciar andare e cosa supervisionare è il lavoro più umano rimasto nell'operazione parallela.
Link di Riferimento (Fonti Primarie Ufficiali)
- Crea subagent personalizzati
- Orchestra team di sessioni Claude Code
- Esegui sessioni parallele con worktree
- Come Claude ricorda il tuo progetto / CLAUDE.md e memoria automatica
Ho intenzione di condividere informazioni utili che non posso pubblicare su X in questo Open Chat. Se siete interessati, unitevi ora.
