GitHub Octoverse 2026: gli agenti avviano oltre il 40% delle pull request mentre l’attività cresce

GitHub ha pubblicato il suo rapporto Octoverse 2026 il 28 ottobre, riferendo che gli agenti hanno fornito la prima bozza per oltre il 40% delle pull request di settembre. Una pull request propone modifiche al codice da revisionare prima che entrino in un progetto. Il dato colloca la stesura automatizzata all’interno di un flusso di lavoro software centrale, lasciando però produttività e qualità come questioni distinte.

GitHub Octoverse 2026 segnala inoltre un’attività record sull’intera piattaforma. Questo rende più rilevante la distinzione tra produrre modifiche e consegnare software utile. Un AI coding agent, ovvero un software che svolge attività di sviluppo utilizzando un modello di IA, può generare lavoro che richiede comunque un notevole giudizio umano.

Per i responsabili engineering, la tensione centrale riguarda la crescita della produzione di codice rispetto alla capacità di valutarlo. Ricerche precedenti di METR hanno mostrato perché queste misure meritano di essere trattate separatamente. Nel frattempo, il supporto di GitHub per gli agenti di Anthropic e OpenAI colloca fornitori concorrenti nello stesso ambiente di revisione. La domanda pratica è quanto lavoro utile superi l’intero processo.

GitHub Octoverse 2026 registra un cambiamento nel modo in cui iniziano le modifiche

Secondo i risultati di Octoverse di GitHub, gli sviluppatori hanno effettuato 17,9 miliardi di push e unito 1,3 miliardi di pull request durante l’anno oggetto del rapporto. Un push invia a GitHub le modifiche al codice salvate. Il totale dei push ha superato i due anni precedenti messi insieme.

La finestra di rilevazione va dal 1° ottobre 2025 al 30 settembre 2026. La maggior parte delle cifre include progetti pubblici e privati. GitHub ha ricalcolato gli anni precedenti utilizzando definizioni comparabili, una precisazione importante nel confrontare questi dati con rapporti pubblicati in precedenza.

La quota avviata dagli agenti è salita dal 17% di marzo a oltre il 40% di settembre. GitHub definisce queste richieste in base a una prima bozza generata da un agente rilevabile.

Il dato sull’adozione misura come iniziano le modifiche proposte, non quanto software completato un agente crei autonomamente.

Questa distinzione cambia il significato del titolo. Uno sviluppatore può definire il compito, respingere un approccio iniziale, riscrivere parti del risultato e prendere la decisione di approvazione finale. Definire il lavoro risultante interamente autonomo cancellerebbe questi contributi.

Il denominatore conta altrettanto. Una quota di pull request non può essere tradotta direttamente in una quota di codice, ore lavorate o funzionalità di prodotto. Le modifiche proposte variano per dimensione, difficoltà e importanza.

Si consideri una correzione della documentazione accanto a una modifica all’autorizzazione dei pagamenti. Entrambe possono generare una pull request. I requisiti di revisione e le conseguenze differiscono sostanzialmente, anche quando la piattaforma registra ciascuna come una singola proposta.

Allo stesso modo, un numero crescente di modifiche proposte può riflettere diversi sviluppi. I team potrebbero tentare più progetti, suddividere il lavoro in parti più piccole o generare revisioni aggiuntive. Queste possibilità richiedono interpretazioni diverse.

Per questo il rapporto merita attenzione senza caricarsi di ogni conclusione associata al dibattito sull’AI coding. Documenta un cambiamento sostanziale nel comportamento di sviluppo osservabile. Stabilire il valore economico di tale comportamento richiede ulteriori prove.

Per i lettori che seguono l’adozione degli agenti GitHub, il punto di partenza utile è dunque un’attribuzione precisa. Si tratta di misurazioni della piattaforma GitHub, con le definizioni e i limiti di rilevamento dell’azienda. Non sono una stima sottoposta a verifica indipendente del contributo dell’IA a tutto lo sviluppo software.

La notizia resta importante a questi termini. La stesura è un punto di ingresso significativo nel lavoro engineering. Quando gli agenti vi partecipano, i sistemi di revisione diventano il luogo in cui le loro proposte incontrano requisiti di progetto e responsabilità umana.

Questo colloca maintainer, engineering manager e revisori della sicurezza direttamente al centro della vicenda. Le loro decisioni determinano se l’attività aggiuntiva si trasformi in software utile o in una raccolta più ampia di proposte incompiute.

Più bozze mettono sotto pressione la capacità di revisione

I team engineering beneficiano di una stesura più rapida quando riescono a valutare le modifiche risultanti senza perdere il controllo su qualità o priorità.

Si tratta di un’argomentazione operativa, non dell’affermazione che ogni team abbia già una coda di revisione sovraccarica. La pressione deriva dal flusso di lavoro: produrre una proposta e assumerne la responsabilità richiedono attività diverse.

Un revisore deve stabilire cosa intende realizzare la modifica. Deve poi determinare se l’implementazione corrisponde a tale intenzione. I test automatizzati possono supportare questa valutazione, ma la loro utilità dipende da ciò che verificano effettivamente.

Un test che conferma l’output previsto può comunque trascurare un’ipotesi errata sul comportamento dei clienti. Una modifica può soddisfare il compito assegnato pur entrando in conflitto con un’altra parte del prodotto. Sono ragioni per esaminare le prove che accompagnano una proposta.

Le conseguenze si estendono anche oltre la correttezza al momento dell’invio. Qualcuno deve mantenere l’implementazione, spiegarne le decisioni e rispondere quando i requisiti cambiano. Il codice aggiuntivo crea obblighi insieme a qualsiasi valore immediato fornisca.

Per gli engineering manager, questo solleva una questione di capacità. Se la stesura diventa più semplice, come dovrebbe un team distribuire l’attenzione tra nuove proposte, manutenzione esistente e affidabilità in produzione? Aumentare gli invii senza adeguare queste priorità rischia di spostare il vincolo più a valle.

I ricercatori DORA di Google Cloud descrivono una tensione correlata nella loro analisi dei compromessi nello sviluppo con IA. Riferiscono che il tempo risparmiato durante la creazione si sposta spesso verso audit e verifica. La loro interpretazione tratta l’IA come un amplificatore dei punti di forza e di debolezza organizzativi esistenti.

Questa osservazione offre un quadro utile per leggere i dati della piattaforma. Un team con requisiti chiari e controlli affidabili parte da una posizione diversa rispetto a uno con responsabilità poco chiare. Offrire a entrambi una stesura più rapida non elimina tali differenze.

La pressione immediata ricade sulle persone che approvano le modifiche e ne assumono le conseguenze. Un maintainer non può ragionevolmente trattare la sicurezza espressa da un agente come sostituto delle prove. Un engineering manager non può dedurre il valore per il cliente soltanto da un numero crescente di invii.

I team di sicurezza affrontano un problema simile di allocazione. Una proposta potrebbe richiedere un esame approfondito perché modifica regole di accesso, gestisce informazioni sensibili o introduce un componente esterno. La sua origine non ne determina il rischio.

Anche i team di prodotto hanno un ruolo. Un’implementazione più semplice rende più allettante perseguire richieste definite in modo vago. Criteri di accettazione chiari diventano più preziosi quando generare un’implementazione plausibile richiede meno sforzo.

Per i singoli sviluppatori, l’implicazione è più specifica del semplice imparare a fare prompting. L’abilità preziosa consiste nel collegare una modifica richiesta alle prove che funziona e che appartiene al progetto.

Ciò include preservare il ragionamento alla base delle decisioni. I team che cercano di creare una base di conoscenza consultabile affrontano una sfida correlata: mantenere disponibile il contesto tecnico quando l’autore originario è assente.

La documentazione non può approvare una modifica. Può aiutare un revisore a comprendere i vincoli da cui dipende l’approvazione. Con l’accelerazione della stesura, questo contesto condiviso merita attenzione insieme agli stessi strumenti di generazione.

Copilot, Claude e Codex competono nello stesso flusso di lavoro

Il contesto competitivo aiuta a spiegare perché l’adozione degli agenti sta diventando una questione di flusso di lavoro. Gli sviluppatori possono incontrare fornitori diversi senza abbandonare il luogo in cui i loro team discutono e approvano le modifiche.

L’annuncio di GitHub di febbraio ha introdotto i partner coding agents, inclusi Claude di Anthropic e Codex di OpenAI, in anteprima pubblica. Descriveva l’assegnazione di lavoro da GitHub e la revisione di pull request in bozza generate da tali agenti.

Quell’annuncio definisce la direzione del prodotto durante l’anno oggetto del rapporto. Non dovrebbe essere letto come un inventario completo dell’attuale disponibilità o delle condizioni di accesso.

Per GitHub, ospitare agenti concorrenti rende il flusso di lavoro di revisione una risorsa strategica accanto al proprio assistente di coding.

La piattaforma può rimanere centrale anche quando uno sviluppatore preferisce un fornitore diverso per un determinato incarico. Il lavoro necessita comunque di una destinazione, una cronologia, una discussione e un processo di approvazione.

Per Anthropic e OpenAI, comparire in questo ambiente offre un’altra via verso il lavoro di sviluppo. I loro agenti possono competere per incarichi nei quali i team già gestiscono modifiche software.

Questo confronto non stabilisce quale agente produca risultati migliori. Un accordo di distribuzione e un annuncio di prodotto non possono rispondere a questa domanda. Mostrano come i fornitori raggiungono gli utenti, non quanto affidabilmente risolvano compiti comparabili.

La distinzione conta nell’interpretare l’adozione degli agenti GitHub. Più proposte avviate dagli agenti non identificano automaticamente un fornitore vincente. L’adozione del flusso di lavoro e la concorrenza all’interno di quel flusso sono sviluppi separati.

Un esempio concreto compare nell’annuncio di febbraio: gli sviluppatori potevano assegnare un issue a un agente e ricevere una bozza da revisionare. Un issue registra un’attività o un problema richiesto. Questo conferisce alla delega un inizio riconoscibile e un risultato revisionabile.

L’importanza risiede nel passaggio di consegne. Una richiesta diventa un tentativo di implementazione, che ritorna a un sistema in cui le persone possono ispezionare le modifiche e richiedere revisioni. L’agente partecipa a una struttura di responsabilità esistente.

Per un team che valuta i fornitori, questa struttura dovrebbe rendere il confronto più significativo. La domanda pertinente è se un fornitore completi il lavoro effettivo del team con uno sforzo di revisione accettabile. Una dimostrazione ben rifinita non può stabilire questo risultato.

Si immagini di confrontare agenti su un’attività ricorrente di manutenzione. Una valutazione utile considererebbe se ogni proposta affronta la richiesta, rispetta le convenzioni del progetto e fornisce una verifica credibile. Contare i file generati risponderebbe a una domanda diversa.

Lo stesso vale per l’integrazione di un agente in un team. L’accesso allo strumento è soltanto l’inizio. Permessi, confini delle attività e responsabilità dell’approvazione richiedono ancora decisioni esplicite.

Esiste anche un vantaggio pratico nel preservare un ambiente di revisione coerente. I team possono valutare un nuovo fornitore senza sostituire contemporaneamente ogni processo circostante. Ciò rende più facile distinguere le differenze tra fornitori dai cambiamenti nel flusso di lavoro.

La vicenda competitiva sostiene quindi la tensione centrale. I fornitori stanno rendendo la stesura più accessibile in ambienti engineering consolidati. Il valore di tale accesso dipende da quanto efficacemente i team trasformano proposte concorrenti in modifiche accettate e manutenibili.

Merge più rapidi lasciano aperte importanti domande sulla qualità

GitHub riferisce che le richieste con coinvolgimento degli agenti di settembre hanno raggiunto un tasso di merge entro due settimane del 90%, contro circa l’86% delle richieste senza coinvolgimento rilevato degli agenti.

Un merge registra l’accettazione in un progetto; non stabilisce l’affidabilità a lungo termine o il valore aziendale della modifica.

Questa limitazione si applica anche alle modifiche di origine umana. L’approvazione può essere ragionevole sulla base delle evidenze disponibili, mentre i comportamenti successivi possono rivelare un’interazione trascurata. La qualità del software si manifesta nel tempo.

Un percorso più rapido verso l’accettazione può riflettere un miglioramento. Può anche riflettere differenze nei compiti inviati, nelle pratiche di progetto o nel livello di controllo richiesto. Un confronto osservazionale non può distinguere automaticamente queste spiegazioni.

La selezione delle attività è particolarmente importante. I team potrebbero delegare lavori che sanno già come specificare e verificare. Gli incarichi più ambigui potrebbero rimanere agli sviluppatori. Confrontare questi gruppi senza considerare le loro differenze rischia di sovrastimare il risultato.

Anche la possibilità opposta merita considerazione. Un agente potrebbe rendere praticabile una manutenzione in precedenza trascurata, ampliando la gamma di lavori che un team tenta di affrontare. Una valutazione corretta dovrebbe tenere conto dell’utile output aggiuntivo.

È qui che le interpretazioni semplicistiche falliscono in entrambe le direzioni. Un’attività aggiuntiva non è una prova sufficiente che ogni team sia diventato più produttivo. L’assenza di una stima universale della produttività non è una prova sufficiente che l’attività non abbia valore.

L’esperimento sulla produttività degli sviluppatori di METR illustra perché la misurazione conta. Il suo studio randomizzato di inizio 2025 ha coinvolto 16 sviluppatori esperti impegnati in 246 attività in progetti open source a loro familiari. Consentire l’uso dell’AI ha aumentato il tempo di completamento del 19%.

Questi risultati descrivono una popolazione particolare, un determinato contesto operativo e una specifica generazione di strumenti. Non dovrebbero essere trattati come una misurazione diretta delle prestazioni degli agenti alla fine del 2026.

La rilevanza dello studio in questo caso è metodologica. Osservare che gli sviluppatori usano uno strumento non dice quanto più rapidamente completino un lavoro equivalente. Questo richiede un confronto credibile.

Anche la ricerca storica deve essere aggiornata al cambiare dei comportamenti. Un risultato può rimanere valido nel suo contesto originario pur diventando meno informativo su un flusso di lavoro più recente. Trattarlo come senza tempo sarebbe un altro errore di misurazione.

I confronti sulla qualità richiedono confini altrettanto accurati. Una modifica proposta può superare i controlli esistenti aggiungendo al contempo complessità che i futuri manutentori dovranno assorbire. In alternativa, un’implementazione più ampia può eliminare una soluzione provvisoria scomoda e ridurre il lavoro futuro.

I revisori hanno quindi bisogno di evidenze collegate all’attività. Controlli pertinenti, ragionamenti comprensibili e una descrizione chiara del comportamento modificato offrono più informazioni di un’etichetta sull’origine.

Per gli acquirenti aziendali, questo crea una sfida di approvvigionamento. Le dashboard di adozione sono facili da riassumere, mentre gli incidenti evitati e gli oneri di manutenzione ridotti richiedono più tempo per essere dimostrati. Una valutazione convincente dovrebbe riconoscere questa differenza.

La conclusione appropriata è specifica. I dati di accettazione di GitHub offrono informazioni su come le modifiche attraversano la sua piattaforma. Lasciano spazio a ulteriori ricerche su rilavorazione, affidabilità, impegno dei revisori e consegna utile.

Questo divario costituisce un programma di misurazione. Non richiede di presumere né che gli agenti siano universalmente vantaggiosi né che i loro contributi siano semplice rumore.

Misurare la produttività degli agenti diventa più difficile quando il lavoro cambia

La sfida della misurazione va oltre la scelta della dashboard giusta. L’uso degli agenti può cambiare quali attività gli sviluppatori tentano e come distribuiscono la propria attenzione.

Nel suo aggiornamento sulla ricerca di produttività del febbraio 2026, METR ha dichiarato che il suo esperimento successivo forniva una stima inaffidabile degli attuali effetti dell’AI sulla produttività. Reclutamento, selezione delle attività e uso simultaneo degli agenti hanno complicato l’interpretazione.

I ricercatori ritenevano che gli sviluppatori stessero probabilmente beneficiando più di quanto suggerissero le loro stime precedenti. Hanno anche sottolineato che i loro dati offrivano evidenze deboli sull’entità di tale miglioramento.

Una valutazione affidabile deve considerare i cambiamenti nel lavoro stesso, insieme ai cambiamenti negli strumenti che lo svolgono.

Questo è importante perché un confronto su attività fisse risponde a una domanda delimitata. Può stimare come l’assistenza influenzi un incarico particolare. Non può cogliere pienamente ciò che accade quando l’assistenza modifica gli incarichi che le persone scelgono.

Supponiamo che uno sviluppatore avesse precedentemente rinviato una migrazione tediosa perché richiedeva troppo impegno concentrato. Un agente potrebbe rendere quel lavoro fattibile durante una settimana altrimenti intensa. Il beneficio include il completamento di qualcosa che sarebbe rimasto incompiuto.

Consideriamo ora il caso opposto. Una stesura più facile potrebbe incoraggiare un team a implementare una funzionalità prima di aver stabilito che gli utenti ne abbiano bisogno. L’implementazione può avere successo sul piano tecnico, consumando però attenzione che sarebbe stata impiegata meglio altrove.

Questi esempi sono possibilità analitiche, non risultati riportati dal dataset Octoverse. Spiegano perché una consegna utile necessita di un collegamento con intenzione e risultati.

Il lavoro parallelo introduce un’altra complicazione. Uno sviluppatore potrebbe rivedere una proposta mentre un agente lavora a un’attività separata. Misurare il tempo di esecuzione trascorso dell’agente come tempo di lavoro umano rappresenterebbe in modo errato questa configurazione.

Tuttavia, anche ignorare la supervisione distorcerebbe il risultato. Preparazione delle attività, interruzioni, approcci respinti e revisione finale fanno parte di una valutazione del flusso di lavoro. Il confine contabile influenza la conclusione.

Per le organizzazioni, questo favorisce diverse forme complementari di evidenza. Le valutazioni di attività comparabili possono esaminare lo sforzo di completamento. I dati operativi possono mostrare accettazione e rilavorazione. Gli esiti di prodotto possono stabilire se le modifiche consegnate abbiano aiutato gli utenti.

Nessuna singola misura coglie tutto. Questo è un motivo per dichiarare ciò che una misura rappresenta, invece di comprimere risultati diversi in un punteggio universale di produttività.

Un team potrebbe migliorare la velocità di consegna pur avendo difficoltà con la manutenzione. Un altro potrebbe ridurre lo sforzo ripetitivo senza aumentare la frequenza delle release, perché le approvazioni restano vincolate altrove. Entrambi meritano descrizioni che corrispondano alla loro esperienza effettiva.

La stessa disciplina si applica al confronto tra team. Un servizio maturo con rigorosi requisiti di affidabilità è diverso da un nuovo progetto sperimentale. Il loro numero di invii non dovrebbe trasformarsi in una classifica dell’efficacia degli sviluppatori.

GitHub Octoverse 2026 è utile come evidenza di un ambiente di sviluppo in evoluzione. Le sue implicazioni più ampie diventano più chiare quando l’attività della piattaforma viene considerata insieme agli studi a livello di attività e agli esiti organizzativi.

Per gli sviluppatori, la preoccupazione pratica è se il loro lavoro diventi più facile da completare e più facile da mantenere. Per i manager, è se questi guadagni resistano nell’intero team. Nessuna delle due domande scompare quando la stesura diventa comune.

Osservare lo sforzo di revisione, l’affidabilità e i risultati di attività comparabili

Le prossime evidenze utili dovrebbero collegare la partecipazione degli agenti a ciò che accade dopo la comparsa di una proposta. Nei prossimi mesi, i lettori dovrebbero cercare cambiamenti che chiariscano il rapporto tra stesura e consegna.

Le evidenze di follow-up più solide collegheranno il lavoro originato dagli agenti allo sforzo di revisione, agli esiti in produzione e a confronti credibili tra attività.

Il primo segnale è una migliore rendicontazione dello sforzo di revisione. I fornitori di piattaforme e i team di ingegneria dovrebbero mostrare quanta attenzione umana richiedono le proposte degli agenti accettate. Il solo tempo di attesa non può dimostrarlo.

Una richiesta può attendere in una coda senza richiedere molto sforzo ai revisori. Un’altra può avanzare rapidamente pur richiedendo una discussione intensa. Distinguere queste situazioni renderebbe le statistiche di accettazione più informative.

L’evidenza di uno sforzo di revisione in calo su lavori comparabili rafforzerebbe l’ipotesi che gli agenti migliorino l’intero flusso di lavoro. Uno sforzo crescente suggerirebbe che parte dei risparmi nella stesura si spostino nella supervisione.

I lettori dovrebbero inoltre esaminare come i team contabilizzano il lavoro respinto. Una dashboard focalizzata solo sui merge riusciti può omettere lo sforzo speso per valutare proposte che non raggiungono mai l’accettazione. Anche questi tentativi fanno parte della valutazione.

Il secondo segnale è l’affidabilità dopo l’accettazione. Cercate valutazioni che seguano le modifiche oltre il merge e verifichino se richiedano correzioni, annullamenti o risposta agli incidenti.

Un annullamento rimuove o revoca una modifica precedente. Il suo significato dipende dal contesto, poiché le decisioni di prodotto possono cambiare per ragioni non correlate alla qualità del codice. Una rendicontazione utile necessita di dettagli sufficienti per distinguere queste spiegazioni.

Un’affidabilità stabile insieme a consegne più rapide rafforzerebbe l’argomento a favore di guadagni netti. Più riparazioni successive lo qualificherebbero. Il confronto pertinente dovrebbe tenere conto del rischio dell’attività e della maturità del progetto.

Questo è particolarmente importante per gli acquirenti che valutano il deployment nell’intera organizzazione. Un progetto pilota riuscito su lavori di manutenzione delimitati non dimostra automaticamente la prontezza per sistemi sensibili. L’espansione dovrebbe produrre evidenze sul nuovo ambito.

Il terzo segnale è una ricerca aggiornata che confronti lavori equivalenti con gli strumenti attuali. Gli studi dovrebbero spiegare come gestiscono la selezione delle attività, gli agenti concorrenti e lo sforzo umano che circonda la generazione.

Un miglioramento coerente tra valutazioni credibili rafforzerebbe la tesi della produttività. Risultati misti suggerirebbero che i benefici dipendano dall’incarico, dallo sviluppatore o dall’organizzazione. Entrambi gli esiti sarebbero più utili di un’affermazione universale.

I ricercatori dovrebbero anche rendere visibili i confini. Un risultato a livello di attività, un risultato sulla consegna del team e un risultato sulla soddisfazione degli sviluppatori possono essere tutti validi. Descrivono dimensioni diverse dell’esperienza.

Per i lettori che valutano GitHub Octoverse 2026, mantenete visibili le distinzioni centrali man mano che arrivano nuovi annunci. Chiedetevi quale lavoro gli agenti iniziano, chi lo valuta e cosa accade dopo l’approvazione. Seguite se le organizzazioni pubblicano evidenze sullo sforzo di revisione e sull’affidabilità insieme all’adozione. Nel confrontare gli strumenti, cercate risultati da attività simili alle vostre, con la supervisione inclusa nella contabilizzazione. Conservate il contesto dietro le modifiche importanti affinché i futuri revisori possano comprenderne lo scopo. Il rapporto rende difficile ignorare la partecipazione degli agenti; la vostra prossima decisione dovrebbe dipendere dal lavoro che tale partecipazione aiuta a completare. Quali evidenze dimostrerebbero che il vostro team sta consegnando software più utile con meno sforzo totale?