Pull request degli agenti AI: cosa misura l'Octoverse 2026 e cosa deve misurare il vostro team

Le pull request degli agenti AI sono diventate la maggioranza relativa del lavoro su GitHub, e il numero che si cita di più, quel 90% di unioni, non dice quanto il vostro team consegna. Secondo l'Octoverse 2026, pubblicato da GitHub il 28 ottobre, a settembre più del 40% delle pull request è partito da una prima bozza scritta da un agente. Una pull request unita è una pull request accettata: la consegna si vede dopo. Qui leggo il rapporto come lo leggerebbe chi guida una software house e propongo il calcolo da fare sul vostro repository.

Cosa dice l'Octoverse 2026 sulle pull request scritte dagli agenti

L'Octoverse è il rapporto annuale con cui GitHub descrive l'attività sulla propria piattaforma. L'edizione Commits, pushes, reach new highs in 2026 copre il periodo dal 1° ottobre 2025 al 30 settembre 2026 e include, per la maggior parte delle metriche, repository pubblici e privati.

Secondo il rapporto, le pull request "partite da un agente", cioè quelle la cui prima bozza viene da un agente di coding che GitHub riesce a rilevare, erano il 17% a marzo e hanno superato il 40% a settembre. A settembre sono state 110 milioni, circa sei volte il volume di marzo. Le pull request unite sono passate da 538 milioni a 1,3 miliardi nei dodici mesi, con i dati dell'anno precedente ricalcolati con le stesse definizioni.

Il dato che fa titolo riguarda le unioni. Le pull request con coinvolgimento di un agente unite entro due settimane sono passate dall'83% di febbraio al 90% di settembre, mentre il gruppo di confronto, senza coinvolgimento rilevato, è rimasto intorno all'86% in entrambi i mesi.

Come GitHub dichiara i limiti dei propri numeri

GitHub scrive che il segnale degli agenti è una stima per difetto, "a floor", perché non ogni uso viene rilevato. Scrive anche che i dati descrivono l'uso osservato e non la qualità dei modelli. Nella pagina che ho letto non trovo una misura di qualità del codice, di quanto resti in produzione senza correzioni o di quanto tempo di revisione costino quelle 110 milioni di pull request. GitHub vende GitHub Copilot, che include un agente di coding: ha un interesse nel tema che misura.

Perché unita in due settimane non vuol dire consegnata

Un tasso di unione misura l'accettazione, non la durata. Se il 90% delle pull request degli agenti viene unito in due settimane, sappiamo che qualcuno ha cliccato su approva e che la modifica è entrata nel ramo principale. Non sappiamo se tre settimane dopo è arrivata una correzione, se è stata riaperta una issue, se chi ha approvato ha letto il diff o ha guardato la CI verde.

Il confronto con l'86% aggiunge poco, per due motivi. Il gruppo di controllo non è costruito per dimensione, tipo di modifica o esperienza di chi apre la pull request: lo dico io, la pagina che ho letto non descrive un controllo di questo genere. E una pull request piccola e meccanica, per esempio un aggiornamento di dipendenza, si unisce più facilmente di una funzione nuova: se gli agenti vengono usati dove il rischio è basso, il 90% riflette la scelta dei compiti più che la qualità del lavoro.

Il caso opposto è già documentato

Chi segue lo studio di Deakin University sulle correzioni dopo il merge, che ho commentato in cosa misurare dopo il merge, conosce l'altra faccia: al momento dell'unione le modifiche che verranno corrette e quelle che reggeranno hanno segnali quasi identici. Un tasso di unione alto e un tasso di correzione alto possono convivere nello stesso repository. La chiusura dell'Octoverse lo ricorda a modo suo: qualcuno deve ancora decidere se il lavoro "works, whether it belongs, and whether it's good".

Cosa calcolare lunedì mattina sul vostro repository

Per sapere cosa vi dice l'Octoverse sul vostro team servono tre numeri, calcolati sullo stesso periodo: quota di pull request partite da un agente, quota unita entro quattordici giorni, quota seguita da una correzione entro trenta. Il terzo è il solo che parla di consegna, ed è lo stesso tasso di rientro descritto nell'articolo sulle metriche.

Serve un segno coerente per riconoscere le pull request degli agenti: un'etichetta agent applicata dal flusso di lavoro, oppure il prefisso del branch. Poi, con la riga di comando di GitHub:

gh pr list --state all --limit 1000 \
  --search "created:2026-08-01..2026-10-18" \
  --json number,createdAt,mergedAt,labels > pr.json

jq '[.[] | select(any(.labels[]; .name == "agent"))]
  | { aperte: length,
      unite_14g: ([.[] | select(.mergedAt != null and
        ((.mergedAt | fromdateiso8601) - (.createdAt | fromdateiso8601)) <= 1209600)] | length) }' pr.json

L'intervallo di date esclude le pull request aperte da meno di quattordici giorni, che non hanno ancora avuto il tempo di essere unite. Ripetete il conteggio senza il filtro sull'etichetta per avere il gruppo di confronto, e poi aggiungete il campo Corregge: #numero al modello di pull request, così il terzo numero si conta senza stime. Se il tasso di unione degli agenti è più alto del vostro ma il tasso di correzione pure, il numero che conta è il secondo: il lavoro è stato accettato in fretta e ritorna.

La revisione è il passaggio dove si decide quale dei due casi avete. Come ho scritto nell'articolo sulla revisione del codice con gli agenti, un revisore che vede solo il diff non vede il contratto con il sistema esterno. Se le pull request triplicano e le persone che le leggono restano le stesse, il tasso di unione sale per una ragione che non ha niente a che fare con la qualità.

Dove sta la rilavorazione nel metodo che costruisco

Il metodo che sto costruendo, DETENT, per software house e team di sviluppo, usa la rilavorazione come freno: sul sito dichiara che il guardrail è la rilavorazione e non le righe scritte, che chi esegue non scrive le prove che lo giudicano e che prima del rilascio c'è la firma di una persona. È l'opposto di un tasso di unione: conta se la modifica regge dopo, non se è stata accettata. Il quadro è nella pagina sull'industrializzazione della produzione di software con gli agenti.

Un'annotazione sul mio modo di lavorare, perché è l'unico aggancio reale con il tema. Gli articoli di questa serie li scrive una routine guidata da istruzioni versionate nel repository, e le istruzioni le chiedono di saltare il giorno quando non ha una fonte letta. Anche qui vale la regola dell'Octoverse: l'unica cosa che il sistema può contare senza sbagliare è quanto ha pubblicato, e quello non dice se l'articolo è buono.

Il 90% di unioni è un buon dato di cronaca e un cattivo indicatore interno. Prima di citarlo in una riunione, aggiungete la riga che manca: quante di quelle pull request sono tornate.