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

«I test sono passati» risponde solo a una parte delle domande. Occorre sapere quali test, se coprivano il problema originale e se ci sono modifiche fuori ambito. L'accettazione parte da criteri confrontabili con codice e comportamento dell'applicazione.

Controlla tre livelli: modifiche ai file, verifiche automatiche e percorso utente. È un metodo proposto, non una garanzia di assenza di bug. Aiuta a individuare le prove mancanti.

Definire i criteri prima di iniziare

«Correggi l'invio» non basta per un modulo di contatto. Descrivi il comportamento osservabile:

Se il server restituisce un errore, i valori restano e appare un messaggio chiaro. Durante l'invio non si crea una richiesta duplicata. Dopo il successo compare una conferma.

Distingui requisiti e preferenze. Un refactoring elegante non sostituisce la correzione richiesta.

Per lavori complessi, chiedi prima di individuare le parti coinvolte e i controlli esistenti. La verifica esplicita compare anche nelle raccomandazioni di Anthropic.

• raccomandazioni di Anthropic

Livello 1: leggere il diff

Esamina i file modificati e chiarisci il ruolo di ciascuno. Una piccola correzione del modulo non dovrebbe cambiare silenziosamente autenticazione, dipendenze e 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 creato un commit, confronta i commit appropriati: il diff delle modifiche non registrate può essere vuoto. Guida git diff.

• Guida git diff

Livello 2: eseguire verifiche adatte

Chiedi comandi ed esito di ogni verifica. Distingui «avviato», «terminato» e «riuscito». Un errore dell'ambiente può interrompere un processo senza confermare o smentire la correzione.

Nessuna riga sostituisce tutte le altre. Una build riuscita non dimostra che un'email sia arrivata.

Per un difetto riproducibile, verifica che il test rilevi il vecchio comportamento e passi dopo la modifica. Altrimenti potrebbe 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. Usa dati e destinatario di test per osservare gli esiti senza vere richieste dei clienti.

Nell'automazione browser controlla il comportamento visibile con riferimenti stabili. Playwright raccomanda test isolati e locator legati a ciò che percepisce l'utente. Buone pratiche Playwright.

• Buone pratiche Playwright

Uno screenshot conferma uno stato visibile, non l'intera catena. Controlla anche i campi ricevuti dal gestore, la registrazione nel sistema di test e l'assenza di duplicati dopo un secondo clic.

Usare un secondo agente per la revisione

Fornisci incarico originale, diff e risultati disponibili. Chiedi violazioni dei requisiti e modalità di riproduzione. Non anticipare 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 aggiunge domande. La correttezza deve comunque poggiare su codice e verifiche. Riproduci uno scenario contestato invece di votare tra modelli.

Scrivere il resoconto

Conserva un documento breve e verificabile:

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.

Non nascondere l'incertezza dietro «in generale funziona». Se il servizio di test non è disponibile, dichiara che la consegna finale non è confermata.