Agenti di coding: la velocità di una persona non diventa capacità del team

Una persona con un agente di coding scrive più codice, e questo ormai si misura. Che il team consegni di più, invece, non segue in automatico, ed è lì che molte software house si fanno male: comprano velocità individuale e la contabilizzano come capacità. In questo articolo sostengo che la differenza sta in cosa resta fuori dalla sessione dell'agente, e propongo due verifiche da fare sul vostro repository.

Cosa mostra lo studio di Harvard su 718 aziende

Il dato più solido che conosco sul passaggio dalla velocità personale alla consegna dell'azienda è il paper di Fiona Chen e James Stratton, Artificial Intelligence in the Firm: Bottlenecks in Software Production, un working paper di dottorato dell'università di Harvard, nella versione del 4 agosto 2026. È un job market paper, quindi non una pubblicazione con revisione paritaria.

I dati arrivano da Jellyfish, una piattaforma di analisi per team di ingegneria: circa 300 milioni di eventi di lavoro, 725.938 persone in 718 aziende, da gennaio 2021 a marzo 2026, fra attività su GitHub, issue su Jira e calendari. Il metodo è una differenza nelle differenze con adozione scaglionata: si confrontano le aziende prima e dopo l'adozione degli strumenti, sfruttando il fatto che l'adozione avviene in momenti diversi. L'adozione è misurata a livello di azienda, non di singola persona.

Per gli agenti di coding le righe di codice aggiunte crescono del 30%, i commit del 20% e le pull request del 23%, tutti effetti significativi. Per gli assistenti di completamento le stime sono più piccole, 12%, 9% e 5%, e solo quella sui commit è significativa. Sul lato dell'output, issue ed epic risolte salgono di poco ma in modo non significativo, e per gli agenti gli autori escludono un aumento superiore al 12% della media di partenza. Quel 12% è ben sotto il 30% di codice in più.

Dove si accumula il lavoro, secondo gli autori

Gli autori stimano che gli ingegneri dedichino il 30-40% del tempo a scrivere codice, e il resto a pianificare, rivedere e testare. Dopo l'adozione degli agenti il tempo medio di revisione di una pull request aumenta del 49%, la quota di pull request con modifiche richieste quasi raddoppia e i commenti per pull request crescono del 35%. La quota di persone che fanno revisione sale del 14%. Il collo di bottiglia, scrivono, non sparisce nemmeno con gli strumenti di revisione automatica.

Cosa non dice

Va letto con tre cautele. Primo, è un'osservazione, non un esperimento: la parte causale poggia sull'ipotesi che le aziende che adottano prima e dopo avrebbero avuto andamenti simili. Secondo, il campione sono clienti di Jellyfish che hanno acconsentito all'uso dei dati per ricerca, un venditore di analisi di ingegneria con un interesse nell'argomento; il paper dichiara finanziamenti da Stripe Economics of AI Fellowship, Harvard Kennedy School e Schmidt Sciences, e precisa che Jellyfish ha letto il manoscritto solo per escludere dati riservati. Terzo, "output" qui vuol dire issue chiuse su Jira, che è una misura imperfetta, e i dati si fermano a marzo 2026.

Lo studio non parla di contesto, di sessioni o di prove: quello è il mio ragionamento, e lo tengo separato dai dati.

Dove finisce la velocità di una sessione

La revisione che rallenta è la parte visibile del problema, e ne ho già scritto a partire da un benchmark di Microsoft Research sulla revisione del codice. Quello che mi interessa qui è un passo prima. Quando una persona lavora con un agente, tutto ciò che rende il lavoro rivedibile vive dentro la sessione: cosa è stato chiesto davvero, quali file e documenti l'agente ha letto, quali alternative sono state provate e scartate, perché una certa prova è considerata sufficiente. Chiusa la sessione, nel repository resta il diff.

Chi rivede riceve un diff e deve ricostruire il resto. Più codice arriva, più ricostruzioni servono, e la ricostruzione costa tempo di revisione proprio dove lo studio vede crescere i tempi. Non posso dimostrare che il 49% in più sia dovuto a questo: i dati non lo separano dalla qualità delle bozze, che gli autori indicano come seconda causa. Dico che è la parte che il team può controllare, e che costa poco da cambiare.

Lo vedo anche nel lavoro di questo blog. Gli articoli della serie li scrive una routine che parte ogni volta da un clone pulito del repository e non ricorda niente di quello precedente. Quello che sa lo sa perché è scritto: una procedura versionata, una mappa degli argomenti, una scheda di fatti verificabili e un comando, npm run blog:uscito, che elenca tutto ciò che è già uscito. Un controllo automatico blocca poi gli argomenti ripetuti. La velocità della routine non conta quanto quei file, perché sono la parte che un'altra sessione, o un'altra persona, può usare.

DETENT, il metodo che sto costruendo per software house e team di sviluppo, parte dallo stesso principio. Sul sito si legge che l'unità di lavoro è un contratto di lavorazione e non un prompt, che chi esegue non scrive le prove che lo giudicano e che prima del rilascio c'è la firma di una persona. Come ho scritto nell'articolo sul contratto di lavorazione, i campi del contratto sono esattamente ciò che altrimenti resta nella testa della sessione.

Due verifiche per lunedì mattina

La prima verifica dice se il guadagno individuale arriva alla consegna. Prendete due mesi di lavoro del team con gli agenti e contate le pull request unite per persona e le issue o le funzionalità chiuse nello stesso periodo. Per le pull request:

gh pr list --state merged --search "merged:2026-08-01..2026-09-30" --limit 500 --json number | jq length

Se le pull request per persona salgono e le issue chiuse restano ferme, avete lo stesso scarto che lo studio trova su 718 aziende. Affiancate il tempo medio dall'apertura all'approvazione, perché è lì che lo scarto si legge. Come ho spiegato nell'articolo sulle metriche di delivery con gli agenti, il volume non è una misura di consegna.

La seconda verifica dice se il lavoro dell'agente è rivedibile da chi non c'era. Scegliete cinque pull request recenti scritte con un agente e chiedete a un collega che non le ha seguite di rispondere in quindici minuti, usando solo repository e ticket, a quattro domande: cosa era stato chiesto, che contesto aveva l'agente, con quale prova si considera finito il lavoro, quali decisioni sono state prese lungo la strada. Contate le risposte che non riesce a dare. Come regola mia, non un dato: se più di due pull request su cinque restano senza risposta, quel lavoro non è trasferibile e ogni revisione lo ricostruirà da capo.

Poi portate le quattro domande nel modello di pull request come campi obbligatori: richiesta, contesto dato, prova di completamento, decisioni. Costano un minuto a chi scrive e tolgono a chi rivede la parte più cara. Questo non sostituisce la revisione, che resta una persona; la rende più veloce senza ridurre il controllo, e vale anche con un secondo agente che controlla il primo.

Il metodo di fondo è quello del quadro generale sulla industrializzazione della produzione di software con gli agenti: misurare la consegna del team, non la velocità della sessione.