Un Claude che corregge l'altro

Cos'è e perché conta

Quando una sessione di Claude Code finisce un lavoro e ti dice «fatto», viene spontaneo chiederle di ricontrollare. Funziona poco. Ha appena scritto quel codice, sa perché l'ha fatto così, e quando lo rilegge vede quello che voleva fare, non quello che ha fatto davvero.

È lo stesso punto cieco che abbiamo noi quando rileggiamo un nostro testo. Gli errori che sfuggono sono proprio quelli che non hai immaginato mentre scrivevi: il campo lasciato vuoto, il doppio clic, l'utente che apre i dati di un altro.

Per questo il controllo lo faccio fare a un'altra sessione, che parte senza la conversazione della prima. Vede solo le modifiche e un compito: trovare come romperle. Lo dice anche la guida ufficiale di Claude Code: una sessione con il contesto pulito rivede meglio il codice, perché non è legata a quello che ha appena scritto.

Perché conta: se costruisci un'app senza essere uno sviluppatore, l'occhio per vedere questi buchi non ce l'hai ancora. Un revisore che ha il compito di attaccare il codice li cerca al posto tuo, prima che li trovino gli utenti.

1. Il prompt del revisore

Questo è il prompt che incollo nella seconda sessione, parola per parola. Così com'è funziona prima del commit. Se hai già fatto commit, aggiungi in fondo quali file guardare.

Sei un revisore esterno. Non hai scritto tu questo codice e non sai perché è fatto così: non chiederlo e non cercare giustificazioni. Guarda solo le modifiche appena fatte: lancia git status e git diff, e leggi per intero i file nuovi che git status elenca (il diff non li mostra). Il tuo unico compito è trovare come romperle. Cerca:
- input: campi vuoti, testi lunghissimi, caratteri strani, numeri negativi, doppio clic, richieste doppie;
- permessi: chi può vedere o modificare dati non suoi, cosa succede senza login o con il login di un altro;
- casi limite: liste vuote, rete lenta o assente, due utenti nello stesso momento;
- sicurezza: chiavi o password nel codice, dati dell'utente usati senza controllo, errori che mostrano troppo.
Per ogni problema scrivi: dove (file e riga), come lo rompo (i passi esatti), cosa succede, gravità (alta, media, bassa). Ordina dal più grave. Non correggere niente e non modificare i file: voglio solo il rapporto.

Ogni pezzo ha un motivo.

• «Non hai scritto tu questo codice»: gli tolgo il ruolo di autore. Un autore difende il suo lavoro, un revisore esterno cerca i difetti.
• «Lancia git status e git diff, e leggi per intero i file nuovi»: git diff mostra solo le modifiche ai file che git conosce già. I file creati da zero li trova con git status, e senza questa riga resterebbero fuori.
• «Il tuo unico compito è trovare come romperle»: non gli chiedo se il codice va bene. Gli chiedo di attaccarlo, che è un'altra domanda.
• Le quattro aree, cioè input, permessi, casi limite e sicurezza, sono i punti dove si rompono più spesso le app costruite in fretta. Se la tua app ha una parte delicata, tipo i pagamenti, aggiungila come quinta riga.
• «Come lo rompo (i passi esatti)»: un problema con i passi lo verifichi tu in due minuti. Un «potrebbe esserci un problema» no.
• «Non correggere niente e non modificare i file»: il revisore segnala, non tocca. Se correggesse lui, avresti due sessioni che cambiano gli stessi file e non sapresti più chi ha fatto cosa.

2. Come lo uso

1. Quando la prima sessione dice «fatto», non le chiedo di ricontrollarsi.
2. Apro un terminale nuovo nella stessa cartella e lancio claude. Oppure, nella stessa finestra, /clear apre una conversazione nuova con il contesto vuoto. La vecchia resta salvata e la riprendi con /resume.
3. Incollo il prompt. Prima del commit, git status e git diff mostrano il lavoro appena fatto. Dopo il commit, le indico i file.
4. Porto il rapporto alla prima sessione e faccio correggere partendo dalle gravità alte.
5. Su login, pagamenti e dati degli utenti rivedo anche la correzione, in un'altra sessione nuova.

Un dettaglio su git diff: mostra le modifiche ai file che git conosce già, quindi i file nuovi non ci sono. Per questo nel prompt c'è git status, che li elenca, e il revisore li legge per intero. Se preferisci vederli anche nel diff, prima di aprire il revisore lancia git add -N . nel terminale: git li segna come file da aggiungere e da lì compaiono in git diff.

Il revisore non deve poter scrivere

Nel prompt c'è scritto di non modificare i file, ma è una richiesta, non un blocco. Se voglio esserne sicuro, apro la seconda sessione in plan mode:

claude --permission-mode plan

In plan mode Claude legge i file e può lanciare comandi per esplorare, tipo git diff, ma non modifica il codice finché non approvi un piano. Se alla fine ti propone un piano di correzioni, non approvarlo: il rapporto ti basta. Se la sessione è già aperta, ci entri premendo Shift+Tab finché in basso compare «plan mode on».

Riportare il rapporto

Nella prima sessione incollo il rapporto con un prompt così:

Ecco il rapporto di un revisore esterno: [incolla il rapporto]. Correggi prima i problemi di gravità alta, uno alla volta. Per ognuno dimmi cosa hai cambiato e come l'hai verificato. Le gravità basse non toccarle: le decido io.

Se avevo usato /clear, prima torno alla conversazione di partenza con /resume, così la sessione che corregge ha di nuovo tutto il contesto del lavoro.

Le basse le tengo per me per un motivo preciso. Un revisore a cui chiedi di trovare problemi ne trova quasi sempre qualcuno, anche quando il lavoro è fatto bene, perché è quello che gli hai chiesto. Se correggi tutto, ti ritrovi codice in più per casi che non succederanno mai.

3. Con un subagent, nella stessa finestra

Se non vuoi aprire un'altra finestra, il revisore può essere un subagent: un aiutante che lavora dentro la tua sessione, con un contesto suo, e non vede la conversazione. Nella guida sui subagent spiego come creare un code-reviewer fisso con solo gli strumenti per leggere.

Il vantaggio: il rapporto torna direttamente alla sessione che ha scritto il codice, senza copiare e incollare. Il rischio: il compito al subagent lo scrive Claude, e Claude sa perché ha fatto così. Se glielo spiega, il revisore parte già convinto. Quindi gli chiedo di passare il prompt così com'è:

Fai rivedere le ultime modifiche al subagent code-reviewer. Passagli questo prompt parola per parola, senza aggiungere spiegazioni su come o perché hai scritto il codice: [incolla il prompt del revisore]

Per le parti delicate, però, preferisco la sessione nuova: lì il prompt lo incollo io e so esattamente cosa ha ricevuto il revisore.

La regola d'oro

Niente della conversazione di prima: se le spieghi perché hai fatto così, finisce per darti ragione.

Vale anche per te. Quando incolli il prompt, non aggiungere «l'ho fatto così perché…». Dai le modifiche e il compito, e basta. Le spiegazioni servono dopo, quando decidi quali problemi correggere.

Una sessione nuova legge comunque le istruzioni del progetto (CLAUDE.md) e la memoria automatica, se le usi. Va bene: sono regole, non la storia di come è nato quel codice.

Gli errori più comuni

• Chiedere alla stessa sessione di ricontrollarsi: apri una sessione nuova, o usa /clear, così chi controlla non ha scritto il codice.
• Spiegare al revisore perché il codice è fatto così: dagli solo le modifiche e il compito, se no finisce per darti ragione.
• Lasciare che il revisore corregga: chiedigli solo il rapporto e fai correggere la sessione che ha scritto il codice.
• Correggere ogni problema segnalato: parti dalle gravità alte e le basse decidile tu, se no riempi il codice di difese inutili.
• Fidarsi solo di git diff quando ci sono file nuovi: nel diff non compaiono, quindi fai lanciare anche git status come nel prompt.
• Non rivedere la correzione sulle parti delicate: per login, pagamenti e dati degli utenti rifai la revisione in una sessione nuova.

Checklist

• Il revisore è in una sessione nuova
• Il prompt è incollato senza spiegazioni
• Prima del commit: git status e git diff. Dopo: i file indicati
• Ogni problema ha dove, passi, effetto e gravità
• Le gravità alte sono corrette e verificate
• Sulle parti delicate c'è stata una seconda revisione

Domande frequenti