Chi risponde del codice scritto da un agente: cosa chiedono i revisori prima di firmare

Chi risponde del codice scritto da un agente non lo decide il nome sulla pull request, lo decide chi, dopo il merge, sa spiegarlo, difenderlo e mantenerlo. Un sondaggio uscito il 15 ottobre 2026 mostra che i revisori lo sentono già: davanti a una modifica scritta da un agente chiedono più prove, si fidano meno dei test che la accompagnano e vogliono sapere chi la sa difendere. Per una software house la conseguenza è pratica, perché la pull request che non porta queste informazioni si ferma in revisione.

Cosa chiedono i revisori a una pull request scritta da un agente

Il sondaggio si intitola Plausible Is Not Enough: Trust and Evidence in AI-Authored Pull Request Review ed è un preprint su arXiv di Md Shamimur Rahman, Khairul Alam, Banani Roy e Chanchal K. Roy, del Dipartimento di informatica dell'Università del Saskatchewan. Ha raccolto 239 risposte valide da 31 paesi, e ogni persona rispondeva a domande identiche prima per le pull request scritte da una persona, poi per quelle che percepiva scritte soprattutto da un'intelligenza artificiale.

Secondo gli autori, il 64,9% dei rispondenti si fida meno delle pull request scritte da un agente, il 61,1% chiede più prove per approvarle e il 78,2% ne ha riviste almeno dieci. Gli autori dichiarano fondi dei programmi NSERC (compreso un programma a indirizzo industriale) e della Canada Foundation for Innovation, e nessun venditore di strumenti per sviluppatori compare fra i finanziatori.

Il test non basta più, serve il ragionamento di chi rivede

Per approvare una pull request scritta da una persona, il 41,0% indica come prova sufficiente i test che coprono il comportamento a rischio. Per una scritta da un agente scende al 23,8%, mentre sale dal 28,5% al 55,2% chi dice di dover ragionare da sé sui casi critici. Davanti a una parte non verificabile nei tempi, il blocco dell'approvazione passa dal 19,4% al 43,9%, e l'approvazione con l'incertezza annotata dal 19,8% al 5,5%.

La proprietà pesa. Il 29,3% indica la responsabilità poco chiara come motivo per fermare la revisione di una pull request scritta da un agente, contro il 14,6% per quelle scritte da una persona. Gli autori sintetizzano il quadro come un "evidence-ownership problem": servono prove, e qualcuno che ne risponde.

Cosa dimostra e cosa non dimostra il sondaggio

Il sondaggio dimostra come i revisori dichiarano di giudicare, non come giudicano in pratica. Gli autori stessi precisano che sono risposte raccolte con un questionario, non comportamenti osservati nei repository, e che le differenze non vanno lette come l'effetto causale dell'autore artificiale.

Il metodo ha limiti dichiarati. Le domande sulle pull request scritte da una persona comparivano sempre per prime, nello stesso ordine per tutti, quindi il confronto può risentire dell'effetto contrasto. Il campione è raccolto in modo mirato: sviluppatori di repository con attività di agenti, di progetti open source maturi e contatti su LinkedIn, per cui chi lavora su software privato o in aziende regolamentate è rappresentato meno. Le percentuali vanno lette come ordini di grandezza.

C'è poi un dato che smorza la lettura più severa. Più di un terzo dei rispondenti, il 35,2%, si fida allo stesso modo o di più delle pull request scritte da un agente, e circa metà ha mantenuto lo stesso criterio di approvazione. Gli autori concludono che l'obiettivo è una fiducia calibrata e non il sospetto di principio. Nemmeno il tempo di lavoro è misurato: il costo della revisione resta un'ipotesi.

Quel che il nome non basta a dire

Il dato che trovo più utile riguarda i documenti da avere in anticipo. Il riepilogo di cosa è stato generato e cosa modificato a mano sale dall'11,7% al 35,6% e la dichiarazione esplicita di proprietà dal 16,3% al 33,9%. Un responsabile della manutenzione indicato per nome resta invece al 13,8% contro il 12,6%. Il nome non basta: i revisori cercano la frase "posso spiegare e mantenere questa modifica".

Cosa mettere nella pull request lunedì mattina

La regola che propongo, e che è mia e non dello studio, è questa: una pull request scritta in gran parte da un agente non va in revisione senza una scheda di firma compilata da una persona. Gli autori suggeriscono di dare alle modifiche di routine solo una sintesi di provenienza e test, e di riservare assunzioni, misure e revisione del responsabile del dominio a concorrenza, sicurezza, migrazioni di dati, compatibilità delle API e prestazioni. Nel modello di pull request del repository basta una sezione di cinque campi:

## Scheda di firma
- Generato dall'agente / modificato a mano: (file o parti)
- Verificato da me di persona: (cosa ho eseguito o riletto, con quale esito)
- Prova che l'agente non ha scritto: (test, riproduzione, misura)
- Domande ancora aperte: (cosa non ho potuto verificare)
- Posso spiegare e mantenere questa modifica: sì / no, e chi se no

Il campo che decide è il terzo. I test scritti dallo stesso agente che ha scritto il codice possono passare senza toccare il comportamento che conta, come ho sostenuto nel test del codice scritto da un agente. Se il campo resta vuoto, la pull request torna all'autore prima di occupare un revisore.

La stessa idea vale fuori dal codice. Nella procedura di questo blog, la routine che lo scrive deve consegnare a fine lavoro un rapporto con le fonti lette e la loro data, le candidate scartate con il motivo e l'esito dei controlli. Il controllo automatico dichiara di non verificare che i fatti siano veri: la scheda è il modo per far vedere a una persona cosa è stato davvero controllato.

DETENT, il metodo che sto costruendo per software house e team di sviluppo, prevede la stessa separazione. Sul sito si legge che chi esegue non scrive le prove che lo giudicano e che la firma umana prima del rilascio è una stazione della linea. Il motivo per cui la revisione è il passaggio che si intasa l'ho trattato in un benchmark sulla revisione del codice, il metodo completo è nella pagina su l'industrializzazione della produzione di software.

Per misurare se la scheda funziona, confrontate per due mesi il tempo tra apertura e approvazione delle pull request con la scheda compilata e di quelle senza, e contate quante tornano indietro per prove mancanti. Se la differenza non c'è, il campo è burocrazia e va tolto. Se c'è, avete trasformato un blocco dichiarato dai revisori in un costo che si legge.