Le Claude Code best practices che funzionano davvero non sono trucchi di prompt: sono un modo di dividere il lavoro. Tu decidi cosa fare e come si verifica il risultato, Claude decide come farlo. Non è un'opinione: è quello che emerge dallo studio in cui Anthropic ha analizzato circa 400.000 sessioni reali di Claude Code.
La ricerca copre circa 235.000 persone tra ottobre 2025 e aprile 2026 ed è tornata al centro del dibattito in Italia a metà settembre 2026. Io uso Claude Code ogni giorno su progetti Next.js, integrazioni per clienti e sulla pipeline di questo blog, e molti numeri confermano errori che ho fatto anch'io all'inizio.
In questa guida trovi cosa dicono i dati, gli errori più comuni e la checklist che applico prima di ogni sessione.
I numeri dello studio in breve
- Divisione del lavoro: in media l'utente prende circa il 70% delle decisioni di pianificazione e solo il 20% di quelle esecutive. Claude gestisce circa l'80% dell'esecuzione.
- Azioni per prompt: ogni richiesta avvia in media circa 10 azioni di Claude (leggere file, modificare codice, eseguire comandi), a volte oltre 100.
- Micro-gestione: quando l'utente controlla oltre l'80% delle decisioni esecutive, Claude fa circa 8 azioni per turno. Quando Claude guida la pianificazione, arriva a circa 16.
- Esperienza sul problema: nelle sessioni da principiante ogni prompt genera circa 5 azioni e 600 parole di output, in quelle da esperto circa 12 azioni e 3.200 parole.
- Successo verificato: 15% delle sessioni da principiante contro il 28-33% da intermedio in su.
- Abbandono: nelle sessioni in difficoltà abbandona il 19% dei principianti contro il 5-7% degli altri.
Un dettaglio che conta: per "esperto" Anthropic non intende lo sviluppatore senior, ma chi conosce bene il problema. Un commercialista che non scrive Python ma sa esattamente quali regole di riconciliazione deve rispettare uno script, in quella sessione, è l'esperto.
Errore 1: micro-gestire ogni passaggio
È l'errore che vedo più spesso, e che facevo anch'io: dire a Claude quale file aprire, quale riga cambiare, quale comando lanciare. I dati dicono che così Claude lavora circa la metà.
Cosa fare invece: dai tre cose.
- Obiettivo: cosa deve succedere e perché ("il checkout deve accettare codici sconto cumulabili perché il cliente lancia una promo").
- Vincoli: cosa non toccare, librerie da usare, compatibilità da mantenere.
- Contesto: dove si trova il problema, come riprodurlo, cosa hai già provato.
Poi lascia che Claude scelga la strada. Il controllo non sparisce: si sposta sulla revisione del risultato.
Errore 2: chiedere "sei sicuro?" come verifica
"Ricontrolla" o "sei sicuro?" non sono verifiche: chiedi a Claude di giudicare il proprio lavoro. Tra i segnali che lo studio usa per stimare l'esperienza c'è proprio cosa l'utente chiede di verificare, e il successo "verificato" richiede prove concrete come test che passano o commit coerenti con il lavoro.
Cosa fare invece: prima di iniziare chiediti cosa dimostrerebbe in modo oggettivo che il compito è riuscito.
- Stai correggendo un bug? Fai scrivere prima un test che lo riproduce, poi fallo passare.
- Stai cambiando una configurazione? Fai mostrare lo stato risultante con un comando.
- Stai toccando un'integrazione? Fai eseguire una chiamata reale in ambiente di test.
Più il ciclo di feedback è oggettivo, meno ti affidi alla parola del modello.
Errore 3: partire senza contesto di progetto
Ogni sessione senza contesto costringe Claude a riscoprire stack, comandi e convenzioni, e costringe te a ripeterli. È tempo e sono token.
Cosa fare invece: tieni un file CLAUDE.md nella root del progetto. Nel mio metto sempre:
- stack e versioni principali;
- comandi per installare, avviare, testare e fare lint;
- convenzioni di naming e struttura delle cartelle;
- le cose da non fare mai (migrazioni in produzione, file generati, segreti).
Per le procedure che ripeti, come pubblicare un contenuto o preparare un rilascio, le skill funzionano meglio del CLAUDE.md. Ho spiegato come ne ho costruita una nella guida su come creare una skill da zero, e trovi una selezione nell'articolo sulle migliori skill per Claude Code.
Errore 4: arrendersi quando la sessione va storta
Nelle sessioni che incontrano problemi (errori, test che falliscono, tentativi ripetuti) solo il 4% dei principianti arriva a un successo verificato, contro il 15% degli esperti. E i principianti abbandonano molto più spesso.
Anthropic nota che gli esperti tendono a bloccarsi su problemi più difficili, quindi il confronto non è perfetto. Ma la lezione pratica resta: chi sa guidare l'agente recupera.
Cosa fare invece: quando Claude gira in tondo non ripetere la stessa richiesta.
- Porta un'informazione nuova: il log completo, il messaggio d'errore esatto, un esempio che funziona.
- Riduci il perimetro: un file, una funzione, un caso.
- Se il contesto è sporco di tentativi falliti, riassumi cosa hai capito e riparti con /clear da quel riassunto.
Sulla gestione del contesto ho scritto una guida dedicata: ottimizzare Claude Code e ridurre i token.
Errore 5: pensare che serva essere sviluppatori
Questo è il dato che mi ha sorpreso di più. Nelle sessioni che producono codice, chi lavora nel software raggiunge un successo verificato nel 34% dei casi, le altre professioni nel 29%. Tra le dieci professioni più rappresentate, tutte restano entro sette punti dagli sviluppatori.
Il fattore che fa la differenza è capire il problema, non saper scrivere il codice. Per una PMI significa che chi conosce il processo (magazzino, fatturazione, prenotazioni) può ottenere risultati concreti. Ma significa anche che senza qualcuno che verifichi il codice prima della produzione il rischio resta alto.
Il lavoro sta cambiando: meno debug, più operazioni
Nei sette mesi osservati la quota di sessioni dedicate a sistemare codice rotto è scesa dal 33% al 19%. Sono cresciute le sessioni di gestione del software, dal 14% al 21%, e quelle di analisi dati e scrittura di documenti, da circa il 10% a circa il 20%.
Anthropic stima anche che il valore del compito medio, confrontato con gli annunci del mercato freelance, sia salito del 27%. È una stima indicativa, utile per confronti relativi più che come cifra in euro. Nel mio lavoro lo vedo: sempre meno "correggi questo errore", sempre più "prepara il deploy, controlla i log e documenta".
La mia checklist di Claude Code best practices
- CLAUDE.md aggiornato con stack, comandi e divieti.
- Obiettivo, vincoli e contesto nel primo messaggio, niente istruzioni riga per riga.
- Piano prima dell'esecuzione sui task non banali: lo leggo, lo correggo, poi lascio lavorare.
- Verifica oggettiva decisa prima: test, comando o stato da mostrare.
- Branch e commit frequenti, così ogni tentativo è reversibile.
- Permessi proporzionati al rischio: più libertà in locale, massima attenzione su dati e produzione.
- Quando si blocca, correggo la rotta con informazioni nuove invece di ripetere la richiesta.
Queste abitudini incidono anche sui consumi: meno giri a vuoto significa arrivare più tardi ai limiti del piano. Se ti chiedi quale abbonamento ti serve, trovi i dettagli in quanto costa Claude Code. E se stai scegliendo tra Claude Code e il resto di Claude, leggi Claude Cowork vs Claude Code.
I limiti dello studio
Anthropic stessa segnala alcuni limiti. Le classificazioni sono fatte da un modello che legge le trascrizioni, non da persone. Lo studio non misura se il codice viene poi usato davvero. E sono escluse le sessioni non interattive, come Claude Code dentro pipeline automatiche o IDE di terze parti. Sono dati da leggere come tendenze, non come leggi.
Domande frequenti
Qual è la best practice più importante per Claude Code?
Delegare l'esecuzione mantenendo la pianificazione: dare obiettivo, vincoli e contesto e lasciare a Claude la scelta di file e comandi.
Serve saper programmare per usare bene Claude Code?
Serve soprattutto conoscere il problema. Nelle sessioni che producono codice le altre professioni ottengono risultati vicini a quelli degli sviluppatori.
Conviene ricominciare da zero quando una sessione va male?
Non sempre. Spesso basta portare informazioni nuove o ridurre il perimetro. Se il contesto è compromesso, riparti da un riassunto di ciò che hai capito.
Conclusione
Le Claude Code best practices che emergono da 400.000 sessioni si riassumono in una frase: decidi tu il cosa e come si verifica, lascia a Claude il come. Più conosci il problema, più lavoro ottieni da ogni richiesta.
Se vuoi introdurre Claude Code nel tuo team o ti serve qualcuno che imposti CLAUDE.md, skill e verifiche su un progetto reale, scrivimi. Puoi anche vedere i progetti di sviluppo web app che seguo.
