Plan Mode in Claude Code: guida passo passo e 4 fasi nel 2026

Ulteriori istruzioni sono disponibili nella documentazione di Ailoot.

Che cos’è Plan Mode e perché non basta da solo?#

In modalità normale, Claude Code scrive subito il codice e, se non tieni traccia delle modifiche, puoi ritrovarti all’improvviso con una diff su molti file. Plan Mode inverte l’ordine: prima ricerca e pianificazione, poi approvazione e infine modifiche.

Anthropic descrive così Plan Mode nella documentazione ufficiale:

Sembra semplice, ma nasconde il cambiamento principale. Plan Mode cambia il ritmo del lavoro: prima ci si mette d’accordo, poi si agisce. È un cambio di modalità, non un ritocco estetico. Il problema per chi fa vibe coding è che gli agenti IA tendono a precipitarsi. Se chiedi «Aggiungi l’autenticazione Google», in modalità normale Claude scriverà il codice in un minuto, ma metà dei file saranno quelli sbagliati. In Plan Mode, la stessa richiesta diventa un piano testuale che puoi leggere in due minuti e correggere prima che venga toccato qualsiasi codice.

Ecco una trappola di cui nessuno parla nelle guide internazionali. Plan Mode da solo è uno strumento debole: il piano esiste solo nella conversazione corrente. Chiudi la finestra e il piano scompare. Non puoi passarlo a un altro agente. Non ci sono versioni né cronologia. Se l’attività è grande (rifattorizzare un modulo di 30 file, migrare a un nuovo database), il piano raggiungerà presto il limite della finestra di contesto e inizierà a deteriorarsi.

Ecco perché Plan Mode funziona bene insieme a una cartella plans/ nel repository. Il piano viene salvato come plans/2026-05-21-google-oauth.md, suddiviso in fasi con caselle di controllo, così qualsiasi agente successivo può riprenderlo. È così che funziona il context engineering: si gestisce il contesto prima del prompt, non durante.

Come si attiva Plan Mode in Claude Code?#

Il modo più rapido durante una sessione è usare la tastiera:

Shift+Tab           # cycles through modes: default → acceptEdits → plan

Dopo due pressioni, in fondo al terminale compare l’indicatore ⏸ plan mode on. Una terza pressione riporta alla modalità normale. È il metodo più comodo: puoi attivarla al volo quando ti accorgi che l’attività sta diventando più ampia.

Il secondo metodo consiste nell’aggiungere un prefisso prima di un singolo prompt:

/plan write a plan to migrate the database from MySQL to Postgres

Questa opzione è utile se sei in modalità di accettazione automatica e non vuoi cambiarla per l’intera sessione. Una richiesta in Plan Mode, poi il lavoro prosegue come prima.

Il terzo metodo si usa all’avvio della sessione:

claude --permission-mode plan

Usalo quando sai già che un’attività richiede una pianificazione, per esempio prima di una rifattorizzazione importante o di una migrazione.

Il quarto metodo consiste nell’impostare il valore predefinito in .claude/settings.json del progetto:

{
  "permissions": {
    "defaultMode": "plan"
  }
}

Quando è utile? Quando un team lavora su un sistema complesso in cui qualsiasi modifica potrebbe influire sui moduli adiacenti. In quel caso, Plan Mode come impostazione predefinita protegge tutti dalle modifiche accidentali.

Un quinto trucco spesso trascurato: Ctrl+G apre il piano in un editor di testo. Usalo quando il piano è quasi giusto, ma devi riformulare 2-3 punti o aggiungere un vincolo. Modificalo manualmente, salva e Claude proseguirà con la tua versione.

Quali sono le 4 fasi canoniche di Anthropic in Plan Mode: Explore, Plan, Implement, Commit?#

Molte guide descrivono 3 fasi (Explore-Plan-Execute) o solo 2 (Plan-Implement). Sono semplificazioni. Nella sua guida ufficiale alle best practice, Anthropic descrive esattamente 4 fasi. La differenza è importante: separare Commit in una fase a sé ti porta a registrare il risultato invece di fermarti a «Ho fatto ancora qualche ritocco, poi farò il commit»: la causa più comune del lavoro perso.

Più il piano è preciso, meno iterazioni serviranno per l’implementazione. Se dedichi 10 minuti al piano, l’implementazione richiederà un solo prompt. Se abbozzi il piano in un minuto, passerai un’ora a correggere.

Ecco come si articolano le 4 fasi per aggiungere Google OAuth (un esempio tratto da Anthropic Docs):

Anche i prompt cambiano in ogni fase. In Explore: «leggi /src/auth e scopri come gestiamo le sessioni e l’accesso». In Plan: «Voglio aggiungere Google OAuth. Quali file devono cambiare? Crea un piano». In Implement: «realizza il flusso OAuth del tuo piano, scrivi i test, esegui la suite e correggi gli errori». In Commit: «crea un commit con un messaggio descrittivo e apri una PR».

Una precisazione importante: Plan Mode non impedisce a Claude di eseguire comandi per fare ricerche. Read, LS, Glob, Grep, web fetch e i comandi shell di esplorazione sono consentiti. Sono vietati solo Edit, Write e qualsiasi operazione sul filesystem che apporti modifiche. Questo significa che Claude può leggere la struttura del progetto, eseguire git log e consultare i test, ma non potrà modificare nulla per errore.

Come leggere il piano di Claude e decidere se approvarlo?#

Quando Claude ha finito di creare un piano, mostra le opzioni per procedere:

• Approva e avvia in modalità automatica
• Approva e accetta le modifiche
• Approva e controlla manualmente ogni modifica
• Continua a pianificare con un feedback
• Perfeziona con Ultraplan (revisione nel browser)

Saper decidere se approvare un piano è la competenza fondamentale in Plan Mode. È facile premere automaticamente «Approva» e poi dover annullare dei commit. L’IA compiacente vuole dare una risposta rapida, e tu vuoi arrivare al codice più in fretta. Vi sbagliate entrambi.

Un buon piano soddisfa 7 criteri:

1. Nomi specifici dei file. Non «aggiornerò auth», ma «modificherò src/auth/login.ts:42-58, creerò src/auth/oauth-callback.ts e aggiornerò src/auth/session.ts:103».
2. La sequenza è definita. Il piano è diviso in fasi o passaggi, anziché limitarsi a «farò tutto da qualche parte».
3. Le dipendenze esterne sono indicate. Se l’attività richiede una nuova libreria, è elencata. Se servono variabili d’ambiente, sono indicate.
4. I rischi sono elencati. Un buon piano dice: «La migrazione potrebbe interrompere le sessioni esistenti; occorre verificare X». Uno cattivo tace gli effetti collaterali.
5. Ci sono criteri di successo. «I test in test/auth passano, il linter non segnala errori e il server di sviluppo si avvia senza problemi».
6. Non ci sono supposizioni “tirate fuori dal nulla”. Se Claude dice «userò la libreria Z», controlla: l’hai installata nel progetto? Se l’IA se l’è inventata, vedrai che non è menzionata in package.json.
7. Il piano sta nello schermo. Se un piano per una semplice funzionalità è lungo 200 righe, probabilmente l’attività è troppo ampia per un unico piano. Suddividila.

Quando un piano non supera la verifica, ci sono tre opzioni:

• Continua a pianificare con un feedback: invia a Claude un commento specifico su ciò che non ti convince e riscriverà il piano.
• Ctrl+G: apri il piano in un editor, modificalo manualmente e salva. Claude proseguirà con la tua versione.
• Perfeziona con Ultraplan: il piano viene aperto nella modalità browser di Claude Code sul web, dove puoi esaminare le sezioni e commentarle, per poi eseguirlo localmente o nel cloud.

Se qualcosa va storto durante l’implementazione, non forzare. Torna a Plan Mode e riscrivi il piano. Costa 10 volte meno che annullare 40 commit in seguito.

Plan Mode e cartella plans/: una combinazione per i contesti lunghi#

Plan Mode è una modalità di Claude Code. La cartella plans/ è una metodologia costruita su di essa. Se usi Plan Mode senza una cartella, raggiungerai il limite dopo un’ora di lavoro.

Ecco come funziona. La finestra di contesto di Claude è la memoria della sessione. Può contenere 1 milione di token in Opus 4.7, ma quello è il volume dell’intera conversazione. Se pianifichi un’attività complessa in una conversazione, poi chiedi di implementarla, poi discutete un bug e poi un’altra cosa, la finestra si «gonfia». Claude inizia a dimenticare le decisioni iniziali, confondere i contesti e fare di nuovo le stesse domande.

La soluzione è la regola d’oro: un’attività, una conversazione.

Ecco come procedere:

1. Conversazione 1: definisci il piano. Attiva Plan Mode, descrivi l’attività e Claude creerà un piano. Salvalo in plans/2026-05-21-feature-name.md. Chiudi la finestra.
2. Conversazione 2: suddividilo in fasi. Apri una nuova chat. Chiedi: «prendi plans/2026-05-21-feature-name.md e suddividilo in fasi». Salva il file aggiornato.
3. Conversazione 3: implementa la fase 1. Apri una nuova chat. Chiedi: «implementa la fase 1 da plans/2026-05-21-feature-name.md e spunta le voci man mano che le completi». Chiudi la finestra.
4. Conversazione 4: implementa la fase 2. Procedi allo stesso modo.

Che cosa ottieni? La finestra di contesto di ogni conversazione rimane fresca. Claude nella fase 3 non conosce i dettagli della fase 1, ma conosce il piano perché il file plans/ è nel repository. Qualsiasi agente successivo (che sia un subagent, una nuova sessione o un’esecuzione tramite /goal) può riprendere il piano e proseguire.

Confronto tra gli approcci:

Ogni funzionalità ha il proprio file di piano. Quando, tre mesi dopo, devi ricordare perché hai scelto un provider di pagamenti rispetto a un’alternativa, puoi aprire il piano pertinente e leggere la cronologia delle decisioni: che cosa è stato discusso, quali opzioni sono state considerate e perché è stato scelto quel percorso.

Sono piani di lavoro in evoluzione; la documentazione statica diventa obsoleta nel giro di qualche mese.

Come fare in modo che Claude lavori mentre dormi con Plan Mode e /goal?#

Il principale limite delle lunghe sessioni con l’IA non è il modello in sé, ma la persona che preme Invio. Ogni volta che Claude arriva alla fine di un turno, aspetta una tua risposta. /goal elimina quell’attesa.

La sintassi è semplice:

/goal all tests in test/auth pass and lint is clean, or stop after 20 turns

La condizione può contenere fino a 4000 caratteri. È possibile impostare un solo obiettivo per sessione. Dopo ogni turno, il mini-modello Haiku esamina la trascrizione e decide: «condizione soddisfatta: termina» oppure «non soddisfatta: turno successivo». Il valutatore non chiama strumenti: si limita a leggere.

Alias per cancellarlo: /goal stop, /goal off, /goal reset, /goal none, /goal cancel.

La combinazione con Plan Mode funziona così:

1. Attiva Plan Mode (premi Shift+Tab due volte).
2. Chiedi: «crea un piano per migrare il database da MySQL a Postgres e salvalo in plans/2026-05-21-postgres-migration.md con fasi e criteri».
3. Rivedi il piano, modificalo e approvalo.
4. Esci da Plan Mode (premi Shift+Tab un’altra volta).
5. Imposta un obiettivo: «completa tutte le fasi in plans/2026-05-21-postgres-migration.md, spunta le caselle, tutti i test passano oppure fermati dopo 50 turni».
6. Chiudi il portatile e vai a dormire.

Al mattino, controlla il risultato: «✓ obiettivo completato» oppure «◎ fermato dopo 50 turni», con la cronologia delle attività svolte.

Ci sono tre regole essenziali per /goal, altrimenti sprecherai token:

Regola 1: uno stato finale misurabile. «Fallo sembrare bello» è una cattiva condizione. «npm test restituisce 0, npm run lint restituisce 0 ed è stata aggiunta una voce a CHANGELOG.md» è una buona condizione.

Regola 2: verifica esplicita. La condizione deve riferirsi a qualcosa di verificabile: un comando, un file o un endpoint. Non «funziona tutto», ma «curl localhost:3000/api/users restituisce 200».

Regola 3: limita il numero di turni. Aggiungi sempre «oppure fermati dopo N turni». Anthropic lo raccomanda esplicitamente nella documentazione:

Se attivi /goal senza un limite «oppure fermati dopo», il budget potrebbe svanire durante la notte.

Quale ciclo in 4 passaggi trasforma Plan Mode in un processo ingegneristico?#

Un errore comune è chiedere «come posso risolverlo?»: Claude dà una soluzione, tu la applichi, ma non funziona o peggiora le cose. È il fenomeno dell’«IA compiacente»: è addestrata a rispondere in fretta, e tu vuoi arrivare più rapidamente al codice. Un ciclo in 4 passaggi risolve il problema.

Il ciclo in 4 passaggi contrasta questo comportamento. Si segue in sequenza, all’interno di una sola sessione Plan Mode:

Passaggio 1. Stabilisci i fatti senza proporre soluzioni.

Prompt: «Sto riscontrando quanto segue: [descrizione del sintomo]. Il tuo compito ora è stabilire i fatti. Sono vietati soluzioni, idee e consigli. Devi indicare soltanto: che cosa osservo, quali passaggi sono riproducibili, quali dati sono disponibili e quali mancano. Condizione di arresto tassativa: NON proporre soluzioni; registra solo la diagnosi».

Questo blocca il primo impulso dell’IA: «ecco la soluzione». Claude deve fermarsi a «che cosa si sa e che cosa non si sa».

Passaggio 2. Sviluppa opzioni basate su precedenti.

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, una breve descrizione e i pro e i contro per la nostra situazione».

Questo blocca il secondo impulso dell’IA: «inventare una soluzione sul momento». Le chiediamo di consultare fonti esterne e riportare approcci verificabili.

Passaggio 3. Piano dettagliato con i rischi.

Prompt: «Prendi l’opzione migliore dal passaggio 2 e definisci un piano dettagliato: quali file specifici modificare, cosa aggiungere, cosa rimuovere, quali test scrivere, cosa potrebbe rompersi e quali rischi potrebbero presentarsi a 2-3 passaggi di distanza».

È la consueta fase Plan, ma con una differenza: si basa sulle opzioni verificate nel passaggio 2, non sulle ipotesi di Claude.

Passaggio 4. Autoverifica del piano.

Prompt: «Ora esegui un’autoverifica obbligatoria. Ricontrolla onestamente il tuo piano: ci sono punti in cui hai tirato fuori qualcosa dal nulla senza verificarlo nel codice, nella documentazione o in un precedente del passaggio 2? Se sì, segnalali e rivedi il piano».

È il filtro finale. Claude deve controllare il proprio ragionamento e ammettere dove ha avuto allucinazioni. In genere, in questo passaggio vengono rivisti almeno 2 elementi del piano.

Dopo i 4 passaggi, il piano è pronto per essere approvato. Puoi procedere all’implementazione sapendo che l’attività è stata compresa, le opzioni sono state valutate e i rischi presi in considerazione.

Questa metodologia serve a diagnosticare bug difficili e a prendere decisioni architetturali, in cui il costo di un errore è elevato. Applicata a Plan Mode, elimina il problema principale di chi fa vibe coding: «l’IA mi ha dato una soluzione, l’ho applicata ed è saltato tutto».

Quali 5 prompt pronti all’uso sono utili in Plan Mode per le attività più comuni?#

Modello 1. Rifattorizzare un modulo.

Sto attivando Plan Mode. Attività: rifattorizzare il modulo {module-name}.

Passaggio 1: studia la struttura attuale del modulo {module-path}. Descrivi:
- quali file fanno parte del modulo
- quali dipendenze esterne ha
- quali parti sono duplicate
- quali funzioni sono eccessivamente complesse

Passaggio 2: trova online 2-3 esempi di rifattorizzazione di moduli simili.
Almeno 1 fonte deve essere la documentazione ufficiale di Anthropic o del framework pertinente.

Passaggio 3: crea un piano di rifattorizzazione in plans/YYYY-MM-DD-refactor-{module}.md:
- quali file rinominare
- quali funzioni estrarre in moduli separati
- quali test mantenere e quali riscrivere
- rischi: cosa potrebbe andare storto per gli utenti

Passaggio 4: autoverifica. Ci sono supposizioni nel piano "tirate fuori dal nulla"?
Riscrivile o eliminale.

Modello 2. Migrazione del database.

Sto attivando Plan Mode. Attività: migrare il database da {old} a {new}.

Passaggio 1: studia lo schema del database attuale usando {schema-reading-command}. Descrivi:
- quali tabelle esistono e qual è la loro dimensione
- quali relazioni, indici e vincoli ci sono
- dove sono conservate le migrazioni
- quali dati sono critici

Passaggio 2: trova precedenti di migrazioni da {old → new} in progetti di produzione.
Almeno 3 approcci diversi: pg_dump, dual-write, blue-green.
Per ognuno, elenca i vantaggi e i rischi per le dimensioni dei nostri dati.

Passaggio 3: crea un piano di migrazione in plans/YYYY-MM-DD-db-migration.md:
- fasi (backup, migrazione, verifica, passaggio)
- criteri di successo per ogni fase
- piano di rollback in caso di problemi
- tempi di inattività o nessun tempo di inattività

Passaggio 4: autoverifica. Tutte le cifre sono supportate dalla documentazione?
Hai verificato mentalmente tutti i passaggi rispetto all’ambiente di sviluppo?

Modello 3. Aggiungere una nuova funzionalità.

Sto attivando Plan Mode. Attività: aggiungere la funzionalità {description} al progetto.

Passaggio 1: studia come funzionano attualmente nel progetto funzionalità simili.
In particolare, controlla:
- {file-1}
- {file-2}
- quali pattern architetturali vengono usati
- quali test sono scritti per funzionalità simili

Passaggio 2: scopri come viene implementata questa funzionalità in progetti open source
con un’architettura simile. Almeno 2 approcci diversi.

Passaggio 3: crea un piano in plans/YYYY-MM-DD-feature-{name}.md:
- elenco dei nuovi file
- elenco dei file modificati con le righe specifiche
- sequenza di implementazione
- quali test aggiungere
- cosa aggiungere a CLAUDE.md come regola per le sessioni future

Passaggio 4: autoverifica. Il piano rispetta l’architettura del progetto?
Presuppone librerie che non sono ancora state installate?

Modello 4. Scrivere test.

Sto attivando Plan Mode. Attività: coprire il modulo {name} con i test.

Passaggio 1: studia il modulo {path}. Individua:
- le funzioni pubbliche e le relative signature
- le funzioni interne che NON testeremo (dettagli d’implementazione)
- i casi limite: input vuoto, errori, accesso simultaneo

Passaggio 2: trova esempi di test per una classe di attività simile
in progetti open source popolari che usano lo stesso framework.

Passaggio 3: crea un piano dei test in plans/YYYY-MM-DD-tests-{module}.md:
- un elenco di test per ogni funzione pubblica
- quali mock servono
- quali fixture
- quale metodo di verifica usare (stile delle asserzioni)

Passaggio 4: autoverifica. Tutti i test verificano il comportamento anziché l’implementazione?
La copertura include i casi limite?

Modello 5. Eseguire il debugging di un errore complesso.

Sto attivando Plan Mode. Attività: capire la causa dell’errore {symptom-description}.

Passaggio 1: STABILISCI I FATTI. Soluzioni e idee sono vietate. Solo:
- cosa osservo (testo esatto dell’errore)
- passaggi riproducibili
- quali dati sono disponibili (log, tracce, versioni delle librerie)
- quali dati mancano (cosa occorre raccogliere in più)

Passaggio 2: trova precedenti relativi a questo errore.
Almeno 3 fonti: documentazione ufficiale o dell’autore del prodotto.
Per ciascuna, fornisci un link e un breve riepilogo della soluzione.

Passaggio 3: crea un piano diagnostico in plans/YYYY-MM-DD-bug-{name}.md:
- quali ipotesi verificare (ordinate per probabilità)
- quali comandi/script eseguire per verificare ciascuna
- il risultato atteso di ciascuna verifica

Passaggio 4: autoverifica. Ci sono ipotesi nel piano "tirate fuori dal nulla"?
Sono tutte collegate ai fatti del passaggio 1?

Copia ogni modello, sostituisci {parameters} con i tuoi valori e incollalo in Claude Code in Plan Mode. Otterrai un piano di lavoro in plans/, che potrai approvare e usare per l’implementazione.

Plan Mode o modalità normale: quale scegliere?#

Anthropic lo dice chiaramente nella documentazione:

Salta un piano separato solo se il diff effettivo è piccolo, compreso e a basso rischio. Pianifica se devi scoprire l’approccio o coordinare modifiche rischiose tra componenti. Conoscere i file o riassumere l’obiettivo in una frase non elimina rischi per migrazioni, autenticazione o integrità dei dati.

Tabella decisionale:

Prima di scegliere la modalità, chiediti se approccio, effetti collaterali e verifica siano compresi. Procedi direttamente per una modifica piccola, locale e a basso rischio con un controllo evidente. Pianifica prima per incertezza, codice sconosciuto, migrazioni, autenticazione o coordinamento tra componenti, anche conoscendo già tutti i 3-5 file interessati.

Come combinare Plan Mode, CLAUDE.md e subagent per un lavoro affidabile?#

CLAUDE.md è un file che Claude legge all’inizio di ogni sessione, compreso Plan Mode. Se CLAUDE.md dice «non inserire mai le date nel codice; ricavale sempre dal database», il piano non suggerirà mai di inserirle nel codice. In assenza di questa regola, il piano può suggerire qualsiasi cosa.

La combinazione funziona così:

Livello 1. CLAUDE.md stabilisce le regole.

Il file specifica lo stack del progetto, i principi architetturali, i divieti («non usare API deprecate») e i requisiti («tutte le email passano da un layout condiviso»). Guida dettagliata: Come configurare CLAUDE.md.

Livello 2. Plan Mode applica le regole all’attività.

Quando attivi Plan Mode e chiedi «aggiungi OAuth», Claude legge CLAUDE.md, vede le regole («salva i token in Redis, non nel database») e le tiene subito in considerazione nel piano. Il piano rispetta l’architettura del progetto.

Livello 3. I subagent suddividono il lavoro.

Se il piano è diviso in fasi, ciascuna può essere assegnata a un subagent separato. Ogni subagent lavora nella propria finestra di contesto senza ingombrare quella principale. Il piano in plans/ rimane la fonte centrale di verità: i subagent lo leggono, svolgono la propria fase e aggiornano le caselle di controllo.

Quali 7 errori compromettono Plan Mode?#

Errore 1. Il piano esiste solo nella chat.

Sintomo: hai scritto un piano, hai chiuso la finestra e devi riprenderlo il giorno dopo, ma non c’è più: il contesto è sparito. Soluzione: salva sempre il piano in plans/YYYY-MM-DD-feature-name.md nel repository. La chat è una scrivania; il file è un archivio.

Errore 2. Tutte le attività sono nella stessa chat.

Sintomo: in un’unica sessione discuti di auth, poi di una migrazione, poi del design dell’interfaccia e infine di un bug. La finestra di contesto si «gonfia» e Claude dimentica le cose dette prima. Soluzione: un’attività, una conversazione. Hai finito il piano? Chiudi la finestra. Inizi l’implementazione? Aprine una nuova.

Errore 3. Un unico piano di 3000 righe senza fasi.

Sintomo: il piano esiste, ma non ha caselle di controllo né suddivisioni. È impossibile capire che cosa è stato fatto e che cosa no. Delegare è impossibile. Soluzione: suddividi ogni piano in 3-7 fasi. Ogni fase è un elenco di caselle di controllo con azioni specifiche.

Errore 4. Nessuna ricerca approfondita prima del piano.

Sintomo: Claude propone una soluzione sul momento perché non gli hai chiesto di cercare precedenti. Una settimana dopo scopri che da tempo esisteva un approccio migliore nell’open source. Soluzione: usa il passaggio 2 del ciclo in 4 passaggi: fai cercare a Claude 2-3 precedenti online prima di creare il piano.

Errore 5. L’IA compiacente propone una soluzione senza una diagnosi.

Sintomo: chiedi «come risolvo l’errore X?», Claude propone una soluzione, la applichi, ma non funziona o peggiora le cose. Soluzione: inizia sempre con «stabilisci i fatti; le soluzioni sono vietate». Solo dopo la diagnosi passa alle opzioni.

Errore 6. Saltare l’autoverifica.

Sintomo: il piano sembra plausibile, ma contiene 2-3 supposizioni «tirate fuori dal nulla» (una libreria inventata, un’API inesistente o una versione sbagliata). L’implementazione si blocca proprio su quei punti. Soluzione: usa il passaggio 4 del ciclo in 4 passaggi: chiedi a Claude di ricontrollare onestamente il piano e segnalare le supposizioni.

Errore 7. Condizioni vaghe in /goal.

Sintomo: imposti /goal fallo sembrare bello, lo lasci attivo durante la notte e al mattino scopri che sono stati consumati $200 di quota. Soluzione: usa solo condizioni misurabili, con un comando di verifica e un obbligatorio «oppure fermati dopo N turni». Niente «fallo bene» o «rifiniscilo».

L’ottavo errore, il più comune tra chi fa vibe coding, è ignorare del tutto il concetto di cartella plans/. Plan Mode senza una cartella plans/ non è una metodologia: è un giocattolo. Se usi Plan Mode ma non crei file, ne sfrutti il 10% delle potenzialità.

Che cosa fare dopo la prima esperienza con Plan Mode?#

Tre passaggi concreti, in ordine crescente di difficoltà:

Passaggio 1. Configura CLAUDE.md, se non l’hai già fatto.

Senza CLAUDE.md, Plan Mode funziona «nel vuoto»: Claude non conosce le regole del progetto e propone piani che ne violano l’architettura. Guida completa: Come configurare CLAUDE.md. Un CLAUDE.md minimo contiene 50-80 righe che descrivono lo stack, le regole e i divieti. La lunghezza è secondaria; conta la specificità.

Passaggio 2. Crea una cartella plans/ nel repository.

Aggiungi una cartella plans/ nella radice del progetto. Concorda un formato per i nomi: YYYY-MM-DD-feature-name.md. Ogni piano ha il proprio file. Dopo un mese ne avrai 20-30; dopo sei mesi, 100+. È la cronologia viva delle decisioni del progetto.

Passaggio 3. Prova /goal su un’attività.

Scegli un’attività che di solito svolgi a mano in 30-40 minuti. Attiva Plan Mode, crea un piano e salvalo in plans/. Esci da Plan Mode. Imposta /goal completa tutte le fasi in plans/file.md, tutti i test passano oppure fermati dopo 30 turni. Chiudi il portatile per un’ora e fai altro. Torna a controllare il risultato.

Questi tre passaggi sono il minimo. È un percorso graduale: non cercare di fare tutto in una sera. Inizia con CLAUDE.md, aggiungi plans/ dopo una settimana e prova /goal durante la notte dopo un mese.

Quando sei pronto, scopri Ailoot.