Test del codice scritto da un agente: chi scrive la prova che lo giudica
Il test del codice scritto da un agente ha un problema che non dipende dalla qualità dell'agente: se lo stesso agente scrive la modifica e la prova che la approva, la prova non è indipendente. Una pull request di ottimizzazione che arriva con tre paragrafi di spiegazione sembra validata, e lo sembra quanto una scritta da una persona. Uno studio della Purdue University uscito il 2 ottobre 2026 permette di vedere quanto vale quella somiglianza, e dove finisce.
Cosa dice lo studio della Purdue sulle pull request di ottimizzazione
Lo studio si intitola How Do Coding Agents Optimize Software and Report Performance Validation?, è firmato da Huiyun Peng, Ricardo Calvo, Kelechi G. Kalu e James C. Davis, ed è stato pubblicato su arXiv il 2 ottobre 2026. Gli autori sono della Purdue e il lavoro dichiara un finanziamento pubblico, il premio NSF numero 2343596.
Gli autori hanno raccolto 1.603.213 pull request da 2.807 repository GitHub con almeno 100 stelle, dal 24 dicembre 2024 al 1 giugno 2026, e ne hanno ricavato un campione bilanciato di 1.130 pull request di ottimizzazione scritte da agenti e 1.130 scritte da persone, per un totale di 2.260. Gli agenti sono i cinque coperti dal dataset AIDev.
Secondo lo studio, le pull request degli agenti vengono unite nel 54,4% dei casi contro il 73,3% di quelle umane, e quando vengono unite lo sono in un tempo mediano di 4,99 ore contro 19,16. L'82,3% di quelle degli agenti dichiara una validazione, contro l'80,6% delle umane, una differenza che gli autori non considerano significativa. Circa la metà delle pull request con validazione, in entrambi i gruppi, non riporta nessun numero di prestazioni.
Cosa lo studio non dimostra
Il dato più citabile è anche il più fragile da interpretare. Il tasso di unione è calcolato sullo stato del dataset al momento della raccolta, quindi una pull request ancora aperta conta come non unita, e gli autori scrivono che l'esito riflette i flussi di integrazione e non lo sforzo di revisione o la qualità della modifica. Il confronto mostra associazioni, non effetti causali.
Un secondo limite riguarda la parola "validazione". Lo studio misura la validazione documentata, non quella osservata: le etichette descrivono quello che la pull request afferma, non esperimenti che qualcuno ha verificato. L'estrattore automatico delle metriche ha una precisione dell'87,5% in un controllo a campione, e non ne è stata stimata la copertura. Infine le pull request umane sono definite per assenza di segnali di intervento dell'AI, non per conferma.
Il risultato che interessa a chi produce software è un altro: le categorie dello studio (ragionamento statico, benchmark, profiling, aneddoti) descrivono il tipo di evidenza, non chi l'ha prodotta. Nel gruppo degli agenti il ragionamento statico è la prova principale nel 51,4% dei casi, contro il 39,3% delle persone.
Chi scrive i test del codice scritto da un agente
Dichiarare che una modifica è più veloce e dimostrarlo sono due atti separati, e quando li compie lo stesso autore la revisione umana resta l'unico controllo indipendente. La frase finale dello studio dice la stessa cosa dal punto di vista della ricerca: i risultati "shift the central challenge from generating plausible optimizations to demonstrating that they work".
Per chi governa un team il punto è dove stanno le prove. Una pull request con una spiegazione accurata sembra completa a chi la legge in dieci minuti, e un agente produce spiegazioni accurate a costo quasi nullo. Nella mia lettura, il tempo di revisione pesa perché il revisore deve ricostruire da solo la misura che nessuno ha eseguito. Il discorso è parente di quello che ho fatto a proposito delle metriche di delivery con agenti AI: contare le pull request aperte non dice nulla sulla consegna, e lo stesso vale per contare le descrizioni accurate.
Questo blog è un esempio piccolo. Gli articoli li scrive una routine guidata da istruzioni versionate nel repository, e a giudicarli provvede uno script, scripts/check-industrializzazione.mjs, che la routine non modifica. Lo script controlla forma, link e divieti, non la verità dei fatti: un criterio automatico copre quello che si sa misurare e nient'altro.
Cosa cambiare lunedì mattina nelle pull request degli agenti
La regola si applica a qualunque pull request che dichiari un miglioramento, non solo a quelle sulle prestazioni. Quello che segue è mio, non viene dallo studio, ed è un'ipotesi di lavoro da provare su un repository vero.
Una prova scritta prima, in un commit separato
Prima di affidare il compito all'agente, una persona scrive la misura: uno script di benchmark o un test, committato da solo, con la soglia di accettazione già dentro. La riga del contratto di lavorazione che si chiama verifica diventa così un file che esiste prima della modifica. L'agente può eseguire lo script, non può cambiarlo, e la CI rifiuta qualunque pull request che lo tocchi.
# criterio di accettazione per una pull request di ottimizzazione
misura: "bench/ordini.bench.ts" # committata prima, non modificabile dall'agente
esecuzione: "3 volte sul commit di partenza, 3 volte sulla modifica"
soglia: "tempo mediano ridotto di almeno il 10%, nessun aumento di memoria"
senza_numeri: "la pull request si chiude senza revisione"
Un audit su dieci pull request
Prendete le ultime dieci pull request scritte da agenti con un titolo che parla di prestazioni e contate quante contengono un numero prima e dopo. Poi contate quante di quei numeri sono stati prodotti da uno script che esisteva prima della modifica. La differenza fra le due colonne è la quota di dichiarazioni che avete accettato sulla parola. Il tasso di rientro a trenta giorni completa il quadro. Un secondo agente che rilegge la modifica non sostituisce questa misura, perché recupera istruzioni perse e non dimostra che il risultato sia giusto, come spiego in controllare il codice scritto dall'AI.
DETENT, il metodo che sto costruendo per software house e team di sviluppo, parte da questo principio: il sito dichiara che chi esegue non scrive le prove che lo giudicano, e che prima del rilascio c'è la firma di una persona. Non ho risultati su clienti da raccontare, e per ora il mio argomento è questo studio più la regola sopra. Il metodo è descritto nella pagina su l'industrializzazione della produzione di software.
L'agente che sa spiegare perché il suo codice è più veloce e il team che ha misurato che lo è sono due situazioni diverse. Finché la prova la scrive chi esegue, la differenza la paga chi firma il rilascio.
Domande frequenti
Un agente di coding può scrivere i test del proprio codice?
Può scriverli, ma quei test non bastano per accettare il lavoro. Se l'agente scrive sia la modifica sia la prova, la prova misura la coerenza del lavoro con le sue stesse ipotesi. Per accettare una modifica serve almeno una prova scritta prima, da una persona o da un altro processo, e fissata in un commit separato.
Come si verifica che una pull request di un agente migliori davvero le prestazioni?
Si esegue la stessa misura sul commit di partenza e sul commit della modifica, con uno script che esisteva prima della modifica, e si confrontano i numeri con una soglia scritta in anticipo. Una descrizione che spiega perché il codice dovrebbe essere più veloce non è una misura. Senza numeri prima e dopo, la pull request non si accetta.
Perché le pull request degli agenti vengono unite meno spesso?
Lo studio della Purdue University rileva il dato, 54,4% contro 73,3% per le pull request umane, ma non ne spiega la causa. Lo stato di unione è una fotografia scattata sul dataset, e le pull request ancora aperte contano come non unite. Il dato è un'associazione, non una prova che il codice degli agenti sia peggiore.
Che differenza c'è fra validazione dichiarata e validazione osservata?
La validazione dichiarata è quello che la descrizione della pull request afferma di aver controllato. La validazione osservata è un controllo che qualcuno ha eseguito e di cui esiste il risultato. Lo studio della Purdue misura la prima, non la seconda, e lo dichiara fra i suoi limiti.