Più codice non è più delivery

Un paper dei ricercatori di MIT e Wharton ha seguito più di 100.000 sviluppatori dall'editor fino alla release, incrociando i dati pubblici di GitHub con i registri interni di Microsoft. Il risultato ha la forma di un paradosso: gli strumenti di coding più avanzati hanno prodotto il 741% di righe di codice in più, ma le release consegnate sono aumentate del 20%. Il divario tra quello che i tool generano e quello che i team spediscono è la misura del fenomeno che domina l'ingegneria del software del 2026, e ha un nome semplice: il collo di bottiglia non è più scrivere codice, è rivederlo.

Non è un dato isolato. Nell'ultimo anno almeno sei dataset indipendenti, da categorie diverse (telemetria di prodotto, benchmark, report di ricerca, paper accademici), puntano nella stessa direzione.

Il volume sale, la delivery no

Il paper NBER w35275 (maggio 2026) copre tre generazioni di strumenti: autocomplete, assistenti conversazionali e agenti autonomi. Ognuna produce guadagni di output grezzo più grandi della precedente. L'autocomplete aumenta del 40% il volume di codice inviato in review; gli assistenti conversazionali lo portano al 140%; gli agenti autonomi al 180%.

Ma i guadagni si assottigliano man mano che si percorre la pipeline. Gli assistenti conversazionali producono quell'aumento del 741% nelle righe scritte, ma solo il 65% di codice in più sottoposto a review e appena il 20% di release in più. I ricercatori lo spiegano con quella che chiamano weak-link hypothesis: lo sviluppo software è una catena di passaggi (scrivere, integrare, rivedere, approvare, rilasciare) e l'AI accelera il primo anello, mentre i successivi richiedono ancora giudizio e coordinamento umano. Accelerare un solo anello non accelera la catena.

Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools

Founded in 1920, the NBER is a private, non-profit, non-partisan organization dedicated to conducting economic research and to disseminating research findings among academics, public policy makers, and business professionals.

NBERMert Demirer

Tre livelli di assistenza, tre gradini di paradosso

Il pattern è confermato anche dentro lo stesso report: più il tool è agentico, più il divario tra codice prodotto e codice spedito si allarga. È un effetto a gradini, non casuale. La metafora usata dai ricercatori è quella della catena con un anello debole: è l'anello debole che decide la velocità del sistema, non l'anello che hai accelerato.

PR triplicate, tempo di lavoro no

I dati di utilizzo di Linear (edizione 2026) raccontano la stessa storia dal lato del prodotto. I team che hanno collegato un coding agent sono passati da 21 a 65 pull request settimanali in due anni; i team senza agente da 8 a 10. Nel complesso, le PR aperte per workspace sono cresciute del 111% rispetto alla baseline di giugno 2024. E l'AI è ormai autrice di poco meno della metà di tutto quello che viene creato in Linear, contro meno di una issue su mille due anni fa.

Ma il tempo di lavoro non è calato. Le ore mensili dedicate a creare, valutare e commentare issue sono aumentate in quasi tutte le funzioni: l'ingegneria è cresciuta di circa il 17% su creazione e triage, e i commenti sono passati da 35 a 40 minuti al mese. Il report lo dice esplicitamente: l'AI si è "posata sopra" il lavoro esistente senza sostituirne nessuna parte, almeno finora. Più output, non meno input.

How teams build – Linear

AI usage patterns in software teams: who is adopting AI, how it reshapes where teams spend their time, and how much more they ship.

Linear

Il tempo di sviluppo non è calato

I benchmark 2026 di LinearB (8,1 milioni di PR, 4.800 team in 42 paesi) aggiungono il pezzo che manca: cosa succede a quelle PR una volta aperte. Le PR assistite da AI vengono accettate e merged al 32,7%, contro l'84,5% delle PR scritte a mano. In attesa di review restano circa 5 volte di più: oltre mille minuti contro duecento. E sono più grandi: al 75° percentile oltre 400 righe, contro le 157 di una PR umana.

https://linearb.io/dev-interrupted/podcast/linearb-2026-benchmarks-ai-pr-merge-rate

Perché la review non regge

Il report Faros AI (10.000 sviluppatori, 1.255 team) ha quantificato il fenomeno con telemetria su due anni: i team ad alta adozione AI completano il 21% di task in più e mergiano il 98% di PR in più, ma il tempo di review cresce del 91%, la dimensione media delle PR del 154% e i bug per sviluppatore del 9%. Al livello di azienda, la correlazione tra adozione AI e miglioramento delle metriche semplicemente scompare.

I ricercatori citano la legge di Amdahl: un sistema si muove alla velocità del suo anello più lento, e i guadagni a monte vengono assorbiti dai colli di bottiglia a valle.

Il paper di Sabry Farrag (University of East London, arXiv:2605.01160, 2026) ha formalizzato il fenomeno come "Productivity-Reliability Paradox", incrociando 67 fonti dal 2022 al 2026: lo definisce un problema strutturale, non un bug dei tool. Due meccanismi lo amplificano: il collo di bottiglia della review (il codice generato è plausibile per costruzione, non corretto per costruzione, e ogni PR in più richiede giudizio umano) e il vincolo della context window (l'agente deriva dall'intento originale man mano che la sessione si allunga). L'analisi task-stratificata di Pinna et al. (MSR 2026), su 7.156 PR di cinque agenti, aggiunge un dettaglio: il tasso di accettazione varia del 29 punti percentuali tra tipi di task (84% per le chore, 55,4% per le performance), e nessun agente è il migliore su tutto. Il codice che arriva in review non è uniforme: la fatica di verifica dipende dal tipo di lavoro, e cresce con la complessità.

The AI Productivity Paradox Research Report

Key findings from the AI Productivity Paradox Report 2025. Research reveals AI coding assistants increase developer output, but not company productivity. Uncover strategies and enablers for a measurable return on investment.

Faros AIFaros Research

The Productivity-Reliability Paradox: Specification-Driven Governance for AI-Augmented Software Development

Since 2022, AI-powered coding assistants have produced contradictory evidence: controlled studies report 20-56% productivity gains on well-scoped tasks, while the most rigorous RCT documents a 19% slowdown for experienced developers, and telemetry across 10,000+ developers shows 98% more pull requests but 91% longer review times with flat delivery metrics. This paper argues these findings constitute the Productivity-Reliability Paradox (PRP): a systematic phenomenon emerging from non-deterministic code generators and insufficient specification discipline. Through a multivocal literature review of 67 sources (2022-2026), this paper: (1) formally defines the PRP with three moderating variables (task abstraction, codebase maturity, developer experience) and two amplifying mechanisms (code review bottleneck, context window constraint); (2) proposes the AI-Augmented Methodology Taxonomy (AAMT), classifying six methodologies under three AI integration tiers; (3) introduces the Specification Governance Model (SGM), grounded in Transaction Cost Economics, with a practical governance decision guide; and (4) evaluates Spec Kit and TDAD as SGM instantiations via a four-month pilot study. Specification discipline, not model capability, is the binding constraint on AI-assisted software dependability.

arXiv.orgSabry E. Farrag

Comparing AI Coding Agents: A Task-Stratified Analysis of Pull Request Acceptance

The rapid adoption of AI-powered coding assistants is transforming software development practices, yet systematic comparisons of their effectiveness across different task types and over time remain limited. This paper presents an empirical study comparing five popular agents (OpenAI Codex, GitHub Copilot, Devin, Cursor, and Claude Code), analyzing 7,156 pull requests (PRs) from the AIDev dataset. Temporal trend analysis reveals heterogeneous evolution patterns: Devin exhibits the only consistent positive trend in acceptance rate (+0.77% per week over 32 weeks), whereas other agents remain largely stable. Our analysis suggests that the PR task type is a dominant factor influencing acceptance rates: documentation tasks achieve 82.1% acceptance compared to 66.1% for new features - a 16 percentage point gap that exceeds typical inter-agent variance for most tasks. OpenAI Codex achieves consistently high acceptance rates across all nine task categories (59.6%-88.6%), with stratified Chi-square tests confirming statistically significant advantages over other agents in several task categories. However, no single agent performs best across all task types: Claude Code leads in documentation (92.3%) and features (72.6%), while Cursor excels in fix tasks (80.4%).

arXiv.orgGiovanni Pinna

Legge di Amdahl - Wikipedia

Wikimedia Foundation, Inc.Contributori ai progetti Wikimedia

Il conto del primo trimestre

Messi insieme, questi numeri producono una conseguenza operativa. La capacità di review di un team è un vincolo rigido: ore di attenzione umana per settimana, poco comprimibili. Se l'adozione di un coding agent triplica le PR in arrivo (come nei dati Linear, da 21 a 65) senza che il processo di review venga adeguato, l'attenzione disponibile per ogni singola change si riduce di un fattore tre. Il sistema reagisce in due modi, entrambi misurabili: le PR restano in coda più a lungo (il pickup time 5 volte più alto di LinearB) oppure vengono riviste in fretta e male, con quel fenomeno che i benchmark chiamano "rubber stamping", la timbratura di comodo.

Nel report LinearB il dato è quasi paradossale: le PR AI, una volta prese in carico, vengono riviste più velocemente di quelle umane (194 minuti contro 252), perché chi le apre le scansiona invece di capirle.

Non è una questione di qualità del modello: è aritmetica della capacità di verifica.

La previsione che ne deriva è falsificabile: un team che adotta un coding agent senza investire in un processo di review proporzionato vede peggiorare il lead time di merge già entro il primo trimestre, anche se il volume di codice prodotto sale. Chi osserva solo il volume di PR aperte vede un successo. Chi osserva il merge rate e il cycle time vede il collo di bottiglia che si è semplicemente spostato.

Misurare il merge rate, non il volume

La conseguenza pratica è una sola: cambiare la dashboard. La metrica di adozione non è quante PR apre l'agente, ma quante ne arrivano in produzione, in quanto tempo, e con quale differenziale rispetto al lavoro umano. Tre indicatori coprono il fenomeno:

1. Merge rate differenziale: la quota di PR AI merged entro 30 giorni, confrontata con quella delle PR umane. Il divario 32,7% contro 84,5% di LinearB è la baseline di riferimento.
2. Cycle time: dal primo commit alla merge, separando il tempo in coda dal tempo effettivo di review. Il pickup time è dove si accumula il danno.
3. Dimensione media delle PR: il proxy più economico della fatica di verifica. Sotto le 300 righe, come raccomandano i benchmark, la review umana tiene il passo; sopra, degenera in timbratura.

Chi adotta un coding agent senza toccare il processo di review sta ottimizzando il primo anello della catena. I dati del 2026, da quattro categorie di fonti indipendenti, dicono che gli altri anelli non sono stati ancora accelerati. E la weak-link hypothesis avverte: finché non lo saranno, la velocità di scrittura del codice è la metrica meno utile che un team possa monitorare.