Perché Claude fa la cosa sbagliata: 3 prompt
MarkdownClaude scrive la cosa sbagliata perché si lancia nel codice senza capire le tue intenzioni. Spiego perché e ti propongo 3 prompt pronti all’uso per fargli fare domande prima.
Leggi l’articolo completo
Punto chiave
Claude scrive la cosa sbagliata perché si lancia nel codice e colma le lacune immaginando ciò che pensi di volere. Spesso sbaglia. Quasi mai il problema è il modello: anche il più potente non coglie il punto se il compito è vago. Risolvo tutto con una mossa: faccio prima un’intervista con Claude, per far emergere le mie intenzioni, e solo dopo gli chiedo di scrivere. Qui sotto trovi tre prompt pronti all’uso da copiare e incollare.
Per saperne di più sul servizio, consulta la documentazione di Ailoot.
Perché Claude fa la cosa sbagliata?
Punto chiave
Claude riceve una richiesta breve, completa subito le parti mancanti e si lancia a scrivere codice sulla base della sua interpretazione del compito. La sua interpretazione e la tua sono diverse. Così ti ritrovi con un diff che tocca 14 file, quando ti aspettavi una modifica di una sola riga. La causa è la distanza tra ciò che hai detto e ciò che avevi in mente. Il modello non c’entra quasi per niente.
Scrivi: «Aggiungi filtri alla pagina dei prodotti». Tu pensi a un paio di caselle di controllo e a un elenco aggiornato. Claude sente la stessa cosa e decide di costruire un sistema di filtraggio completo: un proprio archivio di stato, una logica separata per il ritardo degli input, la sincronizzazione con l’URL e una dozzina di funzioni ausiliarie. Centinaia di righe, quando sarebbero bastati alcuni parametri URL.
In un caso come questo, la conclusione è chiara: l’agente non ha commesso un errore; ha semplicemente risolto un problema molto più grande del necessario. La colpa era non aver descritto l’esito desiderato in modo abbastanza breve e preciso.
La parola chiave è «intenzione». Tu ce l’hai in testa, Claude no. Vede il testo della tua richiesta e tutto ciò che è nel suo contesto fino a quel momento. Poi colma le lacune con delle supposizioni. Più breve è la richiesta, più supposizioni fa e più il risultato si allontana da ciò che volevi.
Anthropic lo dice chiaramente nella documentazione di Claude Code:
Se lasci che Claude passi subito al codice, potrebbe risolvere il problema sbagliato.
È successo anche nel mio progetto. Ho chiesto di correggere una schermata di autorizzazione e mi sono ritrovato con un diff che coinvolgeva metà di un modulo vicino. Claude non aveva colpa: gli avevo dato una sola riga e lui aveva completato il resto da sé. Da allora, per ogni compito più grande di una correzione di battitura, comincio con le domande: quelle che Claude mi fa.
È davvero colpa del modello? Perché anche i più potenti sbagliano?
Punto chiave
Il modello conta meno di quanto si tenda a pensare. Se il compito è vago, anche il più potente non coglie il punto: riceve le stesse istruzioni incomplete e colma le lacune con le sue supposizioni. Gli sviluppatori che tengono sotto controllo il proprio agente ottengono gli stessi risultati sia con un modello di fascia alta sia con uno di fascia media. Tutto dipende da quanto chiaramente descrivi ciò che vuoi. In questo caso, la potenza del modello è secondaria.
Ogni settimana arriva un modello «più intelligente» del precedente e ogni volta sembra che l’IA sia finalmente sul punto di capirci da poche parole. Non succederà. Un modello più potente scrive codice più velocemente e gestisce meglio la logica complessa, ma non può ancora leggerti nel pensiero. Se il compito è formulato male, otterrai qualcosa scritto benissimo, ma comunque sbagliato.
La conclusione per te è semplice. Inseguire il modello più recente perché faccia supposizioni migliori è una strada senza uscita. È più economico e affidabile imparare a assegnargli compiti in modo che non debba fare supposizioni. Ecco cosa vedremo ora.
Che cos’è l’interrogatorio e come risolve il disallineamento con l’IA?
Punto chiave
L’interrogatorio consiste nel fare in modo che l’IA ti intervisti prima di mettersi al lavoro: ti pone domande dettagliate sul compito finché non raggiungete una comprensione condivisa. L’obiettivo è colmare il divario di comunicazione prima della prima riga di codice.
Sembra controintuitivo. Ci rivolgiamo all’IA per fare le cose più in fretta, e ora ci viene detto di rallentarla e farle porre domande prima. Ma cinque minuti di domande prima di scrivere codice possono risparmiarti un’ora di correzioni dopo.
Il problema non è solo che hai spiegato male le cose a Claude. Spesso non hai ancora chiarito il compito nemmeno a te stesso: quali casi considerare, dove sono i limiti, che cosa conta di più. L’interrogatorio fa emergere tutto questo con le domande. Alla fine della conversazione, non hai soltanto un compito che l’IA capisce, ma anche il tuo compito finalmente descritto nei dettagli.
È così che funziona il context engineering: il lavoro principale avviene prima del prompt, non mentre lo scrivi. Non cerchi una formula magica per il prompt; prepari in anticipo ciò che serve a Claude, finché non capisce senza spiegazioni aggiuntive.
Come si fa a far sì che Claude ti faccia domande prima?
Punto chiave
Descrivi brevemente il compito a Claude e chiedigli esplicitamente di intervistarti prima di iniziare: fagli chiedere dettagli, casi limite e vincoli, e poi chiedigli di riassumere tutto in un file di specifica. È la raccomandazione ufficiale di Anthropic: la documentazione di Claude Code include un modello di prompt già pronto. Copialo, modifica la descrizione e incollalo all’inizio della sessione.
Anthropic non si limita a consentire questo approccio: lo consiglia. La documentazione contiene una sezione intitolata «Lascia che Claude ti intervisti», con un prompt già pronto. Ecco una versione pratica:
Prompt
Prompt per l’interrogatorio: fai in modo che Claude ti intervisti
Voglio realizzare [breve descrizione del compito].
Prima di scrivere codice, intervistami in dettaglio. Fammi domande sull’implementazione, sull’interfaccia, sui casi limite, sui rischi e sui compromessi. Non farmi domande ovvie: approfondisci gli aspetti complessi a cui potrei non aver pensato.
Fai una domanda alla volta e aspetta la mia risposta. Per ogni domanda, suggerisci subito la risposta che ritieni migliore.
Continua finché non abbiamo considerato tutto. Poi raccogli le informazioni in una specifica completa in un file chiamato SPEC.md.
Tre dettagli rendono utile questo prompt, invece che decorativo. Primo: «una domanda alla volta». Se l’IA ti rovescia addosso dieci domande tutte insieme, ti sentirai sopraffatto e risponderai in modo superficiale. Secondo: «suggerisci tu la risposta». Non devi inventarti tutto da zero: puoi accettare la proposta o correggerla. Terzo: «raccogli tutto in una specifica in un file»: le intenzioni emerse diventano un documento che non andrà perso.
Anthropic descrive il vantaggio in termini di impegno:
Il tempo dedicato a definire bene la specifica vale più del tempo passato a guardare l’implementazione.
Dopo l’intervista, apri una nuova sessione e fornisci la specifica completa. Contesto pulito e intenzioni espresse chiaramente: Claude coglierà il punto al primo tentativo.
La tecnica «dimostrami che è il piano migliore»
Punto chiave
Non limitarti a far porre domande all’IA: chiedile anche di difendere le proprie decisioni. Aggiungo al compito una richiesta: dimostrare che il piano proposto è il migliore, non solo il primo che viene in mente, e che è stato ragionato con diversi passi di anticipo. Così Claude esce dalla modalità «farò qualcosa di simile» ed entra in modalità critica, per verificare il proprio lavoro prima che tu investa tempo nell’implementazione.
L’interrogatorio fa emergere le tue intenzioni. Ma l’IA ha una seconda abitudine: afferrare la prima soluzione che sembra plausibile. Anthropic chiama questo problema «fidati, ma verifica»: Claude produce un’implementazione plausibile che non regge nei casi limite. La soluzione è chiedere prove prima del codice.
Se non puoi verificare il risultato, non inviarlo.
Quasi sempre aggiungo una sezione «dimostralo» al mio prompt. Ecco la formulazione esatta:
Prompt: chiedi all’IA di difendere il suo piano
Prima di scrivere codice, analizza il compito con spirito critico.
Trova 2-3 modi per risolverlo. Per ciascuno, dimostrami che risolve davvero il mio compito invece di aggiungere complessità fine a se stessa. Non scrivere codice solo per il gusto di scrivere codice.
Poi scegline uno e dimostra che è la soluzione migliore, ragionata con diversi passi di anticipo. Che cosa si romperà man mano che il progetto cresce? Che cosa ci stiamo perdendo in questo momento?
Solo allora proponi un’implementazione.
Senza questa sezione, Claude ti dà la prima soluzione praticabile. Con questa, Claude scarta da sé le strade senza uscita, spiega la sua scelta e ti mostra il suo ragionamento prima ancora che venga toccato un file. Leggi un breve testo che richiede due minuti, invece di passare un’ora a capire perché il codice finito non funziona come previsto.
Pre-mortem: chiedi all’IA di trovare 10 ragioni per cui potrebbe fallire prima di iniziare
Punto chiave
Il pre-mortem è una tecnica in cui chiedi all’IA di immaginare che il progetto sia già fallito e di indicarne le ragioni. Claude passa dalla modalità ottimistica «ce la farò» alla ricerca delle debolezze che altrimenti emergerebbero dopo una settimana di lavoro. Ottieni un elenco di rischi prima di aver investito tempo nel progetto e puoi affrontarli in anticipo.
È la mia tecnica preferita ed è psicologica. Quando chiedi all’IA di «fare un buon lavoro», la predisponi al successo e lei sorvola sulle lacune. Chiedile di immaginare un fallimento e comincerà a vedere ciò che prima ignorava. Il prompt è breve:
Prompt
Prompt per il pre-mortem: trova le lacune prima di iniziare
Immagina che sia passato un anno. Il progetto che stiamo pianificando è fallito.
Elenca 10 ragioni per cui è successo. Che cosa non abbiamo considerato all’inizio, che cosa abbiamo sottovalutato, dove abbiamo tagliato gli angoli e quali supposizioni si sono rivelate false?
Poi dimmi che cosa possiamo correggere subito per affrontare ciascuna ragione.
Eseguo questo prompt prima di approvare il piano. La metà delle ragioni si rivela infondata, ma l’altra metà individua ostacoli reali in cui mi sarei imbattuto una settimana dopo. Affrontarli in fase di pianificazione richiede dieci minuti. Incontrarli a progetto finito costa diversi giorni di indagine.
La combinazione è semplice: l’interrogatorio fa emergere le intenzioni, «dimostralo» difende la decisione e il pre-mortem trova le lacune. Tre brevi testi da incollare prima di scrivere codice. Trasformano Claude da esecutore frettoloso a collaboratore che riflette prima di agire.
Perché un contesto sovraccarico fa sembrare Claude stupido?
Punto chiave
Claude ha una finestra di contesto limitata: la quantità di informazioni che può tenere presenti in un dato momento. Quando la finestra è piena per più della metà, inizia a perdere dettagli importanti, a confondere gli accordi precedenti e a colmare le lacune con supposizioni invece di ricordare. Una lunga sessione in cui si parla di tutto è una ragione comune per cui, a fine giornata, l’IA fa qualcosa di completamente diverso da ciò che avevate concordato al mattino.
Anche un compito formulato alla perfezione va a rotoli se ci lavori in un contesto disordinato. Funziona così: ogni nuova richiesta porta l’intera cronologia della chat nel contesto di lavoro di Claude. Più lunga è la sessione, più in fretta si riempie la finestra. Tienila piena al massimo per metà: oltre quel limite, l’IA comincia a comportarsi da stupida e a dimenticare cose importanti di cui avete parlato all’inizio.
Ecco la regola che mi risparmia più frustrazione: un compito, una chat. Hai finito una funzione? Chiudi la chat e aprine una nuova per il compito successivo. Sì, a volte è più comodo fare tutto in un’unica finestra, ma lo pagherai con la perdita di contesto e risposte fuori tema.
Anthropic chiama questa modalità di errore «sessione cassetto delle cianfrusaglie». La soluzione è semplice: usa /clear tra compiti non correlati per svuotare la finestra ed evitare di trascinare il disordine del compito precedente in quello nuovo.
Se fai sessioni lunghe e non capisci dove vanno i soldi e l’attenzione dell’IA, ne parlo separatamente nella guida su dove finiscono i token di Claude Code. Ho raccolto le basi del contesto persistente, che Claude legge a ogni avvio, nella guida a come configurare CLAUDE.md.
Interrogatorio o Plan Mode: qual è la differenza e come si combinano?
Punto chiave
L’interrogatorio e Plan Mode risolvono due metà diverse dello stesso problema. L’interrogatorio fa emergere le tue intenzioni con domande, prima che ci sia un piano. Plan Mode prende un compito già compreso e ti mostra un piano delle modifiche, senza toccare nulla finché non lo approvi. Funzionano meglio insieme: prima l’interrogatorio chiarisce cosa stiamo costruendo, poi Plan Mode mostra esattamente come.
Spesso si confondono queste due tecniche o si pensa che ne basti una sola. In pratica, entrano in gioco in momenti diversi del processo.
| Caratteristica | Interrogatorio | Plan Mode |
|---|---|---|
| Quando avviene | Prima del piano: chiarisce le intenzioni | Dopo: crea un piano delle modifiche |
| Chi fa domande a chi | L’IA ti intervista | Tu leggi e approvi il piano |
| Che cosa ottieni | Una specifica del compito | Un piano delle modifiche, file per file |
| Vantaggio principale | Evita «non era questo che volevo» | Evita «non toccare nient’altro» |
Anthropic descrive un flusso di lavoro canonico in quattro fasi: prima Explore (Claude studia e fa domande), poi Plan (crea un piano senza apportare modifiche), quindi Implement (scrive il codice secondo il piano) e infine Commit (registra il risultato). L’interrogatorio avviene nella prima fase; Plan Mode nella seconda. Per un’analisi completa della seconda fase, consulta la guida a Plan Mode in Claude Code.
Anthropic stessa aggiunge un’importante precisazione: non appesantire i compiti semplici.
Se puoi descrivere una modifica in una frase, salta il piano.
Per una correzione di battitura, un rinominamento o una modifica di una riga, scrivila direttamente, senza interviste né piani. L’interrogatorio è utile per i compiti ambigui e quando un errore costa caro. Per i compiti banali, ti rallenta soltanto.
5 errori nel formulare i compiti che portano l’IA a fare la cosa sbagliata
Punto chiave
Quasi tutti gli errori dell’IA dipendono da cinque errori nel formulare il compito: una frase vaga, l’assenza di vincoli, «scrivi il codice» senza una fase «prima capisci», nessuna definizione di «finito» e un’unica sessione infinita per tutto. Ognuno di questi porta Claude a colmare il compito con supposizioni. Qui sotto trovi l’aspetto di ciascun errore e come correggerlo.
Ho riassunto in una tabella gli errori più comuni. A sinistra c’è ciò che si fa di solito e che porta a sbagliare; a destra, cosa fare invece.
| Errore | Come suona | Cosa fare invece |
|---|---|---|
| Frase vaga | «Migliora la dashboard» | Descrivi il compito e avvia una sessione di domande: lascia che l’IA faccia emergere i dettagli con le sue domande |
| Nessun vincolo | «Aggiungi l’autorizzazione» | Specifica che cosa non deve rompersi, quali librerie non aggiungere e che cosa è fuori ambito |
| «Scrivi codice» subito | Prompt e si comincia a programmare | Prima «capisci e chiedi», poi scrivi il codice |
| Nessuna definizione di «finito» | Ti aspetti che l’IA indovini il risultato | Fornisci un esempio, uno screenshot di riferimento o un test che mostri cosa significa «funzionante» |
| Un’unica sessione per tutto | Trascorri l’intera giornata in una sola chat | Un compito, una chat nuova, così il contesto resta in ordine |
Rileggi l’ultimo prompt per cui l’IA ti ha dato una risposta sbagliata. Quasi certamente è entrato in gioco uno di questi cinque errori. Il più comune è il primo: le hai dato una frase breve e ti aspettavi che Claude completasse correttamente il resto. Lo ha completato, ma non nel modo che avevi in mente.
E adesso? Costruisci un sistema perché l’IA ti capisca da poche parole
Punto chiave
I singoli prompt risolvono i singoli compiti. Per far sì che l’IA ti capisca senza lunghe spiegazioni ogni volta, ti serve un sistema: l’interrogatorio fa emergere le intenzioni per ciascun compito, un Second Brain custodisce le conoscenze sul progetto e il context engineering collega tutto ciò che Claude legge prima del prompt. A quel punto scompare la ragione per cui fa la cosa sbagliata: ha sempre abbastanza contesto per non dover fare supposizioni.
I tre prompt di questa guida — l’interrogatorio, «dimostralo» e il pre-mortem — affrontano il compito specifico che hai davanti. È già molto: smetti di ritrovarti con un diff di 14 file quando volevi solo una modifica di una riga.
Ma l’interrogatorio ha un limite. Far emergere ogni volta le tue intenzioni da zero richiede molto tempo. Il vero cambiamento arriva quando una parte del contesto è sempre disponibile: in una cartella con le conoscenze sul progetto, in un file CLAUDE.md che Claude legge a ogni avvio e nella tua metodologia codificata nelle skill. Così l’IA affronta il compito conoscendo già la tua attività, i tuoi obiettivi e il tuo stile, e ti capisce da poche parole perché hai preparato in anticipo metà del contesto.
Una recente analisi di Anthropic mostra quanto lavoro ci sia ancora da fare: gli sviluppatori usano l’IA in circa il 60% del loro lavoro, ma possono fidarsi pienamente solo per lo 0-20% dei compiti. Per il resto servono la tua comprensione, la tua supervisione e la capacità di spiegare cosa costruire. È questa la competenza da sviluppare, non la caccia al modello più intelligente.
Fonti
Scopri Ailoot.
Maggiori dettagli
Domande frequenti
Quando uso il prompt di intervista anziché passare subito al codice?
Quando risultato, casi limite o vincoli non sono chiari e gli errori sarebbero costosi. Chiedi una domanda alla volta e salva quanto concordato in SPEC.md. Un refuso o una modifica di una riga chiaramente descritta si possono richiedere direttamente.
Cosa controllo prima di accettare il piano proposto?
Chiedi due o tre approcci e confronta come soddisfano specifica e vincoli. Esegui poi il prompt di pre-mortem, esamina i motivi di fallimento individuati e affronta i rischi pertinenti prima dell’implementazione.