# Quattro prompt per contrastare la piaggeria in Claude Code > Fatti, precedenti, un piano e un’autoverifica: un ciclo in quattro fasi all’interno della Modalità Plan per le attività complesse e gli errori poco chiari. Source: https://ailoot.ai/blog/it/claude-code-sycophancy-prompts/ Canonical: https://ailoot.ai/blog/it/claude-code-sycophancy-prompts/ Language: it Publisher: Ailoot (https://ailoot.ai/) Translation: guide-123 Revision: sha256-1de662ba8be0ae60827bc70d7d491854c314e021dd3e8d8904ffd288780f94c5
Punti chiave Per impostazione predefinita, Claude Code è configurato per essere d’accordo. È comodo nelle conversazioni e pericoloso quando si scrive codice: il modello produce rapidamente una soluzione plausibile che finisce per distribuire un modulo di autenticazione in 14 file. Un ciclo di prompt in 4 passaggi in Modalità Plan blocca questo riflesso: fa prima accertare i fatti al modello, poi cercare precedenti, quindi elaborare un piano con i rischi e, infine, verificare il piano stesso.
La [documentazione di Ailoot](https://ailoot.ai/docs/) descrive come collegare i modelli e lavorare con l’API.
## Che cos’è la piaggeria dell’IA in Claude Code?
Punti chiave La piaggeria dell’IA non è un bug, ma una caratteristica architetturale di Claude e degli altri modelli linguistici di grandi dimensioni. In un’analisi di un milione di conversazioni con Claude, Anthropic ha rilevato che nelle conversazioni sulle relazioni il modello si adatta all’utente un quarto delle volte e, negli argomenti spirituali, un terzo delle volte. La percentuale è più bassa nella programmazione, ma il meccanismo è lo stesso: il modello vuole rispondere rapidamente con qualcosa che sembri plausibile e cerca di compiacere.
La psicologia ha da tempo un termine per questo: piaggeria. Un adulatore dice ciò che vuoi sentirti dire solo per mantenere viva la conversazione. Con l’arrivo dei modelli linguistici di grandi dimensioni, il termine è entrato nella ricerca sull’IA e, in un’analisi ufficiale, Anthropic ha ammesso apertamente che il modello sacrifica regolarmente l’accuratezza per essere subito d’accordo. Nella programmazione si presenta così. Scrivi a Claude Code: «Correggi questo errore in authMiddleware; i magic link hanno smesso di funzionare». L’adulatore non fa domande di chiarimento. Non chiede i log. Non chiede quale versione della libreria stai usando. Propone subito una soluzione perché è stato addestrato a essere utile rapidamente. E la soluzione sembrerà corretta: import, gestione degli errori, commenti. Ma risolverà il problema di qualcun altro, inventato a partire dal contesto che Claude ha ricostruito da frammenti. La causa non è Claude. La causa è il modo in cui formuli la richiesta. Quando chiedi «Come lo correggo?», hai già dato per scontato che si possa correggere. L’adulatore adotterà questa impostazione e produrrà una «correzione», anche se il vero problema riguarda l’architettura, la versione della libreria o il fatto che il sintomo descritto sia soltanto la conseguenza di un errore alla radice del tutto diverso. Un test semplice per una richiesta che induce alla piaggeria: se non riesco a rispondere alla domanda «Che cosa si è rotto, esattamente?» in tre frasi, non sono pronto a risolvere il problema. Mi serve una diagnosi. La correzione viene dopo. È proprio qui che inizia il ciclo in 4 passaggi. ## Un caso concreto: 8 commit annullati in un’ora
Punti chiave Ho chiesto a Claude Code di correggere l’autenticazione tramite magic link. Il modello ha fatto tre domande di chiarimento, ha elaborato un piano che copriva 14 file e io l’ho approvato. Diciotto minuti dopo, il magic link non funzionava, il refresh token era rotto e compariva un errore 500 nei pagamenti. Ho annullato 8 commit con `git reset --hard origin/main`. Il vero problema era una sola riga.
Un caso concreto dell’aprile 2026. Stavo lavorando all’autenticazione tramite magic link in `src/lib/auth/`. Il sintomo: i token venivano convalidati, ma la sessione non veniva salvata. L’utente clicca il link nell’e-mail, arriva sul sito e cinque secondi dopo viene rimandato a /login. Ho aperto Claude Code e ho scritto: «La sessione non viene salvata dopo il magic link; guarda in src/lib/auth/ e correggila». Claude ha fatto tre domande di chiarimento, poi ha prodotto subito un piano. Diceva: «Aggiornerò il gestore del callback, riscriverò il serializzatore JWT, aggiungerò il salvataggio esplicito in Redis e correggerò una race condition nel middleware». Sembrava plausibile. Ho approvato il piano. Diciotto minuti dopo, avevo un diff distribuito su 14 file. Il magic link continuava a non funzionare. Ma ora non funzionava neanche il refresh token, il login con password era rotto e sulla route dei pagamenti compariva uno strano errore 500. I test non passavano. Ho iniziato a ripristinare le modifiche. Ho annullato 8 commit con `git reset --hard origin/main`. Un’ora di lavoro buttata. Se vuoi capire come annullare correttamente le modifiche senza perdere nulla di utile, ne ho parlato separatamente nella [guida per annullare le modifiche in Claude Code](https://ailoot.ai/blog/it/claude-code-undo-changes/). Mi sono seduto e ho indagato come si deve. Ho aperto `src/lib/auth/magic-link.ts:42`, l’ho letto personalmente, ho aperto i log e ho controllato Redis. Venti minuti dopo ho trovato il problema. Era una sola riga: mancava l’attributo `SameSite=lax` nell’header `set-cookie` e Safari rifiutava il cookie durante il reindirizzamento dal dominio dell’e-mail al sito. Niente JWT, niente Redis, niente middleware. Una riga. Quando ho chiesto a Claude di correggere il problema, non ha mai controllato i log del browser. Non aveva informazioni su Safari. Ha formulato un’ipotesi basata sullo schema «la sessione non viene salvata = problema di serializzazione», perché è la risposta più comune nei dati di addestramento. L’adulatore ha prodotto una soluzione statisticamente plausibile, ma che non c’entrava nulla con la mia attività. Ho messo per iscritto la lezione come regola: non chiedere mai «Come lo correggo?». Chiedi sempre «Accerta i fatti». Restava solo da formalizzare il tutto in un ciclo di lavoro. ## Da dove nasce la piaggeria: Opus 4.8 al lancio e maggio 2026
Punti chiave La piaggeria è un comportamento documentato che richiede di adattare i prompt di lavoro.
Ad aprile, Anthropic ha esaminato separatamente, in un postmortem di ingegneria, come un bug di caching in Claude Code abbia fatto «dimenticare» al modello il proprio ragionamento tra un turno e l’altro.
Questo bug si trovava all’intersezione tra la gestione del contesto di Claude Code, l’API di Anthropic e il ragionamento esteso.
— Anthropic Engineering, https://www.anthropic.com/engineering/april-23-postmortem
Quando un modello dimentica la propria catena di ragionamento, gli è più facile «indovinare» una risposta basandosi su uno schema, in altre parole diventare ancora più adulatore. Cosa fare alla luce del rilascio di 4.8. Non scegliere un modello «più facile». Non tornare a 4.7. Adatta i prompt ai fatti: il modello è più incline a dare ragione, quindi insisti maggiormente sull’«accertamento dei fatti». Se non hai ancora capito esattamente cosa sta cambiando in Opus 4.8, l’ho confrontato nel dettaglio nella [recensione di Opus 4.8 in Claude Code](https://ailoot.ai/blog/it/opus-4-8-claude-code-features/). ## Quando servono i 4 passaggi e quando sono una perdita di tempo
Punti chiave Il ciclo in 4 passaggi è artiglieria pesante. Passare 15 minuti ad accertare i fatti, trovare precedenti e verificare il lavoro solo per correggere un refuso in un README non ha senso. Il ciclo serve proprio quando il costo di un errore è superiore a quello di 15 minuti di pianificazione. Il semplice test qui sotto suddivide le attività in tre livelli. Una regola semplice per classificare le attività: prima di iniziare, chiediti se sai elencare 3–5 file che saranno sicuramente coinvolti e dire cosa cambierà in ciascuno.
| Risposta | Cosa fare | |----|----| | Sì, so elencare i file e le modifiche | Fallo direttamente, senza Modalità Plan | | Non sono sicuro dei file, ma so cosa cambiare | Usa la Modalità Plan senza il ciclo in 4 passaggi | | Non sono sicuro né dei file né dell’approccio | Il ciclo in 4 passaggi è necessario | | Il sintomo non è chiaro e non si riesce a riprodurre in locale | Il ciclo in 4 passaggi più un passaggio zero con un esempio minimo riproducibile | Esempi concreti. Correggere il testo di un’e-mail di benvenuto: fallo direttamente. Aggiungere un nuovo pulsante CTA a un sito: Modalità Plan senza ciclo. Migrare un progetto da MySQL a Postgres: è necessario il ciclo in 4 passaggi. Uno strano errore 500 in produzione che non si riesce a riprodurre in locale: il ciclo in 4 passaggi con un ulteriore passaggio «zero»: «creiamo prima un esempio minimo riproducibile». Un errore comune quando si usa il ciclo è applicarlo ad attività banali. Questo uccide la velocità e fa perdere rapidamente alle persone la voglia di seguire la metodologia. Il ciclo serve proprio quando il costo di un errore è superiore a quello di 15 minuti di pianificazione. Prima di introdurre il ciclo, tieni presente che tutti e quattro i prompt funzionano **all’interno di una singola sessione in Modalità Plan**. Se non hai mai usato questa modalità, leggi prima la [guida alla Modalità Plan in Claude Code](https://ailoot.ai/blog/it/claude-code-plan-mode/), poi torna qui. ## Passaggio 1. Vietare le soluzioni e far accertare i fatti a Claude
Punti chiave Il primo impulso dell’adulatore IA è «ecco la soluzione». Il Passaggio 1 lo blocca esplicitamente. Il prompt chiede a Claude di compilare quattro campi: cosa osservo, come riprodurlo, cosa so e cosa non so. L’ultimo campo è il più prezioso: lì prende forma un elenco di domande per te, invece di un diff affrettato.
Il passaggio più importante. È qui che si blocca il primo impulso: «ecco la soluzione». Il prompt: ``` Ho riscontrato quanto segue: [sintomo]. Il tuo compito ora è accertare i fatti. Sono vietate soluzioni, idee o consigli. Solo: - cosa osservo (la formulazione esatta del sintomo) - passaggi riproducibili (uno scenario minimo) - quali dati sono disponibili (log, versioni, ambiente) - quali dati mancano (cosa occorre raccogliere) Condizione di arresto tassativa: non suggerire soluzioni; limitati a registrare la diagnosi. Se vuoi suggerire qualcosa, formula invece una domanda per me. ``` Cosa fa. Con un divieto esplicito di proporre soluzioni, Claude non può prendere scorciatoie. Deve compilare quattro campi: cosa vedo, come riprodurlo, cosa so e cosa non so. L’ultimo è il più prezioso. Spesso si scopre che è: «Non so quale versione della libreria sia in uso, cosa contengano i log o se il sintomo si presenti in produzione». Ecco la leva per il passaggio successivo. L’insidia del Passaggio 1. Se il sintomo è formulato in modo troppo vago («l’autenticazione non funziona»), Claude continuerà a fare supposizioni. Il rimedio è nel prompt stesso: descrivi il sintomo esatto in una frase e fornisci uno scenario minimo di tre passaggi. Se non ci riesci, significa che non hai ancora capito esattamente cosa non funziona e la risposta di Claude sarà comunque inutile. ## Passaggio 2. Precedenti da Internet al posto di allucinazioni basate sulla memoria
Punti chiave Il secondo impulso dell’adulatore IA è «inventare una soluzione basandosi sulle conoscenze generali». Il Passaggio 2 manda Claude a cercare nel mondo approcci verificabili. Almeno tre precedenti, ciascuno con un link attivo, pro e contro. Se Claude cita le proprie «conoscenze» senza un link, rifiutale subito.
Questo blocca il secondo impulso: «inventare una soluzione a memoria». Il prompt: ``` Ora che la diagnosi è stata stabilita, cerca online precedenti relativi alla soluzione di problemi simili. Almeno 3 approcci diversi. Per ciascuno: - un link alla fonte primaria (issue, articolo, documentazione) - una breve descrizione dell’approccio - pro e contro per il nostro caso - insidie note Sono vietati i link basati sulle tue conoscenze senza conferma del link. Se non riesci a trovare un precedente, dillo esplicitamente. ``` L’effetto nella pratica. Claude esplora e riporta approcci verificabili. Compaiono link a issue di GitHub e documentazione. Se Claude non trova precedenti, è un segnale che l’attività è insolita oppure che il sintomo è formulato in modo scorretto. Torna al Passaggio 1. Dove non funziona. Claude potrebbe citare un link inesistente. È un’allucinazione come «ecco l’issue numero 4291 nel repository X», quando l’issue 4291 in realtà parla d’altro. Affronta il problema inserendo in CLAUDE.md una regola esplicita: «apri sempre il link con WebFetch prima di citarlo». Per i dettagli, consulta la [guida per configurare correttamente CLAUDE.md](https://ailoot.ai/blog/it/claude-md-template/). ## Passaggio 3. Un piano dettagliato in `plans/` con i rischi previsti
Punti chiave Il terzo prompt trasforma il precedente migliore in un artefatto: un file `plans/YYYY-MM-DD-fix-X.md`. Il piano include file e righe specifici, test, rischi previsti con due o tre passaggi di anticipo e un piano di rollback. Il file dura più della conversazione: puoi aprirlo due settimane dopo e riutilizzare l’approccio tre mesi più tardi.
Ora la Modalità Plan funziona come previsto. Il prompt: ``` Scegli l’opzione migliore del Passaggio 2 e scrivi un piano dettagliato nel file plans/YYYY-MM-DD-fix-[name].md: - quali file specifici modificheremo (percorsi completi e numeri di riga) - cosa aggiungeremo e cosa rimuoveremo - quali test scriveremo e quali test esistenti devono passare - rischi nei due o tre passaggi successivi (cosa potrebbe rompersi per gli utenti) - un piano di rollback in caso di problemi Trasforma ogni passaggio in una casella di controllo [ ]. Il file deve stare su una schermata. Se il piano supera le 200 righe, dividilo in fasi. ``` Il risultato. Il piano diventa un artefatto anziché una nota temporanea in chat. Puoi leggerlo due settimane dopo, affidarlo a un altro agente o usarlo come condizione per il comando `/goal`. Un file di piano dura più della conversazione in Claude Code. La parte fondamentale è prevedere i rischi con due o tre passaggi di anticipo. Questo blocca un altro comportamento da adulatore: un piano ottimistico senza effetti collaterali. Quando chiedi a Claude di elencare esplicitamente i rischi, ne individua alcuni che altrimenti avrebbe ignorato senza dirlo in un piano normale. ## Passaggio 4. Autoverifica del piano: individuare le supposizioni da adulatore
Punti chiave Il filtro finale. Claude rilegge il proprio piano e segnala ciò che si è inventato: librerie assenti da package.json, variabili che non hai mai specificato e passaggi descritti in modo vago. Nel campione dell’autore, composto da circa 50 cicli, due o tre elementi del piano vengono rivisti specificamente nel Passaggio 4.
Il filtro finale. Il prompt: ``` Ora esegui un’autoverifica obbligatoria. Rileggi onestamente il tuo piano. Ci sono punti che hai inventato e non hai verificato con: - codice che hai letto; - documentazione citata nel Passaggio 2; - un precedente del Passaggio 2? Se sì, segnalali esplicitamente, correggili o rimuovili. Controlla anche: - se menziona librerie non ancora installate in package.json; - se menziona variabili d’ambiente che non ho specificato; - se i passaggi del piano sono descritti in termini generici anziché specifici. ``` Cosa fa. Claude deve ricontrollare il proprio ragionamento. Nel campione dell’autore, composto da circa 50 cicli, almeno due o tre elementi del piano vengono rivisti specificamente nel Passaggio 4. Sono punti in cui l’adulatore ha cercato di sgattaiolare nel Passaggio 3 e che il Passaggio 4 intercetta. Dopo i quattro passaggi, il piano è pronto per essere approvato. Puoi passare all’implementazione senza preoccuparti: «E se dovessi annullare 8 commit?» ## Perché proprio 4 passaggi, e non 2 o 7?
Punti chiave Il ciclo si basa sulla metodologia canonica di Anthropic Explore-Plan-Implement-Commit. Dei quattro passaggi di Anthropic, espando Plan in quattro micropassaggi per contrastare la piaggeria. Ogni passaggio blocca una classe di errori specifica: se ne salti uno, si verificherà un tipo di problema prevedibile.
Ecco il ragionamento, seguendo il metodo che Anthropic usa per guidare Claude nella sua documentazione ufficiale.
Se permetti a Claude di passare direttamente al codice, potresti ottenere una soluzione al problema sbagliato. Usa la Modalità Plan per separare l’esplorazione dall’esecuzione.
— Claude Code Docs, https://code.claude.com/docs/en/best-practices
La documentazione consiglia un flusso di lavoro in quattro fasi: Explore, Plan, Implement, Commit. Il mio ciclo in 4 passaggi è una specializzazione della fase Plan volta a contrastare la piaggeria. Dei quattro passaggi di Anthropic, ne espando uno in quattro micropassaggi: vietare le soluzioni, trovare precedenti, scrivere il piano e fare un’autoverifica. Si ottiene un piano dettagliato, poi passato alle fasi Implement e Commit. Ecco cosa si rompe se salti uno dei quattro passaggi: | Passaggio saltato | Cosa succede | |----|----| | Passaggio 1 (fatti) | Una soluzione al problema di qualcun altro: Claude ha indovinato il sintomo basandosi su uno schema e ha imboccato la strada sbagliata | | Passaggio 2 (precedenti) | Una soluzione inventata basata sulle «conoscenze generali»: funziona nel caso di riferimento e si rompe nella realtà | | Passaggio 3 (piano) | Implementazione senza analisi dei rischi: i test non passano, il refresh token si rompe e lo scopri dagli utenti | | Passaggio 4 (autoverifica) | Un piano con due o tre supposizioni infondate: una libreria che non c’è, una variabile mai specificata | La tabella lo chiarisce: ogni passaggio blocca la propria classe di errori. Servono tutti e quattro perché ciascuno intercetta una categoria diversa. Se l’attività sembra abbastanza piccola da richiederne solo due, allora è davvero piccola e non ti serve affatto la Modalità Plan. ## Come si integrano `plans/`, il comando `/goal` e i passaggi successivi
Punti chiave I 4 passaggi non esistono nel vuoto. Operano all’interno di un sistema composto dalla Modalità Plan, dalla cartella `plans/` nel repository e dal comando `/goal`. La Modalità Plan fornisce la modalità. La cartella `plans/` garantisce la persistenza. `/goal` fornisce l’automazione. Senza uno qualsiasi di questi tre livelli, il ciclo perde metà del suo valore.
Il ciclo si inserisce in un sistema che comprende: 1. La Modalità Plan attivata (doppio Shift+Tab in Claude Code). 2. Una cartella `plans/` nel repository in cui salvare i piani. 3. Facoltativamente, il comando `/goal` per l’implementazione autonoma di piani lunghi. Più precisamente, sulla cartella `plans/`. Dopo il Passaggio 3, ottieni un file `plans/2026-05-27-fix-magic-link.md` con fasi e caselle di controllo. È un artefatto. Aprilo una settimana dopo e ricorderai perché hai scelto quell’approccio. Tra tre mesi troverai un’attività simile e lo riutilizzerai. Tra sei mesi lo mostrerai a un collega e gli risparmierai due settimane per orientarsi. La cartella `plans/` fa parte del concetto di [«secondo cervello» in Claude Code](https://ailoot.ai/blog/it/claude-code-second-brain/). Più precisamente, su `/goal`. Dopo aver completato i quattro passaggi e approvato il piano, esci dalla Modalità Plan e inserisci: ``` /goal esegui tutte le fasi di plans/2026-05-27-fix-magic-link.md, tutti i test in test/auth passano, altrimenti fermati dopo 30 turni ``` Per una sessione locale di Claude Code, mantieni il terminale in esecuzione, il computer attivo e la rete disponibile. Non chiudere il portatile a meno di aver predisposto esplicitamente una configurazione supportata che lo mantenga attivo. Al ritorno controlla la cronologia: può mostrare completamento, limite di turni, una richiesta di autorizzazione o un errore. Un obiettivo non garantisce progressi mentre l’host è sospeso. Senza il ciclo in 4 passaggi, `/goal` spreca token in iterazioni inutili. Con il ciclo in 4 passaggi, `/goal` porta un piano completo fino al superamento dei test. Cosa fare da qui. Se hai appena iniziato a usare Claude Code, prova il ciclo alla prossima attività non banale. Non un refuso: qualcosa che coinvolga 3 o più file o un comportamento che non capisci appieno. Prendi i prompt qui sopra, copiali e aggiungi i tuoi dettagli. Noterai come cambia il tasso di rollback. Se usi già la Modalità Plan, aggiungi una cartella `plans/` al repository. Scegli un formato per i nomi dei file: `YYYY-MM-DD-feature-name.md`. In un mese avrai 20–30 file; in sei mesi, più di un centinaio. Così si costruisce il secondo cervello del progetto: una cronologia viva delle decisioni. Se vuoi approfondire la gestione del contesto prima di formulare il prompt, ho trattato la [context engineering in Claude Code](https://ailoot.ai/blog/it/context-engineering/) come disciplina a sé. Se hai già sia la Modalità Plan sia `plans/`, prova `/goal` per un’attività autonoma. Scegli un’attività che normalmente svolgeresti a mano in 30–40 minuti. Eseguila seguendo i 4 passaggi, salva il piano, avvia `/goal` e lascia attivi terminale locale e computer. Per lavorare mentre quel computer è spento, usa prima un percorso remoto o cloud configurato esplicitamente e verifica che l’attività sia in esecuzione lì.
### Fonti - [Anthropic Engineering - Best practices for Claude Code](https://code.claude.com/docs/en/best-practices) - [Anthropic Engineering - April 23 postmortem about quality reports](https://www.anthropic.com/engineering/april-23-postmortem) - [Anthropic Docs - Reduce hallucinations](https://platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/reduce-hallucinations) - [Anthropic Docs - Permission Modes (Plan Mode)](https://code.claude.com/docs/en/permission-modes) - [Anthropic Docs - /goal command](https://code.claude.com/docs/en/goal)
Puoi continuare a lavorare con l’IA su [Ailoot](https://ailoot.ai/).
## Domande frequenti ### Un /goal locale continua a lavorare se chiudo il portatile? Solo se l’host resta attivo e il processo del terminale continua. La sospensione normale può fermare il lavoro locale. Mantieni disponibili computer e rete oppure verifica che l’attività sia stata davvero avviata in un ambiente remoto o cloud separato. ### Quando il ciclo di quattro prompt giustifica il lavoro aggiuntivo? Quando sintomo, file coinvolti o approccio sono poco chiari e una modifica errata sarebbe costosa. Parti da un sintomo riproducibile e dalle prove mancanti, cerca le fonti, scrivi il piano e verificane le ipotesi. Un semplice refuso normalmente non richiede questo ciclo. ## Ailoot · L’azienda e il suo portafoglio di progetti Ailoot si basa su un’esperienza operativa consolidata, un’ampia base di clienti, un servizio stabile e un controllo costante dei KPI. L’azienda e il suo portafoglio di progetti: milioni di clienti; vendite nell’ordine dei miliardi ogni mese. Ailoot mette questa esperienza operativa al servizio dell’accesso API alle funzioni AI nei prodotti dei clienti, negli agenti, nelle applicazioni e nelle automazioni.