Verificare il codice generato dall'IA: dal diff al percorso utente

L’agente corregge l’invio del modulo, i test passano, ma un errore del server continua a cancellare i campi compilati. Succede quando la revisione si ferma al diff e ai comandi andati a buon fine. Per accettare il codice serve una catena di prove: cosa è cambiato, quale controllo rileva il difetto e cosa accade nel percorso utente.

Controlla tre livelli: modifiche ai file, verifiche automatiche e percorso utente. Il metodo non garantisce l'assenza di bug. Ti mostra quali prove mancano ancora.

Definire i criteri prima di iniziare

Per un modulo di contatto, «correggi l'invio» è una consegna troppo vaga. Descrivi un comportamento che si possa osservare:

Se il server restituisce un errore, i dati inseriti vengono conservati e appare un messaggio chiaro. Durante l'invio non si crea una richiesta duplicata. Dopo un invio riuscito compare una conferma.

Tieni separati i requisiti dalle preferenze. Altrimenti un refactoring elegante può prendere il posto della correzione per cui il lavoro era partito.

Per un lavoro complesso, chiedi prima all'agente di individuare le parti coinvolte e i controlli esistenti. Dare all'agente un modo esplicito di verificare il proprio lavoro è indicato anche nelle raccomandazioni di Anthropic.

• raccomandazioni di Anthropic

La spiegazione dell’agente descrive un’intenzione, non un comportamento osservato. Il diff mostra la modifica. Un test verifica una condizione precisa. Eseguire il percorso collega l’interfaccia al risultato. Ogni prova ha il suo limite, e lo screenshot del messaggio di successo non dimostra che l’e-mail sia arrivata.

Livello 1: leggere il diff

Scorri l'elenco dei file modificati e chiediti perché ciascuno è stato toccato. Una piccola correzione del modulo non ha motivo di cambiare, già che c'è, autenticazione, dipendenze o distribuzione.

Controlla che:

• Restino le regole di accesso e la gestione degli errori.
• Un controllo reale non sia diventato un successo incondizionato.
• Non siano spariti test che individuavano il problema.
• Non compaiano segreti, log inutili o aggiramenti temporanei.

Usa git diff e git diff --stat. Se l'agente ha già creato un commit, confronta i commit interessati, perché il diff delle modifiche non registrate può risultare vuoto. Guida git diff.

• Guida git diff

Esegui git status --short prima di leggere il diff, perché i nuovi file possono esserne del tutto assenti. git diff confronta la directory di lavoro con l’indice, mentre git diff --cached confronta l’indice con HEAD. Per vedere in una volta tutte le modifiche tracciate non ancora committate usa git diff HEAD. I commit già creati vanno confrontati con il punto di partenza.

Livello 2: eseguire verifiche adatte

Chiedi i comandi esatti e l'esito di ogni verifica. «Avviato», «terminato» e «riuscito» non sono la stessa cosa. Un errore dell'ambiente può interrompere un processo senza confermare né smentire nulla sulla correzione.

Nessuna riga della tabella sostituisce le altre. Una build riuscita, per esempio, non dimostra che un'email sia arrivata.

Se il difetto è riproducibile, assicurati che il test fallisca sul vecchio comportamento e passi dopo la modifica. Altrimenti rischia di controllare soltanto una proprietà comoda della nuova implementazione.

Livello 3: percorrere l'applicazione

Per il modulo prova input vuoto, valore non valido, errore del server e invio riuscito. Lavora con dati e destinatario di test, così osservi l'esito senza vere richieste dei clienti.

Nei test automatici in browser controlla il comportamento visibile e appoggiati a riferimenti stabili. Playwright raccomanda test isolati e locator legati a ciò che vede l'utente. Buone pratiche Playwright.

• Buone pratiche Playwright

Uno screenshot conferma uno stato visibile, non l'intera catena. Controlla anche che il gestore abbia ricevuto i campi giusti, che la registrazione compaia nel sistema di test e che un secondo clic non abbia creato un duplicato.

Uno scenario di regressione utile: compila il modulo, provoca un errore controllato del server, verifica che i valori siano rimasti e riprova. Un secondo clic durante la richiesta non deve creare un altro invio. Simulare la risposta verifica soltanto la gestione dell’errore. La consegna reale si controlla a parte, con un destinatario di prova.

Usare un secondo agente per la revisione

Dagli l'incarico originale, il diff e i risultati che hai. Chiedigli di cercare le violazioni dei requisiti e di spiegare come riprodurre ciascuna. E non anticipargli che il primo agente ha corretto tutto.

Esempio:

Controlla le modifiche rispetto ai requisiti. Per ogni rilievo indica file, condizioni che provocano il bug e modo di verificarlo. Evita consigli generici estranei al diff. Segnala separatamente ciò che i dati disponibili non permettono di confermare.

Il secondo agente ti dà altre domande, niente di più. Il giudizio sulla correttezza poggia sempre su codice e verifiche. Se un rilievo è contestato, riproduci lo scenario. Una votazione tra modelli non dimostra nulla.

Scrivere il resoconto

Conserva un documento breve, che si possa rileggere e verificare in seguito:

Modifica: correzione e file interessati.
Verificato: comandi, condizioni ed esiti.
Scenario: azioni svolte nell'applicazione.
Non verificato: limiti dell'ambiente e domande aperte.
Decisione: accettare, correggere o chiedere altre prove.

Accetta la modifica quando puoi collegare il requisito, il diff e un risultato osservato. Conserva i comandi e gli scenari realmente eseguiti, insieme alle verifiche ancora mancanti. Se il difetto si riproduce, dai all’agente il passaggio preciso e il comportamento atteso. Serve più che chiedergli di «controllare ancora».

Fonti e verifica

Fonti tecniche e calcoli verificati il 3 ottobre 2026. Scenari e schemi sono esempi didattici di Neaptide. Non abbiamo eseguito benchmark comparativi dei prodotti.

• Claude Code · Best practices
• Git · git-diff
• Playwright · Best practices