Metriche di delivery con agenti di intelligenza artificiale: cosa misurare dopo il merge

Le metriche di delivery con agenti AI hanno un problema comune: si fermano al merge. Una pull request unita viene contata come lavoro finito, e così si contano le pull request aperte, i token spesi, le righe scritte. Uno studio di Deakin University uscito il 22 settembre 2026 segue invece le modifiche degli agenti dopo il merge e mostra perché quel conteggio è incompleto. Questa guida spiega cosa dice lo studio, cosa non dice e come calcolare lunedì mattina lo stesso indicatore sul vostro repository.

Cosa dice lo studio di Deakin sulle correzioni dopo il merge

Il tasso di rientro è la quota di modifiche unite che vengono seguite da una correzione entro un tempo fissato. Wannita Takerngsaksiri, Nhat Duong e Scott Barnett, dell'Applied AI Initiatives di Deakin University, lo misurano nel preprint Who Finishes the Job?, pubblicato su arXiv il 22 settembre 2026 e aggiornato il 24.

Il campione è composto da 6.774 pull request unite da cinque agenti (OpenAI Codex, GitHub Copilot, Devin, Cursor e Claude Code) in 891 repository open source con almeno 500 stelle. Il confronto è con 5.044 pull request umane degli stessi repository. Le pull request degli agenti vanno dal 24 dicembre 2024 al 30 luglio 2025.

I numeri, come li dà la fonte

Secondo il preprint, il 4,5% delle pull request degli agenti con finestra osservabile completa riceve una correzione verificata entro 30 giorni. Nella stessa finestra e negli stessi repository, le modifiche degli agenti ricevono correzioni con un'odds ratio di 1,62 rispetto a quelle umane, con intervallo di confidenza al 95% da 1,10 a 2,39. Metà delle correzioni arriva nella prima settimana.

Le correzioni sono verificate da annotatori umani e da un giudice basato su un modello linguistico, con un accordo (kappa di Cohen) di 0,78 contro 0,77 fra due annotatori umani.

Cosa lo studio non dimostra

Lo studio non dimostra che gli agenti producano codice peggiore di quello umano in generale, e gli autori lo scrivono: i risultati valgono per cinque agenti, in repository popolari, con dati del 2025. Chi legge «1,62 volte» e conclude che il codice degli agenti è peggiore ha letto un titolo, non il documento.

I limiti dichiarati contano per chi vuole replicare il metodo. Le correzioni sono collegate alle modifiche originali tramite i file in comune entro 30 giorni, quindi quelle più lente o su file diversi sfuggono. Il campione di Claude Code è piccolo: 130 pull request, di cui 63 con la finestra completa. I commit di Codex non portano un marcatore, quindi la quota di commit scritti da agenti è una stima per difetto.

Sul finanziamento, il preprint dichiara una sovvenzione dell'Australian Composites Manufacturing CRC per un progetto sulla gestione di fabbriche di intelligenza artificiale. Non dichiara interessi commerciali legati al risultato misurato.

Il dato che pesa di più per chi organizza un team

Il secondo risultato è più utile del primo. Secondo gli autori, al momento del merge le pull request che verranno corrette e quelle che non lo saranno hanno segnali quasi identici, con effetti da trascurabili a piccoli. L'unica eccezione, dentro lo stesso repository, è il numero di commit servito per completare la modifica: dieci volte i commit corrispondono a 6,1 volte le odds di una correzione.

In pratica, né la dimensione né la descrizione della pull request vi dicono quali modifiche torneranno indietro. Per saperlo bisogna aspettare, e misurare.

Come si calcola il tasso di rientro sul proprio repository

Il tasso di rientro a 30 giorni si calcola in quattro passi e si fa con i dati che GitHub già conserva. L'idea è la stessa dello studio, semplificata per un solo repository.

Il primo passo è estrarre le pull request unite con i file toccati. Con la riga di comando di GitHub:

gh pr list --state merged --limit 500 \
  --json number,mergedAt,title,files,author,labels > merged.json

Il secondo passo è definire cosa conta come correzione: una pull request unita entro 30 giorni dopo la prima, che tocca almeno uno dei suoi file e che è di tipo correttivo (etichetta bug, prefisso fix: nel titolo, o la convenzione che usate). Il terzo è fare lo stesso conteggio sulle pull request scritte da persone, nello stesso periodo.

Il quarto passo è quello che quasi tutti saltano: controllare a mano un campione di cinquanta coppie. La corrispondenza sui file produce falsi positivi, e nello studio la precisione dei candidati viene verificata prima di essere usata. Calcolate la quota di coppie giuste e applicatela al conteggio: quel numero corretto è il vostro tasso di rientro.

Che cosa tenere e che cosa togliere dal cruscotto

Il cruscotto di un team che usa agenti dovrebbe avere quattro righe, tutte misurate sullo stesso periodo. La prima è il tasso di rientro a 30 giorni, separato fra modifiche scritte da agenti e modifiche scritte da persone. La seconda è il tempo di revisione umana per modifica. La terza è il numero di issue riaperte. La quarta è quante modifiche arrivano in produzione senza correzioni.

Le righe da togliere sono quelle che crescono quando l'agente lavora di più, a prescindere dall'esito: pull request aperte, token consumati, righe scritte. Il motivo sta nei numeri dello studio: quasi il 70% delle correzioni ai merge degli agenti (69,6%) viene dallo stesso agente, quindi un cruscotto di volume conta anche le correzioni come produzione.

Una regola pratica: ogni metrica del cruscotto deve poter peggiorare quando l'agente produce di più. Se non può peggiorare, non misura la consegna.

Dove si colloca la rilavorazione in una linea di produzione

Il metodo che sto costruendo, DETENT, tratta la rilavorazione come la misura che tiene sotto controllo tutte le altre. Sulla pagina del benchmark il guardrail dichiarato è la rilavorazione, cioè rientri e issue riaperte, e non le righe scritte. L'ultimo dei quattro livelli del benchmark è un rilascio che tiene, senza rientri. Una delle sette stazioni, Monitor, collega gli esiti osservati in produzione alle modifiche consegnate.

Questo è il punto di contatto con lo studio di Deakin: se il segnale che conta arriva dopo il merge, qualcuno deve legare quel segnale alla modifica che lo ha causato. Il quadro generale è nella pagina sull'industrializzazione della produzione di software.

Cosa fare lunedì mattina

Prima di cambiare strumenti o processi, misurate il punto di partenza. Lunedì mattina eseguite l'estrazione, definite cosa è una correzione nel vostro repository e controllate cinquanta coppie a mano. Con il numero in mano, la discussione sugli agenti smette di essere un'opinione.

Poi mettete nel modello di pull request un campo Corregge: #numero, da compilare quando una modifica ne ripara un'altra. Il collegamento esplicito costa dieci secondi a chi lo scrive e vi evita la corrispondenza sui file, con i suoi falsi positivi. È la stessa disciplina di chi controlla il codice scritto dall'intelligenza artificiale con un secondo occhio indipendente: il controllo funziona quando è parte del processo e non una buona intenzione.

Un'ultima precisazione sul metodo: confrontate sempre agenti e persone nello stesso repository e nello stesso periodo, come fanno gli autori. Un confronto fra repository diversi misura la differenza fra i repository.