Come rivedere le modifiche al codice dell’IA prima di accettarle

Esamina il codice presente nel repository, non soltanto il riepilogo dell’agente. Una spiegazione convincente può accompagnare una correzione incompleta, un test mai eseguito o modifiche estranee. Separa comportamento richiesto, cambiamenti effettivi e prove di verifica prima di accettare il risultato.

Mono Code ti permette di aprire i file del progetto, lavorare con agenti di programmazione e vedere le modifiche Git direttamente nell’editor. Questa guida riguarda la revisione di una piccola modifica già conclusa; la guida alla programmazione remota spiega come collegarti. Il repository e i comandi restano sempre sul tuo computer, l’host. Mono non è ancora disponibile; puoi iscriverti alla lista d’attesa.

1. Riformula il criterio di accettazione

Usa un esempio concreto: un modulo fittizio accetta un titolo di attività composto solo da spazi. La correzione richiesta deve rifiutarlo, preservando i titoli normali. Prima di esaminare la patch, scrivi le condizioni:

• I titoli vuoti o composti solo da spazi non possono essere inviati.
• Un titolo normale continua a essere inviato correttamente.
• L’utente vede un messaggio di validazione utile.
• Gli altri comportamenti del modulo rispettano l’ambito concordato.

Tieni questa breve lista accanto al diff. Offre una base per valutare il cambiamento anziché aderire alla spiegazione dell’agente. Se la richiesta iniziale era ambigua, chiarisci il comportamento prima di accettare un’implementazione più ampia.

2. Accerta lo stato del repository

Conferma host, cartella del progetto e ramo. Confronta l’elenco dei file modificati con lo stato iniziale registrato prima del lavoro dell’agente. Le modifiche preesistenti dell’utente non diventano dell’agente solo perché compaiono nello stesso file.

In un terminale sull’host previsto, questi comandi di sola lettura possono aiutare:

git status --short
git diff --stat
git diff -- path/to/file
git diff --cached -- path/to/file

Sostituisci il percorso d’esempio. git diff mostra le modifiche non aggiunte all’indice; --cached confronta quelle nell’indice con il commit. Esamina separatamente i file non tracciati. La documentazione di Git diff spiega questi confronti. Un albero di lavoro pulito non rivela se l’agente abbia già creato un commit: in quel caso controlla la cronologia pertinente.

3. Leggi la patch e il codice circostante

Nell’editor di Mono il margine segna le righe aggiunte e modificate, e toccando un segno si apre il diff di quella parte. È un modo comodo per guardare una modifica, non la prova di averle controllate tutte. Un segno mancante o non aggiornato non significa che il file sia rimasto uguale.

Per l’esempio del titolo, trova la condizione di validazione e segui il flusso successivo. Controlla il valore normalizzato? L’errore è visibile? L’invio si interrompe? Esamina il contesto invece di approvare una condizione isolata senza il suo chiamante.

Controlla file nuovi, codice eliminato, dipendenze e formattazione fuori ambito. Una spiegazione breve non giustifica un grande diff inspiegato. Passa all’host o a uno schermo più grande se le righe sono troncate o la modifica è troppo larga da leggere con sicurezza.

4. Collega i test al comportamento

Chiedi il comando realmente eseguito, il risultato e i controlli saltati. «I test dovrebbero passare» è una previsione, non un risultato registrato. Anche una suite riuscita deve includere un caso pertinente al difetto segnalato.

Una verifica manuale può essere adatta al messaggio visibile; un test automatico di regressione può proteggere la regola di validazione. Scegli prove che dimostrino il cambiamento, non test che ne ripetano l’implementazione. Se l’ambiente impedisce i test, documenta esplicitamente il limite e decidi dove completare la verifica mancante.

5. Risolvi i problemi senza perdere altro lavoro

Dai indicazioni precise: «Il titolo di soli spazi è rifiutato, ma l’errore non appare» oppure «Spiega perché è cambiato il file delle dipendenze per questa validazione». Indica comportamento e file invece di dire solo «riprova».

Evita reset o ripristini globali per rimuovere una piccola modifica se esiste altro lavoro. Chiedi una correzione mirata e controlla il nuovo diff. Ripeti i controlli interessati dopo la correzione: un successo precedente non verifica cambiamenti successivi.

Autorizzare un comando e accettare il codice sono decisioni separate. Approvare un test non autorizza commit, merge o distribuzione. La guida alla revisione dei permessi riguarda l’operazione stessa.

6. Lascia un passaggio di consegne verificabile

Registra la conclusione in una nota breve:

Comportamento richiesto: Rifiutare titoli di attività vuoti.
File esaminati: Elencare i percorsi effettivi.
Prove: Comandi, risultati e verifiche manuali pertinenti.
Questioni aperte: Cosa non è ancora verificato.
Prossima decisione: Accettare, chiedere una correzione o rinviare.

Mantieni esplicite le azioni di commit e rilascio. Per conservare la conversazione, esportala in Markdown, ma conserva anche i veri file del progetto. La trascrizione registra la discussione; repository e controlli verificati stabiliscono cosa è cambiato.