Gli agenti scrivono più codice. Il software resta in coda.

La dashboard di un team software può raccontare una settimana straordinaria: più righe prodotte, più commit, più pull request. L’agente AI ha lavorato senza sosta e i grafici salgono. Poi si guarda la colonna delle attività effettivamente concluse e la festa finisce: il software consegnato è rimasto praticamente allo stesso punto. Non è una contraddizione. È il risultato prevedibile di un processo in cui abbiamo accelerato una fase senza aumentare la capacità delle altre.

Per anni abbiamo discusso di quanto tempo un programmatore impieghi a scrivere codice. Oggi quella domanda rischia di essere la meno interessante. Quando generare una modifica costa poco, il costo si trasferisce su chi deve capirla, provarla, approvarla, integrarla e assumersene la responsabilità. L’AI non elimina automaticamente questo lavoro. Può renderlo più urgente.

I numeri: più attività non significa più software

Fiona Chen e James Stratton, ricercatori di Harvard, hanno studiato i dati aggregati della piattaforma Jellyfish: circa 300 milioni di eventi di lavoro relativi a 725.938 persone in 718 aziende, tra gennaio 2021 e marzo 2026. La versione del paper del 4 agosto 2026 distingue gli assistenti che aiutano a scrivere codice dagli agenti che possono svolgere porzioni più autonome del lavoro. Gli autori confrontano imprese che hanno adottato gli strumenti in momenti diversi, usando un disegno osservazionale difference-in-differences.

Dopo l’adozione degli agenti, le stime riportano un aumento del 30% delle righe di codice, del 20% dei commit e del 23% delle pull request. Sono incrementi statisticamente significativi nelle misure intermedie di produzione. Quando però si passa alle issue e agli epic risolti, usati come indicatori di software completato, gli effetti stimati sono piccoli, positivi e non statisticamente significativi. Questa formulazione conta: non significa che lo studio abbia dimostrato un beneficio esattamente pari a zero, ma che non emerge un aumento sufficientemente distinguibile dal rumore statistico con quelle misure.

È una distinzione che dovrebbe interessare chiunque gestisca budget di sviluppo. Le righe di codice misurano quanto materiale attraversa una fase. Una funzionalità verificata e rilasciata misura un risultato molto più vicino al lavoro che il cliente può utilizzare. Nemmeno il numero di issue chiuse coincide automaticamente con il valore economico, ma almeno si trova più a valle della catena.

Quel 49% non è tempo di lavoro umano: è tempo che passa

Nel medesimo studio, il tempo medio tra la presentazione di una pull request e il suo merge aumenta del 49% dopo l’introduzione degli agenti. Crescono del 35% i commenti per pull request e la quota di PR che richiedono modifiche quasi raddoppia. Anche la percentuale di lavoratori impegnati nella review aumenta, del 14% in termini relativi.

Attenzione al significato del dato: il 49% riguarda il tempo di calendario attraversato dalla pull request, comprensivo delle attese, non un aumento misurato del 49% delle ore effettive trascorse a leggere codice. Confondere le due grandezze produce una diagnosi sbagliata. Una PR può attendere due giorni perché nessuno ha capacità disponibile, pur richiedendo venti minuti di revisione. Il tempo perso dal processo non coincide necessariamente con il tempo lavorato dal reviewer.

Questo è il punto interessante: la review non è un timbro alla fine della catena. È una risorsa con capacità finita. Se gli agenti aumentano la velocità con cui arrivano le modifiche, ma il team non aumenta la capacità di validarle, cresce il lavoro in attesa. Anche un codice formalmente corretto occupa attenzione: bisogna verificare che risolva il problema giusto, che non rompa un contratto esistente, che non sposti un rischio in produzione.

Un processo non diventa più veloce perché una sua fase produce di più. Diventa più veloce quando il risultato attraversa l’intera catena senza accumulare lavoro da verificare.

La coda invisibile è un problema di architettura produttiva

Immaginiamo un team che prima riceveva dieci modifiche da revisionare al giorno e riusciva a chiuderne dieci. Ora un agente ne fa arrivare tredici, ma la capacità di revisione rimane dieci. Non è una simulazione dello studio e quei numeri sono solo un esempio: servono a mostrare la dinamica. Tre modifiche restano in coda ogni giorno. Dopo una settimana la dashboard del coding sarà ancora verde, mentre il tempo necessario a ottenere una risposta si allungherà.

Nella teoria delle code questo comportamento è normale: quando il flusso in ingresso si avvicina alla capacità del servizio, anche piccole variazioni possono far crescere molto le attese. Se poi le modifiche sono più grandi, meno contestualizzate o richiedono più passaggi di correzione, la capacità effettiva del reviewer può persino diminuire. Aumentare i produttori senza progettare i consumatori non è scalabilità. È accumulo.

Nel software l’accumulo è particolarmente costoso perché una modifica in attesa invecchia. Cambia il branch principale, si aggiornano le dipendenze, arrivano altre decisioni, il contesto iniziale si perde. Quando finalmente si apre quella PR, non basta più verificare ciò che l’agente ha scritto: bisogna ricostruire perché lo ha scritto e se è ancora corretto. È una forma di debito operativo che non appare nel conteggio dei token o delle righe.

Il problema non si risolve aggiungendo un secondo agente che approva il primo

Automatizzare anche la review può aiutare, ma non basta aggiungere un bot al processo e chiamare la questione risolta. Se il reviewer automatico produce falsi positivi, commenti ridondanti o approvazioni superficiali, il carico umano cambia forma anziché sparire. La qualità della revisione va misurata, non dedotta dalla velocità con cui arrivano i commenti.

Su questo punto ho già discusso del valore di un benchmark aperto per la code review AI: precisione, recall e costo dei falsi allarmi sono più utili di una demo che trova tre bug in pochi secondi. Un reviewer efficace dovrebbe ridurre il lavoro necessario per prendere una decisione affidabile, non semplicemente generare altro testo da leggere.

C’è anche un limite architetturale: un agente può controllare regole sintattiche, test e alcune invarianti, ma la decisione su un cambiamento che tocca sicurezza, dati, comportamento di prodotto o responsabilità verso il cliente non è sempre riducibile a una checklist. Il punto non è difendere ogni passaggio manuale. È rendere esplicito dove serve ancora giudizio e dove quel giudizio può essere supportato da evidenze ripetibili.

Cinque misure che guarderei prima di dichiarare un successo

Per capire se un investimento in coding agent migliora davvero un’organizzazione, partirei da un insieme piccolo di indicatori osservati prima e dopo l’adozione. Non perché esista un numero magico, ma perché una metrica isolata si lascia ottimizzare molto facilmente senza migliorare il risultato.

• Lead time fino al rilascio: dal lavoro pronto per essere sviluppato fino al cambiamento disponibile e verificato, non soltanto fino al primo commit.
• Tempo in attesa di review: separato dal tempo di revisione attiva; senza questa distinzione si attribuisce al reviewer ciò che dipende dalla coda.
• Rilavorazioni: quante PR tornano indietro, quante iterazioni servono e quali difetti si ripetono.
• Output effettivamente concluso: issue o funzionalità chiuse con criteri di accettazione chiari, tenendo conto di dimensione e complessità.
• Qualità dopo il merge: regressioni, rollback, incidenti e interventi correttivi che il conteggio delle PR non vede.

Aggiungerei il costo operativo complessivo: tempo di chi scrive, tempo di chi verifica, infrastruttura, token, test e interventi successivi. Se il coding diventa economico ma la validazione consuma tutta la capacità dei senior, non ho eliminato il costo. L’ho spostato in una colonna diversa del consuntivo.

Come aumentare la capacità senza trasformare la review in un imbuto

La prima leva non è necessariamente assumere altri reviewer. È diminuire la quantità di lavoro che arriva loro senza contesto. Modifiche più piccole e circoscritte, descrizioni che dichiarano obiettivo e impatto, test automatici significativi, contratti di interfaccia espliciti e controlli prima della PR riducono l’incertezza che il reviewer deve risolvere. Non garantiscono codice corretto, ma rendono il controllo più economico e più mirato.

La seconda leva è limitare il lavoro in corso. Se una squadra ha dieci PR aperte in attesa, autorizzare altri cinque agenti a generarne venti non migliora il flusso. Può essere più utile far terminare ciò che è già iniziato. Questo richiede che gli agenti lavorino dentro un sistema di priorità, ownership e limiti, non come fabbriche indipendenti di commit.

La terza è progettare l’evidenza di completamento. Per un cambiamento importante voglio sapere quale requisito soddisfa, quali test sono passati, quali regressioni sono state cercate e chi o cosa ha autorizzato il passaggio successivo. È lo stesso principio che vale per gli agenti valutati su ciò che consegnano davvero: dichiarare un’azione completata non è la stessa cosa che provarne il risultato.

Che cosa lo studio non dimostra

Sarebbe comodo usare il paper come sentenza definitiva contro gli agenti AI. Sarebbe anche metodologicamente scorretto. I dati arrivano fino a marzo 2026 e il mercato cambia rapidamente; l’adozione è misurata a livello aziendale e le imprese non sono state assegnate casualmente a gruppi sperimentali. Il campione proviene dai clienti Jellyfish che hanno consentito l’uso dei dati, non da tutte le organizzazioni che sviluppano software.

Gli autori impiegano un disegno difference-in-differences e controlli per interpretare le differenze, ma rimangono ipotesi necessarie per attribuire gli effetti all’adozione. Inoltre il conteggio di issue ed epic risolti è un proxy di output, non una misura diretta di qualità percepita, fatturato o soddisfazione del cliente. Un team potrebbe migliorare risultati importanti che queste metriche non catturano. Il paper offre evidenza concreta di un collo di bottiglia nei processi osservati, non una legge eterna sull’utilità degli agenti.

Proprio per questo la conclusione operativa è più utile del titolo sensazionalistico: non chiedere a una ricerca di decidere al posto della tua organizzazione. Usala per costruire un test locale serio, con una baseline e criteri di accettazione definiti prima di guardare i grafici. Se il software arriva in produzione più rapidamente, con qualità e costi sostenibili, l’investimento ha un risultato misurabile. Se aumentano soltanto i commit, hai acquistato attività.

Il software non si consegna con un contatore

Gli agenti possono rendere la scrittura del codice molto più rapida. È una possibilità reale e lo studio non la nega. Ma la produttività di un sistema è determinata da ciò che riesce a completare, non dal componente che produce il maggior numero di eventi. Finché il collo di bottiglia resta nella verifica, celebrare le righe generate è come congratularsi con una cucina perché prepara più piatti di quanti il ristorante riesca a servire.

Il lavoro interessante, oggi, non è insegnare all’agente a scrivere ancora più codice. È progettare un processo nel quale quel codice possa diventare una modifica compresa, verificata e consegnata. Tutto il resto può essere una bellissima dashboard. Ma il cliente non compra dashboard.