La frase che rompe tutto

Cos'è e perché conta

La frase che rompe tutto è quella buttata lì: «sistema il login», «rendi la pagina più veloce», «aggiungi i pagamenti». Claude Code la prende sul serio e fa qualcosa. Il problema è che decide lui cosa vuol dire «sistemato», cosa può toccare e quando ha finito.

Non è un difetto dell'AI. È che non ti legge nel pensiero. Anche la guida di Anthropic sui prompt lo dice in modo semplice: trattalo come un collega bravissimo ma appena arrivato, che non conosce le tue regole e il tuo progetto. Più sei preciso su cosa vuoi, migliore è il risultato.

Per questo prima di ogni richiesta riempio uno schema di tre righe: cosa deve succedere, cosa non deve cambiare, come lo controlliamo. Ci metto poco. Mi evita la parte peggiore, cioè scoprire a lavoro finito che ha riscritto una cosa che funzionava. La stessa AI, con una richiesta chiara, ti dà un risultato diverso. Non è magia: è essere chiari con qualcuno che non ti legge nel pensiero.

Lo schema in tre righe

Eccolo. Copialo e riempi le parentesi. Una riga per pezzo basta.

Cosa deve succedere: [il risultato che vuoi vedere, con parole tue]
Cosa non deve cambiare: [file, pagine o funzioni che non deve toccare]
Come lo controlliamo: [come capisci che funziona: un test, un click, un dato che deve comparire]

Cosa deve succedere

Il risultato che vuoi vedere, non il modo per arrivarci. Scrivilo con parole tue, come lo diresti a voce. «Quando premo Salva, la nota compare nella lista» funziona meglio di «sistema il bug del salvataggio», perché dice cosa deve vedere chi usa l'app. Se sai dove succede, cioè quale pagina, quale bottone, scrivilo: così Claude non deve indovinare.

Cosa non deve cambiare

I confini: file, pagine o funzioni che devono restare come sono. Per sistemare una cosa, a volte Claude ne «migliora» altre vicine che nessuno gli aveva chiesto. Se gli dici dove non mettere le mani, ha un limite chiaro. È la riga che quasi tutti saltano, e ci torno più sotto.

Come lo controlliamo

Come capisci che funziona: un test, un click, un dato che deve comparire. Questa riga serve a te e serve a Claude. Se ha un controllo che può fare da solo, tipo un test che passa o non passa, può provare, leggere il risultato e correggersi prima di dirti che ha finito. Senza, l'unico segnale è che il lavoro «sembra fatto», e il controllo tocca a te.

Due esempi da copiare

Esempio 1: un bottone che non salva

Cosa deve succedere: quando premo il bottone Salva nella pagina Note, deve creare una riga nella tabella delle note nel database.
Cosa non deve cambiare: non toccare il login e non cambiare la grafica della pagina.
Come lo controlliamo: dimmi esattamente come lo provo, passo per passo, e se puoi scrivi un test che lo verifica.

Guarda la terza riga. Non serve saper scrivere un test: chiedo a Claude di dirmi come provarlo e, se può, di scriverlo lui. Non devi sapere tu come si verifica. Devi solo pretendere che ci sia un modo.

Esempio 2: una pagina lenta

Cosa deve succedere: la pagina dei prezzi deve aprirsi in meno di due secondi anche da telefono.
Cosa non deve cambiare: i prezzi, i testi e il pagamento restano identici.
Come lo controlliamo: misura il tempo di caricamento prima e dopo, e mostrami i due numeri.

Qui il controllo è un numero prima e uno dopo. Se Claude ti dice «ora è più veloce» senza i due numeri, non sai se è vero. E la riga in mezzo protegge quello che non vuoi veder cambiare per sbaglio mentre ottimizza: prezzi, testi, pagamento.

Tre consigli per usarlo in Claude Code

1. Se non sai come controllarlo, fermati

Se non sai rispondere a «come lo controlliamo», non sai ancora cosa vuoi. Succede, ed è meglio accorgersene prima che dopo. Invece di far partire il lavoro, chiedi aiuto a capirlo:

Aiutami a capire come verificare questa cosa, non scrivere codice.

Per i lavori più grandi uso la modalità piano di Claude Code (plan mode). Claude legge i file e ti propone un piano, ma non modifica niente finché non lo approvi. Ci entri premendo Shift+Tab finché in basso compare «plan mode on», oppure scrivendo /plan davanti al messaggio. Lì incollo lo schema e chiedo:

Leggi lo schema qui sotto e proponimi un piano. Dimmi quali file pensi di toccare, conferma che non tocchi quelli che ti ho escluso e spiegami come faremo il controllo dell'ultima riga.

[incolla qui lo schema compilato]

Per una modifica piccola il piano non serve: se la descrivi in una frase, tipo correggere un errore in un testo, chiedila direttamente.

2. Non saltare la riga in mezzo

«Cosa non deve cambiare» è il pezzo che tutti saltano, ed è quello che ti salva il login, i pagamenti e i dati veri. Le cose che non deve toccare mai le scrivo anche nel CLAUDE.md, il file nella cartella del progetto che Claude Code legge all'inizio di ogni sessione. Per esempio questa riga:

Non modificare il login, i pagamenti e i dati degli utenti senza chiedermelo prima.

Attenzione però: il CLAUDE.md è un'istruzione, non un lucchetto. Claude lo tratta come contesto, non come un blocco. Per questo, quando la richiesta passa vicino a quelle parti, le riscrivo comunque nello schema.

3. Alla fine, chiedi il resoconto

Quando ha finito, chiedi sempre:

Dimmi cosa hai cambiato e cosa non hai toccato.

Poi confronta la risposta con lo schema. Se ha toccato qualcosa della riga in mezzo, o se manca il controllo della terza riga, lo vedi subito. In quel caso non vado avanti e chiedo:

Fammi vedere la prova dell'ultima riga dello schema: il test con il risultato, oppure i passi esatti per provarlo io.

Gli errori più comuni

• Descrivere il codice invece del risultato, tipo «cambia quella funzione»: scrivi cosa deve vedere chi usa l'app e lascia il come a Claude.
• Lasciare vuota «cosa non deve cambiare» perché sembra ovvio: scrivi almeno login, pagamenti e dati veri quando il lavoro ci passa vicino.
• Un controllo vago come «verifica che funzioni»: chiedi una cosa che si vede o si misura, cioè un test che passa, un click, un numero.
• Mettere tre richieste nello stesso schema: uno schema, una cosa sola, e le altre le chiedi dopo, una alla volta.
• Fidarsi del «fatto» senza resoconto: chiedi cosa ha cambiato e cosa non ha toccato, e confrontalo con lo schema.

Checklist

• Ho scritto il risultato con parole mie
• Ho scritto cosa non deve toccare
• So come controllo che funziona
• Lo schema chiede una cosa sola
• Per un lavoro grande ho chiesto prima un piano
• Alla fine ho chiesto cosa ha cambiato e cosa no

Domande frequenti