Il paradosso della velocity AI: perché ci fermiamo al 10%

L'AI coding è ovunque. Il 90% degli sviluppatori la usa quotidianamente secondo il DORA Report 2025. Le aziende hanno firmato gli account aziendali, Jensen Huang parla di budget annuali di token per ingegnere, Claude Code e Copilot sono infrastruttura.

E poi arriva il conto: la velocity aziendale reale — quella che misura cosa arriva davvero in produzione — cresce in aggregato di circa il 10%. Non del 10x promesso nei keynote. Non del 55% dello studio GitHub del 2023. Circa il 10%, e su alcuni setup meno ancora. Il paper METR ha misurato che su progetti open source di lungo corso i dev esperti sono -19% più lenti con l'AI. Credendo, in media, di essere stati il 20% più veloci.

C'è un soffitto invisibile. E non è un problema di modello: Opus 4.7 e GPT-5.4 sono ottimi, il bottleneck è da un'altra parte. Sono cinque forze umane e organizzative che tengono la velocity reale incollata al 10%. Vale la pena guardarle una per una, perché se ne vedi due o tre nel tuo team sai già dove stai perdendo il grosso del potenziale.

Forza 1: gli incentivi remano contro la velocity reale

Un paper pubblicato su Harvard Business Review nell'agosto 2025 ha studiato quasi 29.000 ingegneri in una grande azienda tech, un anno dopo il rollout di un AI coding assistant. Il dato più sgradevole: quando i reviewer credevano che un ingegnere avesse usato AI, valutavano la sua competenza il 9% in meno, a parità di lavoro consegnato. Penalità più severa per donne e over-40.

Oggi, a un anno di distanza, quel numero è più sfumato. Nel 2026 dichiarare di usare l'AI non ti fa più sentire uno sfigato come succedeva a metà 2025 — i manager ci sono dentro anche loro, i bravi la usano, il taboo si è ammorbidito. Ma la dinamica di fondo non è sparita: è diventata incertezza sulla reazione. Sai che nessuno ti scrive che sei scarso perché usi AI. Ma se raddoppi la velocity visibile, cosa succede davvero? Il manager la premia? Il tuo team si aspetta che tieni quel ritmo? Ti danno altri tre task? Ti stimano meno le prossime volte? Non lo sai. Per questo la maggior parte dei dev — non per malafede, per prudenza — accelera un po' meno di quanto potrebbe.

Il secondo incentivo è ancora più strutturale ed è il vero elefante nella stanza: scrivere in metà tempo non raddoppia lo stipendio. E nessuno, oggi, sta ragionando seriamente su modelli in cui essere pagati a tempo smette di essere vantaggioso per l'azienda e diventa svantaggioso per il dev.

Lo sviluppo software è quasi tutto costruito su proxy del tempo. Stime in story point, sprint, day rate per i consulenti, RAL calibrata su "quanto uno consegna in un trimestre". Sono tutti modelli che assumono implicitamente che la velocity abbia un tetto fisso per persona. L'AI toglie quel tetto — ma la compensation fa finta che ci sia ancora. Se stimi un task in cinque giorni e lo chiudi in due, non guadagni tre giorni di carriera: guadagni tre giorni di aria, e a lungo termine stime più aggressive.

Nessuno è stupido. La scelta razionale è non mostrare l'intero guadagno. Se prima chiudevi un task in cinque giorni e adesso lo chiudi in due, la stima rimane cinque. La differenza diventa buffer, tempo di pensare, o — più onestamente — tempo per altre cose. È razionalità di fronte a un sistema di ricompensa che non è stato aggiornato.

Gergely Orosz, nella sua survey del 2026 su 900+ sviluppatori, ha notato che circa il 5% tiene abbonamenti AI personali separati da quelli aziendali. È un segnale debole ma esplicito: l'uso più intenso avviene fuori dal perimetro aziendale, dove non viene misurato e non viene sotto compensato.

La velocity reale di chi usa bene l'AI esiste. Finché paghiamo il tempo invece del valore, continuerà a non comparire nelle dashboard.

Forza 2: la review la facciamo ancora senza AI (e il verify non esiste)

Il report Faros AI su 10.000+ dev e 1.255 team dà la misura numerica del fenomeno:

+21% task completati
+98% PR mergeate
+91% tempo di review PR
+154% dimensione media PR
+9% bug per developer
Metriche DORA di delivery piatte

A prima vista si legge come "la review è il nuovo bottleneck". In realtà il problema è più preciso: la scrittura del codice è diventata AI-assistita, la review è rimasta umana da sola. Un dev con Claude Code apre una PR da 800 righe in mezza giornata. Il reviewer la apre, e ci mette dentro gli stessi occhi umani che ci metteva prima — senza un agente che gli pre-legga il diff, gli sottolinei le 15 righe che contano, confronti il cambio contro la spec, esegua un property-based test mirato.

Il risultato operativo è quello che tutti conosciamo, ma che pochi dicono ad alta voce: a un certo punto della review, finisci per approvare. "Vabbè, lasciamo andare, lo vediamo in staging." Non è lassismo, è il tetto umano dell'attenzione. Se pompi dal lato della generazione di un ordine di grandezza senza fare niente dal lato della review, il tuo QA non scala — cede. E cede con una dinamica silenziosa: non più bug evidenti, ma più bug che passano perché nessuno ha avuto l'energia per guardarli bene.

Il livello di verify che oggi non fa nessuno

C'è un pezzo ancora più interessante, e sottovalutato, di tutto questo discorso. Guardiamo a cosa un agente AI produce oggi, in una sessione di lavoro reale:

Un piano. Prima di toccare il codice, scrive un piano strutturato: step, file da modificare, invarianti, rischi, ordine di esecuzione.
Una progettazione. Se glielo chiedi, abbozza un design prima di implementare — nomi, interfacce, scelte architetturali.
Step di validazione. A ogni tappa può riportare cosa ha verificato, cosa non ha verificato, cosa assume.

E ora la domanda scomoda: chi fa la review di queste cose? Chi fa il verify dei piani dell'agente? Chi ne controlla la progettazione prima dell'implementazione? Chi valida ciò che l'agente dichiara di aver validato? Chi tiene traccia dei piani successivi nel tempo?

La risposta onesta, nella maggior parte dei team, è: nessuno. Saltiamo direttamente al diff di codice, che è l'unico artefatto che la cultura del team sa leggere. Gli artefatti a monte — piano, progettazione, step di verifica — vengono scartati come rumore o lasciati in una chat che domani nessuno aprirà più.

Eppure, se ti ci fermi un secondo, il piano che un agente AI moderno sa produrre è spesso un contratto più preciso della user story che quel lavoro aveva in origine. La user story in Jira o Linear è due righe di prosa scritte di fretta da un PM. Il piano di un agente su un task non banale è facilmente qualche centinaio di righe strutturate: analisi dei file coinvolti, step numerati, dipendenze, invarianti, rischi, precondizioni, criteri di accettazione, rollback plan. È letteralmente un documento migliore, più lungo e più rigoroso di quello che l'azienda ha prodotto come fonte di verità — e lo stiamo buttando via dopo averlo letto di sfuggita.

Questo è il vero livello dove la review dovrebbe spostarsi: prima del codice, sul piano. Un team che impara a leggere e correggere i piani dei suoi agenti prima che implementino, sblocca il bottleneck a monte e arriva alla review di codice con artefatti già allineati. Nessuno, quasi, lo sta facendo.

Addy Osmani ha dato un nome elegante all'effetto aggregato: comprehension debt — il divario crescente tra quanto codice esiste nel sistema e quanto un umano ne capisce davvero. La frase che chiude il cerchio: "Junior engineers now generate code faster than senior engineers can audit it." Vale per il codice. Vale ancora di più per i piani, che nessuno sta nemmeno leggendo.

Forza 3: il trust sta crollando, non salendo

Si tende a immaginare una curva di fiducia che sale man mano che i modelli migliorano. I dati mostrano l'opposto.

Stack Overflow Developer Survey 2025, oltre 49.000 rispondenti:

84% usa AI nei workflow (adozione alta)
29% si fida dell'accuratezza — giù da 40% nel 2024. Undici punti in un anno.
46% attivamente diffida
Solo il 3% "highly trust" l'output
66% spende più tempo a correggere codice AI-generato

Un dato interessante della survey: nel segmento che si dichiara più esperto, solo il 2,6% risponde "highly trust" e il 20% "highly distrust" — la diffidenza è più alta della media. Non è luddismo, è che chi paga davvero il costo della review dubita di più: lo vede tutti i giorni, il codice "quasi corretto, ma non proprio", che è la frustrazione citata dal 45% dei rispondenti. È però un dato di popolazione, non un ritratto del singolo: sulla capacità reale di usare l'AI conta molto più l'atteggiamento individuale della seniority anagrafica.

Il DORA Report 2025 riassume il fenomeno in una formula che vale la pena ricordare: "AI amplifica, non trasforma". I team forti ne traggono valore. I team in difficoltà peggiorano. Non c'è un effetto di livellamento.

Forza 4: da solo sei allineato, in team no

È il punto che mi interessa di più, perché non ha un paper dedicato ma lo si vede ovunque nei thread di Hacker News, LeadDev e nei post di Simon Willison. E spesso viene raccontato male.

Willison dichiara di essere 2-5x più produttivo sui suoi progetti personali con Claude Code. Il METR misura -19% su progetti OSS di lungo corso. Si tende a spiegarlo dicendo "eh, sui progetti personali non ci sono standard, quindi fai quello che vuoi e vai veloce". Non è così, o almeno non per un dev bravo. Un dev bravo, anche sui suoi progetti, fa test, scrive documentazione, rispetta pattern, mantiene la codebase pulita. La differenza non è il rigore. La differenza è un'altra: quando sei da solo, sei allineato con te stesso. Non hai gap da colmare.

Metti in fila cosa evapora quando lavori da solo:

Zero gap di comunicazione (non devi spiegare a nessuno cosa stai facendo)
Zero gap di fiducia sull'AI (tu ti fidi del tuo setup, non devi convincere altri)
Zero gap di pratica (sai come usi gli agenti, nessuno deve allinearsi al tuo stile)
Zero gap di processo (decidi tu quando mergeare, testare, rilasciare)
Zero gap di priorità (non ci sono stakeholder che cambiano idea mercoledì)

Quando sei così allineato, la velocity dell'AI si traduce direttamente in risultato. Arrivi al punto, vedi il prodotto funzionante, hai la dopamina, ti premia il risultato stesso. È un ciclo che si autoalimenta.

Al lavoro in un team è l'opposto, oggi:

La review è obbligatoria, e la fanno persone che magari non si fidano ancora dell'AI (Forza 3: 46% diffida, 3% "highly trust")
Il tuo collega usa un agente diverso dal tuo, con uno stile diverso, e non avete concordato niente
Il PM aggiunge un requisito in standup e la tua pianificazione salta
Integrazione continua, staging, processi di release che non sono stati pensati per 98% più PR
Metà del team vuole spingere, metà vuole frenare

Non è che gli standard aziendali siano il problema — gli standard sono giusti. Il problema è che le best practice di lavoro con l'AI, a livello di team, ancora non esistono.

Ci sono voluti anni — decine di anni — per arrivare alle best practice condivise del coding "normale": trunk-based development, code review asincrone, CI/CD, TDD dove serve, pair programming dove serve, definition of done. Sono convergenze culturali costate riunioni, libri, errori, retrospettive. Per l'AI siamo all'anno zero. Come usiamo gli agenti in team? Come condividiamo i piani? Chi revisiona il piano prima del codice? Quando si lavora in parallelo, come si evita che due agenti generino codice in conflitto? Nessuno lo sa ancora, o meglio, ogni team lo sta inventando da zero — e la maggior parte sta inventando male.

Il dev che in due settimane si costruisce un SaaS completo a casa sua esiste davvero. Lo stesso dev, in azienda, fa tre task in sprint e ne commenta uno in retrospettiva. Non è diventato scemo al lavoro: è che il typing del codice, fuori, era l'unico collo di bottiglia che aveva. Dentro, ne ha dieci, tutti umani.

Il boost dei freelance in arrivo

C'è una conseguenza di questa asimmetria che sta già iniziando a vedersi, ed è un ritorno di spinta del lavoro freelance. Chi lavora da solo, con buoni strumenti AI, oggi può competere su velocity con team di 4-5 persone dentro aziende mediamente organizzate. Perché non paga il costo dell'allineamento.

La domanda naturale è: "Ma se si ammala, chi continua?" Qui arriva il twist che chiude il cerchio con Forza 5: se hai specifiche scritte come contratti — piani versionati, criteri di accettazione eseguibili, decisioni architetturali documentate — il lavoro fatto dal freelance smette di essere irrecuperabile. Un altro freelance (o un team) può prenderlo in mano e continuare, perché la fonte di verità non è nella sua testa. È nel repository.

Il freelance ben attrezzato del 2026 non è quello che corre di più. È quello che ha capito che la sua velocity diventa valore solo se è coperta da specs che la sopravvivono. È il template che molti team aziendali dovranno adottare — e finché non lo fanno, la velocity continuerà a uscire dal perimetro aziendale.

Un dato della Berkeley Haas, citato da Scientific American, rinforza il quadro: dopo l'adozione AI i dipendenti in azienda prendono più task, lavorano più ore, a ritmo più alto, ma la stabilità di delivery peggiora (più rollback, più patch post-release). Più attività, meno valore aggregato.

Forza 5: le aziende non cambiano i processi (e intanto è far west)

È il dato più brutale, ed è ovunque.

McKinsey State of AI 2025-2026:

88% delle organizzazioni ha deployato AI in qualche parte dell'operatività
Altrettante non riportano impatto significativo sul bottom line
Quasi 2/3 non ha scalato l'AI oltre i pilot
Solo l'1% dei C-suite US descrive i propri rollout come "maturi"

La regola di investimento che McKinsey raccomanda è "per ogni dollaro speso in tecnologia AI, investire 5 dollari in persone". La 10-20-70 del BCG dice la stessa cosa: le aziende che allocano il 70% delle risorse di implementazione AI a persone e processi — e solo il 30% a tech e algoritmi — battono consistentemente chi tratta l'AI come un progetto IT.

Quasi nessuno lo fa.

La posizione media oggi è questa: "L'AI sta succedendo, quindi la facciamo usare. Ma sprint planning, code review, QA, definizione di 'done', raccolta requisiti, politica su tech debt, compensation — tutto resta com'era."

Il risultato è quello che Harness nel suo report 2025 chiama AI velocity paradox: i gain upstream evaporano quando review, QA e release pipeline non si adattano al nuovo ritmo. Come infilare una pompa d'acqua nuova in un tubo vecchio — la pompa spinge di più, il tubo resta quello.

Il far west del non-automatizzato

Guardato da vicino, il problema è persino più serio di "non abbiamo aggiornato i processi". Abbiamo un'AI che scrive codice 10x più velocemente, e tutto il resto del ciclo è fermo al manuale:

Il verify non è automatizzato. La review del codice generato la fa un umano, a mano. Non esistono ancora, nei team medi, agenti dedicati che leggono le PR altrui, confrontano contro una spec, fanno property-based testing mirato, eseguono mutation testing. Lo scrive Osmani: "What used to be a quality gate is now a throughput problem."
La raccolta requisiti non è automatizzata. È ancora tutto parlato umano, screenshot su Slack, stringhe in un ticket Jira, una call di 45 minuti che finisce con "dai, ci siamo capiti". Poi il dev traduce quella nebbia in codice — e adesso lo fa con l'AI, ma il nebbia a monte è la stessa.
Il QA non è automatizzato oltre la unit test suite. Gli end-to-end sono fragili, i test di regressione visuale fanno schifo, i test di load si fanno due volte l'anno.
La definition of done non è versionata. È un accordo implicito tra persone che cambia a ogni nuovo PM.

Dove va davvero il vantaggio: specs-as-contract

Se il primo draft di codice è gratis, il valore si sposta a monte — sulle specifiche. Oggi sono ancora linguaggio umano: documenti, ticket, conversazioni con ambiguità, contraddizioni, aggiornamenti silenziosi. Prima dell'AI ci passavamo sopra perché il tempo di scrittura del codice copriva le incongruenze, le chiarivamo iterando. Adesso il codice esce in mezz'ora, e ti ritrovi con un software che fa quello che il ticket sembrava dire — non quello che serviva.

La transizione probabile è verso specifiche come contratti: documenti eseguibili, versionati, verificabili. Test comportamentali scritti prima del codice. Proprietà formali dove servono. Schemi machine-readable dei processi di business invece di user stories in prosa. Framework come TLA+, o approcci più recenti tipo spec-driven development con contratti eseguibili, vanno in questa direzione — e il piano che abbiamo visto in Forza 2, trattato come artefatto versionato, è un primo passo naturale.

Il limite matematico: la legge di Amdahl

Anche se togliessimo tutte le cinque forze umane, resterebbe un soffitto matematico che vale la pena ricordare.

La legge di Amdahl, applicata al ciclo di sviluppo: se la scrittura del codice rappresenta il 25-35% del tempo totale di un SDLC — requirements, design, review, testing, deploy, debugging, coordinamento sono l'altro 65-75% — anche azzerando completamente il tempo di scrittura, il guadagno massimo è 25-35% sul totale.

I ~10% di system-level gain che vediamo oggi sono consistenti con: un'AI che riduce del 50-60% il tempo della fase coding, in aziende che non hanno ancora ristrutturato il resto. Il margine per andare al 20-25% esiste — ma non lo prendi pompando più token. Lo prendi rifacendo i processi a valle.

I click mentali (e perché le aziende non li fanno)

Un punto personale, perché credo conti.

Per quello che sto vivendo io adesso, l'effetto dell'AI non è "lavoro meno e sto più rilassato". È l'opposto: voglio fare molto di più, e la lentezza di alcune parti del sistema — aziendali, umane, organizzative — mi sembra quasi fastidiosa. È un'energia in più che cerca un canale per uscire.

Parlando con chi sta capendo davvero questa rivoluzione, emerge sempre la stessa forma di racconto: n step, n click mentali. Ognuno è uno sblocco discontinuo — non un miglioramento incrementale, ma un momento in cui "ho capito una cosa che prima non vedevo" — e ciascuno apre la porta a comportamenti completamente diversi.

Alcuni click che ho visto ricorrere, in ordine non rigoroso:

Il click della fiducia. Il momento in cui smetti di verificare ogni riga e inizi a delegare davvero. Per molti è arrivato solo con Opus 4.5 o 4.6 — prima era un tool utile ma non un partner. C'è chi lo sta vivendo adesso, chi l'ha avuto prima, chi non l'ha ancora fatto.
Il click dell'orchestrazione. Quando passi da "un agente che mi aiuta" a "più agenti in parallelo su pezzi diversi che poi riconcilio". Cambia proprio il modello mentale di cosa è il lavoro.
Il click delle spec. Quando ti accorgi che scrivere meglio quello che vuoi vale più che scrivere prompt più furbi. Spesso arriva dopo qualche mese di uso intenso.
Il click del burnout. Perché l'AI che ti sblocca al lavoro ti sblocca anche nei progetti personali, e a un certo punto ti ritrovi a fare tre cose in parallelo e a dormire peggio. Chi gestisce già questo è avanti di un altro step — chi non ci è ancora arrivato lo scoprirà.

E qui arriva il punto aggregato: le aziende non fanno click. Non hanno un "momento in cui hanno capito". Hanno procurement, budget, pilot, steering committee. Il click è un'esperienza che accade al singolo dev dentro una sessione intensa di lavoro reale, non dentro una PowerPoint trimestrale. Le aziende incorporano l'AI come incorporano un nuovo software gestionale, mentre il grosso del valore arriva solo se accompagni le persone lungo i loro click.

La conseguenza operativa è la metafora dell'atleta col doping. "Ho Claude Code, non serve che mi alleni." Non funziona. L'AI moltiplica quello che sai già fare con l'AI — se non ti alleni, moltiplica poco. E i click non arrivano in ufficio, tra uno sprint e una call con il PM: arrivano quando ci metti le ore fuori dal perimetro del lavoro.

Due implicazioni:

Per chi usa l'AI: il pomeriggio in cui non studi e non sperimenti, qualcun altro lo sta facendo. Quel qualcuno, tra due anni, avrà sbloccato un paio di click in più dei tuoi.
Per chi gestisce un team: se la tua azienda non alloca tempo esplicito per sperimentazione (tempo vero, con progetti reali non critici, con permesso di fallire), stai lasciando che i tuoi migliori si allenino a spese proprie. Alcuni lo faranno, altri no, e la dispersione interna crescerà fino a essere ingestibile.

Cosa significa, in pratica

Tre letture operative.

Se sei un dev (qualsiasi livello): il tuo guadagno di velocity reale è probabilmente maggiore di quello che mostri, perché dichiararlo in pieno non paga — anzi, con il competence penalty del 9%, punisce. La cosa sana è non inflare le stime e usare il margine per la qualità: review approfondite, refactoring, comprensione, specs migliori. Non è un consiglio moralista: è il comportamento che a parità di incentivo dà il massimo ritorno sulla tua carriera.

Se sei un manager tecnico: il bottleneck non è generare più PR. È smaltirle, capirle, testarle — e a monte, capire cosa va costruito. Se vuoi davvero alzare il soffitto, il tempo del tuo team più bravo va investito in review, architettura e soprattutto specifiche scritte bene, non in throughput. Le metriche che premi devono riflettere questo, altrimenti hai un Claudeonomics mascherato (ne ho scritto ieri).

Se sei un founder o CTO: se non hai ridisegnato sprint, review, definition of done e raccolta requisiti per l'era AI, il tuo 10% è già ottimistico. Il 70% dell'investimento va in persone e processo — McKinsey, BCG, Gartner dicono tutti la stessa cosa. E dentro quel 70%, la parte più sottovalutata è automatizzare il verify e versionare le specifiche. Chi ci arriva per primo costruisce un vantaggio competitivo che non è più un discorso di qualche percentuale di velocity — è strutturale.

In chiusura

Il paradosso non è che l'AI non funzioni — funziona benissimo nel suo perimetro. Il paradosso è che l'abbiamo infilata dentro sistemi sociali, economici e organizzativi che remano contro la sua velocità reale: incentivi sbagliati, review senza AI, team non allineati, aziende ferme sui processi di dieci anni fa, specifiche che restano un discorso da call di 45 minuti.

Il soffitto del 10% non lo sbloccano i modelli più grandi. Lo sbloccano l'automazione dei pezzi non-coding del ciclo e la trasformazione delle specifiche da prosa umana a contratti eseguibili. È la prossima ondata — meno sexy dei keynote sui modelli, ma è lì che si sposterà il vantaggio competitivo dei prossimi tre anni.

Fonti: