Un pool di agenti Claude produce una pull request che sembra impeccabile: dieci documenti, tutti ben collegati tra loro. Poi il reviewer automatico segnala che 30 dei 95 link relativi puntano a file inesistenti, con nomi inventati ma plausibili. Un revisore umano, sfogliando in fretta, li avrebbe approvati. E’ il punto di partenza di un articolo di Ruben Broekx su Towards Data Science: un modello linguistico genera la continuazione piu’ plausibile, e a volte la piu’ plausibile e’ finzione consegnata con totale sicurezza. Per chi lavora con coding agent, il tema e’ pratico: come revisionare gli errori e le allucinazioni alla stessa velocita’ con cui vengono prodotti.
La velocita’ ha rotto il ciclo di review
Le allucinazioni sono una costante: cio’ che e’ cambiato e’ il volume. Un singolo ingegnere lancia oggi piu’ sessioni di agenti in parallelo, ciascuna capace di produrre un diff da mille righe nel tempo di un caffe’. Produrre codice e’ diventata la parte facile; revisionarlo onestamente e’ cio’ che consuma la giornata, e il revisore umano e’ il collo di bottiglia della pipeline. Le due derive tipiche sono approvare tutto senza leggere davvero, oppure leggere ogni riga rendendo gli agenti veloci quanto un lettore umano. La conclusione dell’autore: la prima passata di review deve essere automatica, alla stessa cadenza degli agenti.
Un revisore che sbaglia in modo diverso
L’idea di far revisionare all’agente il proprio lavoro e’ la piu’ debole: un’allucinazione entrata nel diff e’, per definizione, plausibile al modello che l’ha prodotta. La ricerca lo conferma: Panickssery et al. (NeurIPS 2024) hanno mostrato che gli evaluator LLM riconoscono e favoriscono le proprie generazioni, e lavori successivi legano questo self-preference bias alla familiarita’. Provider diversi si addestrano su dati e ricette diverse, quindi sbagliano in modi diversi: quella decorrelazione e’ esattamente cio’ che serve in un review agent. Nell’esperienza dell’autore, Codex di OpenAI ha segnalato costantemente in PR scritte da Claude problemi che la review di Claude lasciava passare, dai nomi di file inventati a interi blocchi fuori tema o a violazioni di sicurezza. Attenzione pero’: Codex non e’ il “ingegnere migliore” ne’ e’ infallibile, e la review va trattata come consultiva; il potere sta nel lavorare multimodello, con modelli che colmano le lacune a vicenda.
Struttura, memoria e merge gate
Il setup e’ una singola chiamata LLM avvolta in normale ingegneria CI: due file nel repository, un workflow GitHub Actions che a ogni push raccoglie la conversazione della PR da tre superfici (commenti, review, commenti inline) e la passa a un’action composita con Codex. Tre scelte reggono il peso: la review e’ stateful (una tabella Feedback Summary traccia ogni rilievo mai sollevato, risolto o meno, in un unico commento aggiornato in place); i rifiuti motivati dell’autore vengono onorati e non riproposti; e il verdetto e’ machine-readable, con una riga finale che il workflow trasforma in un commit status verde o rosso, deliberatamente non bloccante perche’ la decisione di merge resta umana. Tra le lezioni sui costi: fissare il modello (il default che slitta gonfia il conto), limitare l’effort a medium come sweet spot issues-per-dollaro, e trattare il testo della PR come input non fidato, superficie di prompt injection, con un token a privilegi minimi che non puo’ fare push ne’ merge.
- Il valore della review nasce dalla decorrelazione: un modello di un altro provider fallisce diversamente e cattura cio’ che l’autore non vede.
- La struttura batte la qualita’ grezza del modello: tabella del ciclo di vita, regola di declino e verdetto machine-readable trasformano opinioni libere in un merge gate.
- Automatizzare entrambi i lati (autore e revisore) lascia nella coda umana solo PR gia’ pronte al merge, con una traccia auditabile.
Fonte: Don’t Let Claude Grade Its Own Homework — https://towardsdatascience.com/dont-let-claude-gaslight-you/
Hai qualcosa da aggiungere? Unisciti alla discussione.