Come usare Claude Code in VS Code senza perdere il controllo delle modifiche

Hai selezionato quattordici righe. Il problema vive lì, ma la prima richiesta dice soltanto «sistemalo». Claude può vedere il frammento e proporre una modifica plausibile. Non sa ancora quale comportamento deve restare invariato, né quale prova chiude il lavoro.

L'estensione di Claude Code porta conversazione, piano e diff dentro VS Code. Il vantaggio vero non è evitare il terminale. È poter costruire un perimetro visibile: righe scelte, file coinvolti, modifiche proposte e controlli da eseguire.

La guida ufficiale per VS Code documenta menzioni di file e cartelle, selezioni con intervalli di righe, revisione del piano e visualizzazione delle modifiche. Questi strumenti aiutano solo se li usi in un ordine preciso.

La selezione aperta è già una decisione

Quando evidenzi del testo nell'editor, Claude può riceverlo come contesto. L'indicatore vicino al prompt mostra quante righe sono selezionate e permette anche di nasconderle. Controllalo prima di inviare la richiesta.

Il dettaglio conta per due motivi. Una selezione vecchia può trascinare nel prompt codice che non c'entra più. Una selezione troppo stretta può invece togliere la funzione chiamante, il tipo condiviso o il test che spiega il comportamento.

Scrivi la richiesta con tre elementi:

Problema osservato: cosa succede ora.
Comportamento atteso: cosa deve succedere dopo.
Vincolo: cosa non deve cambiare.

Poi aggiungi la prova: test, comando, scenario manuale o output atteso. Il codice selezionato dice dove guardare. Il contratto dice perché intervenire.

Parti dalle righe, non dal repository

Usa il contesto più stretto che permette di capire il caso. Inizia dalla selezione, poi passa al file e soltanto dopo alla cartella. L'estensione supporta menzioni @ per file e directory e usa la corrispondenza approssimativa per trovarli.

Il perimetro progressivo può essere scritto così:

Più contesto non significa automaticamente più precisione. Un'intera cartella può mettere sullo stesso piano file sorgente, build generate e prove storiche. Se allargando non sai dire quale dipendenza stai cercando, fermati e chiedi prima una mappa.

Allarga il contesto per una ragione

Ogni file aggiunto deve rispondere a una domanda. Il test mostra il comportamento atteso. Il tipo condiviso mostra il contratto. La configurazione spiega una condizione d'ambiente. Il file vicino solo perché ha un nome simile non basta.

Una richiesta utile può essere: «Leggi queste righe e il test menzionato. Prima di proporre modifiche, dimmi quale dipendenza manca per spiegare il ramo di errore». Così Claude esplora per colmare un vuoto dichiarato.

Per PDF e documenti grandi, la stessa guida permette di indicare pagine specifiche. È un principio trasferibile: porta nel contesto la parte che sostiene la decisione. Il resto resta disponibile se emerge una dipendenza reale.

Separa piano, modifica e prova

Tre momenti, tre domande.

Nel piano chiedi quali file cambieranno, quale comportamento resterà invariato e come sarà verificato. Non giudicare il piano dalla quantità di passaggi. Controlla se ha nominato il punto di ingresso, il caso d'errore e la prova.

Durante la modifica verifica il perimetro. Se compare un file non previsto, chiedi il motivo prima di accettare. Una dipendenza scoperta può essere legittima. Un refactor «già che ci siamo» appartiene a un incarico diverso.

Alla prova non chiedere «funziona?». Chiedi comando, risultato, scenario coperto e limite rimasto. La checklist di verifica degli output AI aiuta a separare forma corretta, contenuto corretto e utilizzo autorizzato.

Leggi il diff come una consegna

Il diff mostra cosa è cambiato rispetto alla base. Leggilo in due direzioni. Prima riga per riga: condizioni, valori rimossi, nomi e file inattesi. Poi per comportamento: quale percorso utente o tecnico cambia davvero?

Usa quattro controlli:

1. scopo: i file toccati coincidono con il piano approvato;

2. sottrazioni: ogni riga rimossa è intenzionale;

3. contratto: input, output ed errori restano coerenti;

4. prova: il test osserva il comportamento nuovo, non solo l'assenza di errori di sintassi.

Il diff non mostra tutto. Un file generato può cambiare dopo la build. Una variabile d'ambiente può cambiare il ramo eseguito. Una modifica di interfaccia va vista nella superficie finale. Per questo la revisione del diff viene prima della prova, non al posto della prova.

Scegli la modalità di permesso adatta

Il pannello può chiedere conferma prima di applicare una modifica oppure lavorare con livelli più automatici, secondo la modalità scelta. Parti dal livello che ti permette di vedere il piano e il diff quando stai ancora definendo il comportamento.

L'accettazione automatica ha senso soltanto dentro un perimetro già provato: repository fidato, comando noto, backup disponibile e test rapido. Per un workspace ricevuto da altri, la documentazione Anthropic raccomanda anche la Restricted Mode di VS Code e una revisione attenta delle modifiche.

La modalità di permesso non sostituisce l'autorità. Se una modifica prepara un deploy, un messaggio o un aggiornamento su un servizio esterno, devi ancora distinguere il file locale dall'azione remota.

Quando passare dal pannello alla CLI

Il pannello e la CLI condividono Claude Code, ma non espongono ogni funzione nello stesso modo. La tabella ufficiale di confronto indica, per esempio, che la CLI offre tutti i comandi e le Skill, mentre l'estensione ne mostra un sottoinsieme. La configurazione dei server MCP è più completa dalla CLI.

Passa al terminale integrato quando il job richiede un comando assente nel pannello, una configurazione avanzata o un flusso ripetibile da riga di comando. Non cambiare superficie solo per abitudine. Se il lavoro è leggere una selezione, rivedere un piano e controllare il diff, il pannello tiene insieme le evidenze che ti servono.

Attenzione a un dettaglio: l'estensione include una copia privata della CLI per il pannello, ma non aggiunge il comando claude al PATH. Per eseguirlo nel terminale serve l'installazione standalone.

Chiudi con una ricevuta minima

Prima di terminare, registra:

• richiesta e comportamento atteso;

• selezione o file usati come contesto;

• file modificati rispetto al piano;

• prova eseguita e risultato;

• limite o caso non verificato.

Cinque righe bastano. Senza questa ricevuta, la sessione successiva deve ricostruire la decisione dal dialogo. Con la ricevuta, puoi riprendere dal fatto verificato e non dalla memoria di chi era davanti allo schermo.

La procedura di controllo delle modifiche offre una base per legare richiesta, variazione, prova e ritorno indietro.

Nel programma su Claude Cowork e Code di MAIKER HUB puoi portare un piccolo strumento reale in VS Code, delimitare il contesto e seguire ogni passaggio fino alla prova. Il risultato utile non è vedere Claude scrivere nell'editor. È sapere perché ha toccato quei file e quale evidenza ti permette di accettarli.