Claude Code Plan Mode: come pianificare e rivedere le modifiche

Il momento decisivo è quello che precede l’approvazione: ci si accorge di un chiamante trascurato, si tutela un contratto esistente o si elimina una modifica al database non necessaria. Un piano dettagliato serve davvero quando porta a cambiare una decisione.

Come funziona Claude Code Plan Mode

Plan Mode chiede a Claude di esaminare il codice del progetto e proporre le modifiche. Può leggere file, eseguire comandi di esplorazione e scrivere il piano. Di norma, le modifiche al codice sorgente restano bloccate fino all’approvazione. È come controllare il progetto di una ristrutturazione prima che l’impresa inizi a spostare i muri. Il flusso di pianificazione di Anthropic.

La documentazione segnala però un’eccezione importante: nelle sessioni interattive da terminale in cui è disponibile il bypass dei permessi, i blocchi di Plan Mode non vengono applicati. Claude riceve comunque l’istruzione di pianificare, ma un tentativo di modifica può essere eseguito. Questo vale anche quando si rende disponibile il bypass con --allow-dangerously-skip-permissions, senza selezionarlo come modalità attiva. Se si vuole subordinare ogni modifica al sorgente all’approvazione, occorre avviare la sessione senza abilitare il bypass. Le regole di Anthropic sulle modalità di autorizzazione.

La pianificazione e il sistema dei permessi lavorano insieme. Il piano descrive ciò che Claude intende modificare; la modalità di autorizzazione stabilisce quali azioni possono proseguire senza chiedere conferma.

Come usare Claude Code Plan Mode: entrare e uscire

Per avviare una sessione da terminale direttamente in Plan Mode:

claude --permission-mode plan

In una sessione già aperta, usa i comandi qui sotto. Controlla l’indicatore della modalità, senza affidarti a un numero fisso di pressioni dei tasti.

Partendo da auto, il ciclo passa a default (Manual), poi a acceptEdits e infine a plan. Seguono le eventuali modalità opzionali disponibili: prima il bypass dei permessi, per ultima auto. Su Windows, Anthropic indica Alt+M come alternativa quando il runtime Node o Bun non abilita la modalità di input VT. Cambio di modalità, riferimento delle scorciatoie da tastiera, riferimento dei comandi.

Quando Claude presenta un piano, la richiesta di approvazione permette di:

• Scegliere No, keep planning per continuare a pianificare e fornire correzioni specifiche.
• Scegliere Yes, manually approve edits per approvare l’approccio e controllare le modifiche una alla volta.
• Scegliere Yes, and use auto mode per approvare e proseguire in modalità auto, quando disponibile.

Se la modalità auto non è disponibile, l’opzione automatica accetta invece le modifiche senza richiedere conferma. Se la sessione è stata avviata con il bypass abilitato, quella stessa opzione passa al bypass dei permessi. Prima di selezionarla, leggi quale modalità viene proposta. L’approvazione chiude Plan Mode e avvia l’implementazione con i permessi scelti. Anche cambiare modalità con Shift+Tab fa uscire dalla pianificazione, ma non approva il piano proposto. Comportamento all’approvazione del piano.

Usi un’interfaccia con editor? In VS Code, fai clic sull’indicatore della modalità sotto il prompt e seleziona Plan. Nella scheda Code dell’app Desktop, usa il selettore accanto a Send. In JetBrains si usano i comandi della CLI nel terminale integrato. Il changelog segnala inoltre il supporto al comando /plan digitato in VS Code a partire dalla v2.1.280. Comandi nelle diverse interfacce, changelog ufficiale.

Le impostazioni da conoscere

Per avviare in Plan Mode le sessioni da terminale di un progetto, integra questa configurazione in .claude/settings.json:

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

Per impostare invece il valore predefinito per tutte le tue sessioni da terminale, usa ~/.claude/settings.json. Il flag di avvio ha la precedenza sulle impostazioni; quelle del progetto o gestite centralmente possono prevalere sul valore predefinito dell’utente. VS Code ha una propria impostazione di avvio: inserisci "claudeCode.initialPermissionMode": "plan" nelle impostazioni utente di VS Code. L’estensione non legge le impostazioni di progetto per scegliere la modalità di autorizzazione iniziale. Configurazione della modalità iniziale.

Queste altre chiavi vanno al livello principale delle impostazioni di Claude Code, fuori da permissions:

Sono scelte indipendenti: dove salvare il piano, come controllare i comandi durante la pianificazione e se offrire un’opzione di approvazione che cancelli la conversazione. Riferimento delle impostazioni, salvataggio dei piani, opzione per cancellare il contesto.

Se scegli di cancellare il contesto, inserisci nel piano stesso i vincoli, le decisioni ancora aperte e i criteri di accettazione. Altrimenti farai affidamento su una discussione che non sarà più disponibile durante l’implementazione.

Plan Mode e modalità auto: come lavorano insieme

Plan Mode lascia in sospeso la decisione di implementare, in attesa della revisione. La modalità auto riduce le richieste ordinarie di autorizzazione facendo valutare le azioni a un modello classificatore separato. Il classificatore controlla gli aspetti legati ai permessi; chi rivede il piano verifica invece che la soluzione proposta affronti il problema giusto.

Quando la modalità auto è disponibile e useAutoModeDuringPlan resta abilitato, il classificatore valuta anche i comandi shell durante la pianificazione. I comandi approvati vengono eseguiti, quelli respinti vengono bloccati. Se auto non è disponibile, oppure l’impostazione è disabilitata, i comandi esterni all’insieme predefinito di quelli in sola lettura richiedono invece conferma. Le rimozioni di percorsi critici hanno una gestione separata e l’eccezione del bypass nel terminale interattivo ha la precedenza. Pianificare non significa che ogni comando shell sia in sola lettura. Comandi durante la pianificazione.

Durante l’implementazione, default prevede la revisione manuale, acceptEdits autorizza automaticamente le modifiche consentite e i comuni comandi sul filesystem, con le eccezioni documentate, mentre auto aggiunge il controllo delle azioni in background. Nessuna di queste modalità stabilisce se l’architettura proposta sia valida. La nostra guida a Claude Code Auto Mode approfondisce questa scelta di autorizzazione.

La documentazione attuale indica auto come modalità iniziale predefinita per le sessioni interattive da terminale e in VS Code a partire dalla v2.1.283, nel rispetto delle regole di configurazione, organizzazione e disponibilità. Impostare esplicitamente Plan Mode all’avvio resta quindi rilevante. Regole attuali sulla modalità iniziale.

Le istruzioni meno recenti possono non includere cambiamenti significativi. Il changelog di Anthropic documenta l’argomento descrittivo di /plan nella v2.1.72, l’opzione di cancellazione del contesto nascosta per impostazione predefinita dalla v2.1.81 e, nella v2.1.218, la gestione tramite classificatore dei comandi Bash di cui non è certa la natura di sola lettura durante la pianificazione con auto. Changelog ufficiale.

Un esempio di refactoring: condividere la logica dei prezzi senza cambiare gli addebiti

Consideriamo un caso concreto: un’applicazione calcola i prezzi del checkout nella propria API e quelli dei rinnovi in un worker in background. L’obiettivo è condividere le regole di calcolo, conservando però il comportamento di ciascun chiamante per arrotondamenti e sconti. Quello che segue è un piano illustrativo, non il resoconto di un repository testato né un risultato garantito di Claude.

Entra in Plan Mode e specifica il vincolo effettivo:

Supponiamo che i file rilevanti del progetto siano questi:

Una prima bozza plausibile potrebbe proporre di estrarre una funzione di calcolo comune, aggiornare entrambi i chiamanti, eliminare le vecchie funzioni di supporto e aggiornare i test. Sembra una soluzione ordinata. È però incompleta: cosa succede se il checkout arrotonda in un punto diverso rispetto al rinnovo?

Modifica il piano prima di accettarlo. Durante la revisione, premi Ctrl+G e sostituisci il passaggio che prevede l’eliminazione anticipata con questa correzione:

Salva il piano e torna alla sessione. Se la proposta richiede ancora lavoro, scegli l’opzione per continuare a pianificare e chiedi a Claude di rendere l’intero piano coerente con la correzione. L’obiettivo è eliminare il passaggio di cancellazione contraddittorio, non aggiungere un avvertimento in fondo. La modifica diretta e la prosecuzione della pianificazione sono entrambe parti documentate del flusso di lavoro. Le indicazioni di Anthropic su esplorazione, pianificazione e scrittura del codice.

Il piano rivisto dovrebbe ora descrivere una sequenza pronta per essere implementata:

1. Fissare il comportamento esistente nei test. Aggiungere casi per gli importi attuali di checkout e rinnovo, comprese le soglie di arrotondamento, gli sconti e gli input non validi. Chiarire ogni risultato atteso ancora incerto prima di proseguire.
2. Introdurre le regole condivise dietro gli adattatori. Conservare input, output e comportamento in caso di errore di ciascuna funzione esistente. Esplicitare le differenze tra i chiamanti.
3. Migrare i chiamanti in passaggi separati. Aggiornare il checkout, verificarlo e solo dopo aggiornare il rinnovo. Escludere da queste modifiche gli interventi di pulizia non pertinenti.
4. Verificare il risultato. Eseguire i controlli effettivamente previsti dal progetto per prezzi, API e worker, seguiti dai normali controlli dei tipi e di integrazione. Esaminare il diff per individuare cambiamenti nelle risposte pubbliche o nella logica degli addebiti.
5. Conservare una possibilità di rollback. Mantenere il livello di compatibilità fino al superamento delle verifiche. Rimuovere il codice obsoleto in un passaggio separato, che si possa rivedere autonomamente.

Per questo esempio, approva poi il piano mantenendo la revisione manuale delle modifiche. Dopo l’implementazione, confronta con il piano le modifiche effettive e i risultati dei test. Un piano che cita dei test resta una proposta finché quei controlli non vengono eseguiti.

Il vantaggio economico, qui, è preciso: intercettare un cambiamento di comportamento prima che vengano riscritti entrambi i chiamanti e i relativi test. Non serve associargli una percentuale ipotetica di risparmio sui token.

Quando conviene pianificare prima di scrivere codice

Dai priorità ai lavori in cui un errore iniziale di progettazione può propagarsi. In ordine di probabile utilità, queste sono le situazioni che affronterei partendo da un piano:

Sono proposte di lavoro, non risultati misurati. Seguono la raccomandazione di Anthropic di pianificare quando l’approccio è incerto, la modifica coinvolge più file o il codice è poco familiare. Per un refuso, una riga di log già definita o una rinomina dal perimetro chiaro, chiedi direttamente la modifica. Quando Anthropic consiglia di pianificare.

Per valutare i costi, confronta i due flussi di lavoro. Con l’esecuzione diretta, investi tempo nell’implementazione e nella revisione prima di scoprire che l’approccio era sbagliato. Pianificare aggiunge all’inizio il tempo di analisi e revisione del piano, con la possibilità di evitare quel lavoro da rifare.

Pianificare conviene quando il costo del lavoro necessario, sommato all’uso aggiuntivo del modello, è inferiore al costo atteso del lavoro da rifare che consente di evitare. È un criterio decisionale, non un benchmark di risparmio di Anthropic. Usa i costi del tuo team di sviluppo e i consumi effettivi. Se il piano si limiterebbe a ripetere una modifica che sai già descrivere con precisione, saltalo.

Quali prodotti vale la pena costruirci intorno?

L’opportunità più solida è un pacchetto di revisione dei refactoring per i team: trasformare una modifica proposta in una mappa dei file, contratti da preservare, verifiche di accettazione e note sul rollback, tutto pronto per chi deve fare la review. Un responsabile tecnico potrebbe pagare per rendere più uniforme il lavoro dei diversi sviluppatori, soprattutto sulla logica di business condivisa.

Le stime DataForSEO per le keyword negli Stati Uniti, recuperate il 12 ottobre 2026, attribuiscono a “code refactoring tools” 170 ricerche al mese. È un segnale modesto di interesse per l’attività, non la prova che chi cerca acquisterà un prodotto per la revisione dei piani. La versione minima utile potrebbe ricevere un piano esportato e una mappa dei file del repository, cercare chiamanti mancanti o presupposti privi di riscontri e produrre un documento di sintesi per la pull request. Il limite è che Claude Code genera già piani generici. Per giustificare la propria esistenza, il prodotto deve offrire controlli specifici per il team e un documento utile alla revisione.

Un’opportunità più circoscritta è un pacchetto di valutazione preliminare delle migrazioni per le agenzie: produrre un inventario dei componenti coinvolti, una checklist del rilascio per fasi e un elenco delle decisioni ancora aperte prima di preventivare un aggiornamento. La stessa verifica DataForSEO stima 20 ricerche mensili negli Stati Uniti per “code migration tools”. Il volume ridotto di questa query commerciale suggerisce di verificare l’interesse con i clienti esistenti prima di costruire un prodotto di portata più ampia.

La versione minima potrebbe concentrarsi su una sola famiglia di migrazioni e richiedere, accanto a ogni modifica, i link alla documentazione pertinente del fornitore. Il problema è la manutenzione: le regole di migrazione legate a una specifica versione diventano obsolete in fretta. Plan Mode può aiutare nell’analisi, ma non fornisce un prontuario verificato per le migrazioni. Sono ipotesi di prodotto basate sulla domanda espressa dalle ricerche, non previsioni di ricavo.

Ultraplan non è più disponibile

Anthropic ha rimosso l’anteprima di ricerca Ultraplan, compresi /ultraplan, la keyword che la attivava e l’opzione di approvazione per perfezionare il piano con Ultraplan sul web. La pagina spiega che le anteprime di ricerca sono sperimentali e possono cambiare o essere rimosse in base ai feedback. Per la pianificazione rimanda a Plan Mode in locale e alle sessioni cloud di Claude Code. La pagina attuale di Anthropic su Ultraplan.

Domande frequenti prima della prossima sessione

Lunedì, prendi il prossimo refactoring che coinvolge più chiamanti della stessa logica, entra in Plan Mode e chiedi di esplicitare il comportamento da preservare, i file interessati, le verifiche e il rollback. Correggi il presupposto più debole prima di approvare. Affianca questo metodo alle pratiche di revisione più generali descritte nella guida alle best practice di Claude Code.

Se al tuo team serve un flusso ripetibile di pianificazione e revisione, possiamo integrarlo nel vostro processo di sviluppo.