Se cerchi i comandi di Claude Code, il primo risultato su Google è la documentazione ufficiale di Anthropic, tradotta in italiano. È completa, è aggiornata a ogni release, ed è giusto che sia lì. Riscriverla su un blog è tempo perso per chi la scrive e per chi la legge.
Quello che la documentazione non ti dice è come si mettono insieme quei comandi quando hai una scadenza, un cliente e un repository che non hai scritto tu. Questo articolo è quello: il flusso che uso davvero, su progetti veri, con lo stack con cui lavoro tutti i giorni — PHP/Laravel, React con TypeScript, Node, PostgreSQL, container su Hetzner.
La regola che regge tutto il resto
Un task per sessione, un task per commit. È l'unica cosa che separa chi usa Claude Code con profitto da chi ci perde tempo.
La tentazione è aprire una sessione al mattino, chiedere dieci cose e chiuderla la sera. Succedono due cose: il contesto si riempie di roba irrilevante e la qualità delle risposte cala, e il diff diventa così grosso che non lo rivedi davvero. I bug in produzione entrano da lì, non dall'AI.
Prima di scrivere una riga: il CLAUDE.md
Claude Code legge il file CLAUDE.md nella root del progetto a ogni avvio. È il posto dove metti quello che un nuovo collaboratore dovrebbe sapere il primo giorno.
Il mio schema, che sta sempre sotto le cento righe:
- Stack e versioni. "Laravel 11, PHP 8.3, PostgreSQL 16, React 19 con TypeScript strict." Senza questo l'agente propone soluzioni di due versioni fa.
- Comandi reali del progetto. Come si lanciano test, lint, build, migrazioni. Sono i comandi che l'agente userà per verificarsi da solo.
- Struttura e convenzioni. Dove stanno i servizi, dove i controller, come si nominano le cose.
- Cosa non toccare. Migrazioni già eseguite, file generati, config di produzione. Questa sezione risparmia più tempo di tutte le altre messe insieme.
Regola di manutenzione: quando l'agente sbaglia due volte la stessa cosa, non ripeterglielo nel prompt — scrivilo nel CLAUDE.md. Il file cresce per correzioni, non per completezza.
Il flusso, dall'inizio alla fine
1. Far leggere prima di far scrivere
Su un repository che non conosco a memoria, il primo messaggio non chiede mai codice. Chiede una mappa: dove sta la logica che mi interessa, quali file la toccano, quali test la coprono.
Serve a due cose. Verifico che l'agente abbia capito il progetto prima di lasciargli modificare qualcosa, e mi accorgo subito se il CLAUDE.md è incompleto.
2. Concordare il piano prima dell'esecuzione
Per qualsiasi task che tocchi più di un file, chiedo il piano prima della scrittura. Il plan mode serve esattamente a questo: l'agente propone i passaggi, io li correggo, e solo dopo parte.
Il valore non è tanto il piano in sé — è che discutere l'approccio costa pochi token, mentre riscrivere un'implementazione sbagliata ne costa moltissimi. Nove volte su dieci il piano rivela che avevo descritto male il problema.
3. Delegare le esplorazioni ai subagenti
Le domande del tipo "dove viene calcolato questo totale in tutto il progetto" richiedono di leggere venti file per produrre tre righe di risposta. Se le fai nella sessione principale, quei venti file restano nel contesto per tutto il resto del lavoro.
Il subagente consuma il proprio contesto, ti restituisce solo la conclusione e sparisce. Uso questo schema per: trovare dove sta un comportamento, verificare che una modifica non abbia rotto altro, leggere la documentazione di una libreria che non conosco.
4. Farlo verificare da solo
Se il CLAUDE.md contiene i comandi di test e lint, l'agente può eseguirli e correggersi prima di consegnarti il lavoro. Il salto di qualità tra "scrivi questa funzione" e "scrivi questa funzione e fai passare i test" è enorme, e costa una riga di prompt.
Sulle cose che possono fare danno — migrazioni, deploy, comandi distruttivi — la conferma resta manuale. Sempre.
5. Rivedere il diff come se l'avesse scritto un junior
Non è una metafora prudente, è la descrizione corretta di cosa hai davanti: codice scritto velocemente da qualcuno di bravo che non conosce il contesto commerciale del progetto. Si legge tutto. Se il diff è troppo grande per leggerlo, il task era troppo grande.
Due cose che uso e quasi nessuno racconta
I worktree di git, per lavorare in parallelo
Con git worktree hai la stessa repository su più cartelle, ognuna su un branch diverso. Significa poter tenere aperte due sessioni di Claude Code contemporaneamente su due feature che non si toccano, senza che si pestino i piedi.
Funziona bene quando i due task sono davvero indipendenti — una modifica al frontend e una alla logica di fatturazione, per dire. Su codice che si sovrappone si finisce a risolvere conflitti, e il gioco non vale la candela.
Un server MCP con dentro il tuo dominio
Questa è la parte che cambia di più il rapporto costi/benefici. Un server MCP espone all'agente gli strumenti del tuo lavoro: il tuo database, il tuo CMS, i tuoi dati di Search Console, il tuo gestionale.
Senza, ogni richiesta parte da zero e tu fai da ponte: copi dati dentro, copi risultati fuori. Con, l'agente interroga direttamente la fonte. È la differenza tra chiedere "scrivimi una query" e chiedere "guarda quali pagine hanno perso traffico e dimmi perché". Se vuoi capire come si costruisce, ne ho scritto nella guida completa al Model Context Protocol.
Gli errori che ho fatto e che ti risparmio
- Sessioni infinite. Il contesto pieno peggiora le risposte e moltiplica il costo. Sessione nuova a ogni task.
- Permessi larghi per comodità. Dare accesso libero a tutto sembra velocizzare e funziona benissimo finché non funziona per niente. L'allowlist si costruisce a mano, un comando alla volta.
- Prompt vaghi su repository grandi. "Sistema il bug del carrello" fa partire un'esplorazione da migliaia di token. Indicare due file di partenza cambia l'ordine di grandezza del costo.
- Accettare la prima implementazione perché compila. Compila anche il codice che raddoppia le query al database.
- Non aggiornare il CLAUDE.md. Se ti ritrovi a ripetere la stessa correzione, il file è vecchio.
Quanto costa tenere questo ritmo
Il consumo dipende quasi interamente da quanto contesto lasci entrare, non da quanto codice produci. Le tre leve che pesano di più sono sessioni corte, file indicati esplicitamente ed esplorazioni delegate ai subagenti. I numeri e le misure li ho messi nella guida su come ridurre il consumo di token con Claude Code, mentre il confronto tra i piani e i limiti sta nell'articolo su quanto costa Claude Code.
Da dove iniziare, concretamente
- Apri il progetto su cui lavori di più e scrivi il CLAUDE.md. Trenta minuti, non di più.
- Prendi un task piccolo e vero, non un esempio. Chiedi prima la mappa, poi il piano, poi il codice.
- Fai eseguire i test all'agente prima di guardare il diff.
- Alla terza correzione ripetuta, torna sul CLAUDE.md.
Se il tuo problema non è imparare lo strumento ma automatizzare processi che oggi mangiano ore in azienda, quello è un altro tipo di lavoro: scrivimi e ne parliamo.
Per i progetti PHP/Symfony di taglia enterprise vedi anche la guida a Pimcore.
