Buone pratiche per Claude Code: abitudini che migliorano i risultati

Quando una sessione di Claude Code va male, la causa è quasi sempre una di due. Claude ha costruito qualcosa di diverso da ciò che avevi in mente, oppure ha detto "fatto" mentre il lavoro non lo era. Nessuna delle due è una debolezza dello strumento. Entrambe nascono da informazioni che Claude non aveva.

Di' a Claude ciò che non può vedere e dagli un modo per controllare il proprio lavoro.

Le abitudini che seguono sono quelle che contano di più, nell'ordine in cui le userai. Presuppongono che tu abbia già installato Claude Code e avviato una sessione. Se no, parti da Claude Code per principianti.

Come procede una buona sessione

Claude Code lavora in un ciclo: raccoglie il contesto, agisce e verifica il risultato. Anche tu sei dentro quel ciclo. Puoi interrompere in qualsiasi momento per correggere la rotta. Ogni abitudine di questa guida migliora una parte del ciclo.

Abitudine 1: di' a Claude solo ciò che non può vedere

Claude inizia ogni compito leggendo il tuo codice, e lo fa bene. Trova la struttura delle cartelle, il framework di test e il modo in cui sono costruiti i componenti esistenti, di solito più in fretta di quanto riusciresti a spiegarli tu. Quindi gran parte di ciò che sei tentato di scrivere è già noto.

Quello che non può trovare è l'informazione che non è mai stata nel repository: una decisione presa in una riunione, un processo di deploy che vive nella testa di una persona, la variabile d'ambiente che servono ai test di integrazione. Fatti due domande prima di aggiungere una riga a un prompt o a CLAUDE.md:

Se entrambe le risposte sono sì, lascia stare. Lunghe liste di fatti ovvi seppelliscono l'unico fatto che conta. La prossima guida, CLAUDE.md spiegato, spiega dove mettere quelli che durano.

Abitudine 2: scrivi un prompt specifico

Un prompt specifico funziona per la stessa ragione: dà a Claude informazioni che non ha. Indica il file o l'area, descrivi il sintomo e di' come si presenta il problema risolto. Se preferisci uno tra due approcci ragionevoli, dì quale, perché Claude non può dedurlo dal codice.

I prompt migliori indicano il luogo, la prova e i limiti. Non sono più lunghi per il gusto di esserlo. Ogni frase aggiunta toglie un'ipotesi.

Nota la delega in quel prompt. Dai contesto e direzione, poi lasci che Claude capisca quali file leggere e quali comandi eseguire.

Abitudine 3: consegna la cosa invece di descriverla

Se hai già ciò che serve a Claude, daglielo direttamente. Scrivere la descrizione di un errore è più lento e meno preciso che dargli l'errore stesso.

Abitudine 4: fatti intervistare da Claude quando non sei sicuro

Non devi definire tutto il piano prima di scrivere il prompt. Quando un'idea è ancora confusa, chiedi a Claude di farti domande finché non riesce a scrivere la specifica:

Claude torna con domande sulle parti che non hai ancora definito: per utente o per chiave, cosa succede alle richieste oltre il limite, cosa resta fuori dall'ambito. Quando le risposte tornano, scrive SPEC.md. Avvia una sessione nuova per costruire a partire da quel file, così la costruzione parte con un contesto pulito e una definizione scritta di lavoro finito.

Per tutto ciò che ha un rischio reale, aggiungi il passaggio del piano visto nella guida sui permessi. Le modalità di permessi di Claude Code e la modalità Plan, spiegate mostra come far esplorare e proporre a Claude prima che modifichi.

Abitudine 5: dai a Claude un controllo da eseguire

È l'abitudine con l'effetto più grande. Claude si ferma quando il lavoro sembra finito. Se non ha nulla da eseguire che gli dica se il lavoro è davvero finito, "sembra finito" è tutto ciò che ha. Nella pratica diventi tu la suite di test, e ogni errore aspetta che tu lo noti.

Dagli qualcosa che torni con esito positivo o negativo, e Claude può chiudere il ciclo da solo: fa la modifica, esegue il controllo, legge il fallimento, lo corregge ed esegue di nuovo il controllo.

Il controllo può essere quasi qualsiasi cosa di cui Claude sappia leggere il risultato:

• un file di test
• il codice di uscita di una build
• un linter o un controllo dei tipi
• uno script che confronta l'output con un esempio salvato
• uno screenshot del browser affiancato al mockup

Se il tuo progetto ne ha già uno, la riga più utile del tuo CLAUDE.md è il comando che lo esegue. Quanto rigoroso renderlo dipende da te:

Abitudine 6: chiedi prove, non rassicurazioni

"All tests pass" da solo dice molto poco. Chiedi a Claude di mostrare il comando eseguito e l'output, o lo screenshot. Leggere l'output è più rapido che eseguire tu il controllo, e per una sessione che non stavi guardando è l'unica prova che hai.

Quando Claude dice di aver finito, puoi anche eseguire /verify, che fa costruire ed eseguire l'app a Claude e fa guardare il risultato. Coglie il tipo di problema che test e controlli dei tipi non vedono, come una pagina che tecnicamente si carica ma è visibilmente rotta.

Abitudine 7: guarda il primo minuto e correggi presto

Nessuna configurazione sostituisce il guardare l'inizio di un compito e intervenire quando Claude va dove non volevi. Impara a memoria questi controlli:

• Esc ferma Claude a metà azione e conserva tutto fino a quel punto, così puoi cambiare direzione senza perdere lavoro.
• Scrivi e premi Invio mentre Claude lavora per mettere in coda una correzione. Claude la legge appena finiscono le chiamate agli strumenti in corso e si adegua.
• /rewind, o Esc due volte su un prompt vuoto, apre un menu in cui riporti il codice, la conversazione o entrambi a un punto precedente. Così provare per primo l'approccio più audace costa poco.
• /btw fa una rapida domanda a margine senza aggiungerla alla cronologia della conversazione.

Abitudine 8: dopo due correzioni fallite, ricomincia da capo

Se hai corretto la stessa cosa due volte ed è ancora sbagliata, una terza correzione si aggiunge a una conversazione che contiene già due tentativi falliti che Claude continua a rileggere. Esegui /clear e scrivi un nuovo prompt che includa ciò che hai imparato.

Sembra di perdere i progressi. Quasi sempre funziona meglio. Anche /clear tra compiti non correlati è una buona abitudine di per sé, perché un contesto mirato dà risposte migliori e costa meno.

Per il lavoro che dura più giorni, dai un nome alla sessione con /rename oauth-migration, poi riprendila più tardi con claude --resume oauth-migration. claude --continue riprende la più recente.

Abitudine 9: tieni brevi le regole e sposta quelle rigide fuori dalla prosa

Tutto ciò che dici a Claude in un prompt o in CLAUDE.md è una richiesta che il modello legge e di solito segue. Un hook, una regola deny o un'impostazione gestita sono diversi: Claude Code li fa rispettare ogni volta, qualunque cosa decida il modello.

Usa il primo tipo per quasi tutto, perché Claude è bravo a giudicare quando una linea guida si applica. Usa il secondo per le poche regole che non ammettono eccezioni, come "never edit the generated client" o "always run the formatter after creating a file".

Se la sessione si allunga, controlla /context per vedere cosa occupa spazio. Claude compatta la conversazione in automatico, e un riassunto può perdere istruzioni dettagliate date all'inizio. Le regole permanenti appartengono a CLAUDE.md, che viene riletto dal disco dopo /compact. Puoi anche guidare il riassunto: /compact focus on the API changes.

Consigli che puoi smettere di seguire

Alcuni vecchi consigli erano scorciatoie per cose che i modelli precedenti non sapevano fare. I modelli attuali le sanno fare, e ora le scorciatoie costano più di quanto danno.

Domande frequenti

Come ottengo risultati migliori da Claude Code?

Dagli le informazioni che non può vedere, scrivi prompt specifici, passagli file ed errori invece di descriverli e dagli un controllo con esito positivo o negativo. Poi correggi presto con Esc ed esegui /clear quando le correzioni non funzionano.

Perché Claude Code dice di aver finito quando non è vero?

Si ferma quando il lavoro sembra finito. Se non c'è nulla da eseguire che dimostri il contrario, "sembra finito" è tutto ciò che ha. Dagli un test, una build o un linter da eseguire e chiedigli di mostrare l'output.

Devo usare la modalità Plan ogni volta?

No. Usala quando una modifica tocca molti file, quando non capisci ancora il codice o quando un errore costerebbe caro. Per una modifica descrivibile in una frase, chiedila direttamente.

Quando devo usare /clear?

Tra compiti non correlati, e dopo due correzioni fallite dello stesso problema. Inizia il nuovo prompt con ciò che hai imparato.

Che differenza c'è tra CLAUDE.md e un hook?

CLAUDE.md contiene istruzioni che Claude legge e di solito segue. Un hook è uno script che Claude Code esegue in un punto fisso, quindi accade a prescindere da ciò che decide il modello. Usa un hook per una regola senza eccezioni.

Come riprendo la sessione di Claude Code di ieri?

Esegui claude --continue per la conversazione più recente, o claude --resume per sceglierne una. Se hai dato un nome alla sessione con /rename, usa claude --resume <name>.

La tua checklist delle abitudini

Continua a leggere

• Claude Code per principianti: installa, accedi ed esegui il tuo primo compito per configurare ed eseguire la tua prima sessione.
• CLAUDE.md spiegato: insegna il tuo progetto a Claude Code una volta sola per il file che porta le tue regole da una sessione all'altra.
• Le modalità di permessi di Claude Code e la modalità Plan, spiegate per scegliere quanto può fare Claude senza chiedere.
• Cosa fare quando Claude non fa ciò che hai chiesto per lo stesso problema nell'app di chat.
• Come fare modifiche su più file con Claude Code per queste abitudini applicate a una modifica su molti file.