Pattern di workflow di Claude Code che usiamo per consegnare codice in produzione ogni giorno

Un pattern di workflow di Claude Code è una forma di sessione ripetibile (come imposti il contesto, quando lasci scrivere a Claude, cosa controlli prima di fare merge) che trasforma una sessione di coding AI estemporanea in un processo ripetibile due volte al giorno senza sorprese.

Anthropic dichiara che la maggior parte del proprio codice è ormai scritta da Claude Code, e che gli ingegneri si stanno spostando su ruoli di architettura e orchestrazione (Anthropic, 2026). Una produttività di quel livello regge solo se la sessione è strutturata, non improvvisata. Qui sotto trovi i sette pattern che eseguiamo su ogni progetto Studio, ordinati per impatto sulla sicurezza in produzione.

Cosa abbiamo valutato

Per ogni pattern abbiamo guardato quattro proprietà:

• Attrito: costo di setup prima della prima chiamata.
• Compliance: quanto il pattern fa rispettare una regola, rispetto al chiederlo gentilmente a Claude.
• Costo in token: come cambia la spesa per task.
• Recupero: cosa succede quando Claude esce di traiettoria.

1. Il loop plan-first

Cos'è. Entra in plan mode (Shift+Tab fino a plan, oppure /plan) prima di qualsiasi modifica non banale. Claude può leggere, cercare e ragionare, ma il livello dei tool blocca fisicamente le scritture e i comandi shell distruttivi (Anthropic, permission modes). Iteri il piano con le domande che faresti a un senior engineer ("qual è il caso di fallimento peggiore?", "cosa rompe che i test non coprono?"), poi passi in Accept Edits per eseguire.

Cosa risolve. I test interni di Anthropic mostrano che i tentativi non guidati riescono circa il 33% delle volte. Plan mode è la correzione più economica disponibile, perché in quella fase non è ancora stato scritto codice.

Dove è debole. Per fix di una riga il rituale del piano è puro overhead. Saltalo per refusi, ordinamento degli import e ritocchi CSS che stanno in una schermata.

A chi serve. A chi tocca codice che va in produzione.

2. CLAUDE.md come documento di guida

Cos'è. Un file alla radice del progetto che Claude legge all'avvio di ogni sessione. Ci scrivi convenzioni, path, zone vietate, esempi di comando, il test runner. I team interni di Anthropic trattano CLAUDE.md come un registro degli errori passati e delle regole di stile nate dalle correzioni.

Cosa risolve. Il contesto ripetitivo. Senza un CLAUDE.md i primi 30 minuti di ogni sessione si bruciano a rispiegare cos'è il codice e come si rilascia.

Dove è debole. La compliance si attesta intorno al 70% sulle regole descritte in CLAUDE.md (Anthropic, 2026). Claude lo legge, poi sotto pressione decide a modo suo. Per le regole non negoziabili, vedi gli hook qui sotto.

A chi serve. A ogni progetto. Tienilo sotto le 200 righe così si carica a ogni sessione senza divorare il budget di contesto.

3. Hook per le regole rigide

Cos'è. Script deterministici che scattano in uno dei 25 punti del ciclo di vita (PreToolUse, PostToolUse, SessionStart e così via). Gli hook bloccano la chiamata di un tool prima che venga eseguita, lanciano qualunque bash o Python e tornano un exit code che Claude è obbligato a rispettare.

Cosa risolve. Il 30% di gap che CLAUDE.md non chiude. "Non pushare su main", "non fare rm -rf della cartella migrations", "esegui il lint prima di committare". Gli hook trasformano queste istruzioni in infrastruttura (Anthropic, best practices).

Dove è debole. Gli hook richiedono uno script per regola e disciplina per tenerli allineati al codice. Un hook obsoleto che blocca un comando rinominato è un incidente in attesa.

A chi serve. Ai team che rilasciano più di una volta a settimana. Lo sviluppatore solo può rimandare finché non si scotta la prima volta.

4. Subagent per separare la qualità

Cos'è. Un subagent è una sessione Claude separata, con il proprio context window, invocata dalla sessione principale. Il pattern canonico è writer/reviewer: un agente scrive il codice, un secondo lo rivede a freddo, senza il bias del "codice che ho appena scritto" (Anthropic, subagents).

Cosa risolve. La cecità da auto-review. Claude dichiara spesso un task completo quando ne ha chiuso solo una parte; un reviewer con contesto fresco trova ciò che il writer ha mancato.

Dove è debole. Due sessioni costano grossomodo 2x in token. Riserva i subagent per diff che toccano superfici sensibili (auth, pagamenti, migrazioni, qualsiasi cosa in infra/).

A chi serve. A chi ha già rilasciato in produzione un bug che Claude aveva dichiarato "verificato e testato".

5. Sessioni parallele su git worktree

Cos'è. Più istanze di Claude Code, ognuna nel proprio worktree git dello stesso repo, ognuna su un task indipendente.

Cosa risolve. La dipendenza sequenziale. Il creatore di Claude Code tiene attive 10 o 15 sessioni in parallelo e rilascia 20-30 PR al giorno, su workflow che sequenzialmente richiederebbero cinque ore per task (Mind Wired AI, 2026). Per uno studio, tre o quattro sessioni parallele è il tetto realistico prima che la code review diventi il collo di bottiglia.

Dove è debole. Diventi tu il merge conflict. Senza isolamento stretto dei task (un agente per superficie, nessun file in comune), le sessioni parallele costano più tempo di quanto ne risparmino.

A chi serve. A chi regge tre o più contesti di task contemporaneamente in testa.

6. Slash command per le routine ripetute

Cos'è. File di comando riutilizzabili in .claude/commands/<nome>.md che istruiscono Claude su un task strutturato: "rilascia una nuova patch", "audit accessibilità sulla pagina in cui mi trovo", "genera una migrazione Supabase a partire da questa definizione di tipo".

Cosa risolve. Il prompt drift. Lo stesso task ricorrente formulato in tre modi diversi produce tre forme di lavoro diverse, e la versione peggiore arriva sempre sotto pressione di scadenza.

Dove è debole. I command marciscono. Se cambia lo strumento sotto (uno script npm rinominato, una regola di lint sostituita) il command produce silenziosamente output obsoleto. Programma una revisione trimestrale.

A chi serve. A qualsiasi team con più di tre routine settimanali ricorrenti.

7. Server MCP al posto delle CLI nude

Cos'è. Dai a Claude un server MCP (Model Context Protocol) invece dell'accesso shell al database, allo stack di osservabilità o alle API admin. Il server espone tool tipizzati con permessi espliciti e log di audit.

Cosa risolve. Il blast radius. Un psql nudo nelle mani di Claude può droppare una tabella; un tool MCP espone solo le query che hai messo in whitelist, con log strutturati che puoi greppare quando qualcosa va storto. Il team data infrastructure di Anthropic è migrato dalla CLI BigQuery a un server MCP esattamente per questo motivo, citando logging e controllo del PII (Anthropic, 2026).

Dove è debole. Il server MCP lo costruisci tu. Per script una tantum non vale la candela. Abbiamo trattato la decisione build-vs-buy nel nostro articolo su MCP build vs buy.

A chi serve. A chiunque dia a Claude accesso a dati con vincoli di compliance, fatturazione o PII.

Come scegliere

Scegli i pattern che corrispondono alla superficie di rischio di ciò che stai costruendo. Un plugin per blog e un gateway di pagamenti non vogliono lo stesso workflow.

• Se rilasci in produzione, applica come minimo plan mode + CLAUDE.md + almeno un hook. È il pavimento.
• Se il repo tocca infra condivise (database produzione, pagamenti, auth), aggiungi server MCP e togli l'accesso shell a quei sistemi.
• Se il collo di bottiglia è la review e non la scrittura, aggiungi subagent con split writer/reviewer prima di aggiungere altri writer in parallelo.
• Se sei solo, con 30 minuti di concentrazione al giorno, salta le sessioni parallele e investi sugli slash command. La leva qui è la riduzione di ripetizione, non il parallelismo.

Nessuno di questi pattern regge senza un CLAUDE.md che descriva il progetto in modo onesto. I pattern sono leva sopra un contesto chiaro. Il contesto viene prima.