Agenti

Le pull request le aprono gli agenti

Secondo GitHub gli agenti avviano più del 40 per cento delle pull request: il lavoro scarso non è più scrivere codice, ma specificarlo, revisionarlo, testarlo e risponderne.

  • Analisi
  • 08.11.2026
  • 5 min di lettura

Il 28 ottobre GitHub ha pubblicato Octoverse, il suo rapporto annuale sull’attività sulla piattaforma, e una riga spicca: a settembre 2026 più del 40 per cento delle pull request su GitHub è partito dalla prima bozza di un agente, contro il 17 per cento di marzo. Sono state 110 milioni di pull request nel solo mese di settembre. Lo stesso giorno, alla sua conferenza Universe, GitHub ha portato Copilot Projects in anteprima pubblica e ha reso Agentic Workflows disponibile per tutti.

Una settimana dopo Meta ha acquistato Conductor, una start-up nata per far lavorare diversi agenti di programmazione contemporaneamente. Insieme, le notizie puntano in una sola direzione: scrivere codice non è più la parte scarsa del fare software. Lo sono specificarlo, revisionarlo, testarlo e risponderne.

Che cosa ha contato GitHub

Sono numeri di GitHub, misurati sulla sua piattaforma, e vanno letti come tali. Octoverse considera una pull request avviata da un agente quando la sua prima bozza proviene da un agente di programmazione che GitHub è in grado di rilevare, e il rapporto definisce questo segnale «una soglia minima, poiché non tutto l’uso di agenti può essere rilevato». Copre repository pubblici e privati, e i dati degli anni precedenti sono stati ricalcolati sulla stessa base.

Il rapporto dice anche che le pull request degli agenti vengono ora integrate almeno altrettanto spesso delle altre. A febbraio l’83 per cento delle pull request con il coinvolgimento di agenti è stato integrato entro due settimane, contro circa l’86 per cento di quelle senza un agente rilevato; a settembre la quota degli agenti aveva raggiunto il 90 per cento. Sono anche più ampie: circa l’87 per cento modifica più di un file, contro il 79 per cento delle altre. Secondo la nostra lettura, un merge dimostra che un revisore ha accettato una modifica, non che la modifica fosse giusta.

Più agenti per persona

I prodotti che GitHub ha lanciato lo stesso giorno danno per scontato che questa quota continuerà a crescere. Copilot Projects offre al lavoro che si estende su più repository un unico posto per il suo contesto, i suoi agenti e i suoi risultati. Si descrive un obiettivo, Copilot fa lavorare agenti in parallelo, «si fa sentire quando ha bisogno di voi» e riporta risultati come pull request da revisionare. Agentic Workflows permette a un team di descrivere in Markdown compiti come lo smistamento delle issue o l’analisi di una build fallita e di farli eseguire a un agente di programmazione in GitHub Actions, con permessi di sola lettura per impostazione predefinita e un job separato che analizza le modifiche proposte prima che vengano applicate.

Il post di GitHub su Universe descrive la divisione del lavoro in una frase: «Gli sviluppatori danno la direzione, prendono le decisioni e restano responsabili di ciò che viene rilasciato». Un analista citato da InfoWorld ha spiegato che cosa significa in pratica. «Dieci sessioni parallele di agenti, per esempio, potrebbero generare dieci pull request da revisionare», ha detto Amit Kumar Jena, che guida lo sviluppo IA presso la società di consulenza Kanerika.

Settanta per cento non vuol dire finito

Un nuovo test esterno a GitHub mostra perché quella revisione non si può saltare. Il 26 ottobre ricercatori di Alibaba e di diverse università hanno pubblicato Co-Design Bench: 273 compiti tratti da 26'314 sessioni di programmazione reali, ciascuno verificato rispetto a criteri di accettazione nascosti scritti da esperti, 2'331 in tutto. Il più forte di dieci modelli, eseguito nella stessa configurazione di agente, ha soddisfatto in media il 69,9 per cento dei criteri per compito, ma ha portato a termine pienamente solo il 26,4 per cento dei compiti. The Decoder, che ha riportato lo studio l’8 novembre, ha scritto che gli agenti di programmazione «hanno ancora bisogno di una ripulitura umana in quasi tre compiti su quattro».

Lo studio ha dei limiti. Ogni compito è una richiesta fissa, quindi gli agenti non potevano fare domande né essere corretti strada facendo, la valutazione è affidata a giudici IA che possono sbagliare, e diversi autori vengono da Alibaba, il cui modello Qwen era tra quelli testati. Eppure lo scarto che misura, tra la maggior parte dei requisiti e tutti i requisiti, è esattamente quello che un revisore deve colmare.

Che cosa fanno ora i team migliori

Più che di nuovi strumenti, tutto questo ha bisogno della vecchia disciplina, applicata con più rigore. Partite dalla specifica: quando un agente prepara la bozza della modifica, il compito scritto è la vera fonte, e Jena ha avvertito che «compiti mal definiti potrebbero portare a esecuzioni ripetute, rilavorazioni e un maggiore consumo di crediti IA». Mettete per iscritto che cosa significa finito prima che l’agente inizi, così come Co-Design Bench fissa per primi i suoi criteri di accettazione.

Mantenete le modifiche abbastanza piccole da poter essere lette. GitHub dice che le stacked pull request, che suddividono un lavoro correlato in modifiche più piccole revisionate in sequenza, a settembre erano state usate da più di 264'000 sviluppatori, due mesi dopo il lancio della loro anteprima. Fate dei test il cancello d’ingresso: una modifica non dovrebbe arrivare a una persona finché non li supera, e i test stessi meritano la revisione più attenta, perché un agente che può modificare i propri test può far passare qualsiasi cosa.

Infine, indicate la persona. Ogni modifica rilasciata ha bisogno di qualcuno che l’abbia approvata e sappia spiegarla, e quel qualcuno non può essere l’agente. Il consiglio di Jena ai CIO è lo stesso: «richiedere l’approvazione umana prima che le pull request generate dagli agenti vengano integrate».

Gli strumenti si possono spegnere

L’acquisizione di Conductor aggiunge una lezione più discreta. Il 4 novembre TechCrunch ha riferito che Meta aveva acquisito la start-up, fondata nel 2024, i cui team di agenti sono «progettati per aiutare gli ingegneri del software a lavorare in modo coordinato su parti separate e compartimentate di un progetto», usando agenti di laboratori come Anthropic e OpenAI. Meta ha confermato l’acquisto ma non ha reso note le condizioni.

L’avviso di Conductor fissa il calendario. Le nuove iscrizioni si sono fermate il 4 novembre, i suoi spazi di lavoro cloud passano in sola lettura il 13 novembre, e il 20 novembre l’azienda inizia a cancellare i dati utente nel cloud, quindi i clienti hanno sedici giorni per esportare ciò che vi conservano. L’app desktop per ora continua a funzionare e inizierà a essere dismessa all’inizio del 2027. Conductor dice di non aver mai venduto i dati degli utenti né di averli usati per l’addestramento, e offre un’esportazione e un trasferimento verso l’app locale.

Niente di tutto ciò fa pensare a malafede. Mostra quanto sia ancora nuovo e instabile lo strato che fa funzionare gli agenti: un servizio che custodisce gli spazi di lavoro e le chat dei vostri agenti può essere acquistato e chiuso nel giro di poche settimane. Tenete ciò che conta in luoghi che controllate voi: il codice e la sua cronologia nel vostro repository, specifiche e decisioni messe per iscritto accanto al codice, e test che ogni agente deve superare, chiunque sia il fornitore.

Dove ci collochiamo

Werk, la nostra piattaforma per le app, è disponibile ed è costruita su questa divisione del lavoro. L’IA scrive la maggior parte del codice su un framework che abbiamo costruito noi e di cui ci fidiamo, le persone decidono che cosa costruire, progettano l’esperienza d’uso e revisionano ogni rilascio, e ogni rilascio viene testato. Il codice è vostro, e la piattaforma continua a crescere sotto di esso. Il prossimo passo verso cui lavoriamo sono agenti che rilasciano da soli modifiche e correzioni di routine, testate e revisionate prima del rilascio, e questo funziona solo quando specifica, test e revisione sono già al loro posto.