Misura ciò che resta scarso

C’è un dashboard, da qualche parte dentro Meta, che quest’estate raccontava una storia magnifica. Le modifiche al codice delle piattaforme e dell’infrastruttura AI: più 220% anno su anno. L’adozione degli strumenti di coding assistito: in crescita ovunque. Il costo marginale di produrre software: in caduta libera. Qualunque comitato di direzione, davanti a quei numeri, avrebbe brindato alla trasformazione AI-native.

Poi c’è il secondo numero, quello che Reuters ha tirato fuori il 26 agosto insieme al resto dell’inchiesta: le feature e i miglioramenti effettivamente arrivati agli utenti crescevano del 36%. E un terzo: incidenti tecnici e di sicurezza gravi, più 40%. E un quarto: il tempo che i dipendenti passavano a risolverli, più 70%.

Il contesto merita due righe, perché è quasi troppo perfetto. Il piano si chiamava Project OT, Organization Transformation, ed era nato a gennaio nel ritiro della leadership alle Hawaii: un’azienda «AI native», team ridotti in alcuni scenari fino al 60%, popolazioni di virtual worker sorvegliate da piccoli gruppi di umani ad alta densità di talento. Meta ha licenziato il 10% dei dipendenti a maggio, poi ha cancellato la seconda ondata prevista per novembre. Interpellata, l’azienda ha descritto i tagli più aggressivi come scenari allo studio, non decisioni prese. E su un punto ha ragione: non conosciamo le definizioni interne di quelle metriche, né il perimetro esatto, né il peso delle variabili organizzative. Il rapporto fra 220 e 36 non è una misura scientifica della produttività dell’AI, e sarebbe disonesto usarlo così.

Ma non è il numero a rendere il caso interessante. È la forma. Da una parte un indicatore di produzione che esplode; dall’altra un indicatore di risultato che si muove appena, mentre il carico operativo cresce. Non è detto che l’AI abbia fallito. Potrebbe aver fallito la nostra idea di produttività.

Goodhart non l’ha inventato l’AI

Prima di attribuire all’AI un problema nato con il management, concediamo tutto quello che c’è da concedere. Le righe di codice sono una pessima misura della qualità di un programmatore da decenni. Il numero di ticket chiusi si gonfia dividendo il lavoro in ticket più piccoli. La velocity di Scrum cresce ricalibrando gli story point. La test coverage sale con test che non troverebbero mai una regressione. Gli incidenti diminuiscono smettendo di registrarli. Charles Goodhart lo scrisse nel 1975, con l’understatement di un banchiere centrale: qualunque regolarità statistica osservata tende a rompersi appena la si mette sotto pressione per scopi di controllo. La versione che tutti citano, «quando una misura diventa un obiettivo, smette di essere una buona misura», è in realtà di Marilyn Strathern, che vent’anni dopo commentava la valutazione delle università britanniche. Il problema delle metriche proxy è vecchio quasi quanto l’idea stessa di misurare il lavoro.

L’AI non inventa Goodhart. Cambia la scala. Finché ottimizzare la proxy richiedeva lavoro umano, il gaming aveva un costo, e quel costo era un limite naturale: potevi spezzettare i ticket, ma dovevi comunque chiuderli tu. Ora un sistema produce quantità quasi arbitrarie di ciò che la metrica conta, a costo quasi nullo. La macchina non ha bisogno di falsificare la misura. Le basta rendere economico ciò che la misura conta. A quel punto l’indicatore può continuare a crescere mentre ciò che volevamo migliorare resta fermo, o peggiora.

La scarsità era l’informazione

Conviene distinguere due fenomeni che si assomigliano solo in superficie. Nel gaming tradizionale una persona manipola intenzionalmente un indicatore: mi valutano sui ticket chiusi, quindi creo ticket più piccoli. È un comportamento opportunistico, e l’organizzazione può correggerlo con cultura, incentivi, controlli.

Con l’AI succede qualcosa di diverso, e succede senza alcuna intenzione. Un developer adotta un coding agent. L’agente produce più commit, più test, più refactoring, più documentazione, più pull request. Il developer non sta imbrogliando: il sistema produce davvero di più. Il problema è che la scarsità che rendeva la quantità informativa è scomparsa. Nessuno misura la produttività di un manager dal numero di email inviate, perché inviare un’email costa zero. La pull request sta assumendo, progressivamente, la stessa natura. Non è una crisi di manipolazione: è una crisi di commoditizzazione dell’output misurabile.

La metafora giusta viene dall’economia monetaria. Quando la quantità di moneta si moltiplica senza che i beni aumentino, ogni unità contiene meno informazione sul valore. Con gli artefatti aziendali sta accadendo qualcosa di analogo: più codice, più report, più analisi, più slide, più alternative, più finding. Un report di cinquanta pagine generato in trenta secondi non rappresenta lo stesso investimento epistemico di un report che richiedeva una settimana di ricerca. Non significa che sia peggiore. Significa che la lunghezza non dice più quasi nulla sulla quantità di conoscenza che contiene. Vale per i report, e vale riga per riga per il codice.

Ogni metrica è una teoria

Qui sta il passaggio che mi sembra più utile per capire cosa si sta rompendo davvero. Quando misuriamo qualcosa non stiamo semplicemente osservando: stiamo facendo un’ipotesi sul mondo. Le righe di codice contengono l’ipotesi che più codice sia almeno grossolanamente associato a più lavoro software. Le PR mergiate contengono l’ipotesi che più modifiche integrate rappresentino più valore elaborato. La velocity contiene l’ipotesi che il volume di story point completati rappresenti avanzamento. Il lead time contiene l’ipotesi che accorciare il tempo fra inizio e delivery sia in generale un bene.

La metrica funziona finché la relazione causale sottostante resta abbastanza stabile. L’AI non rompe il numero: rompe la teoria che lo giustificava. Se genero una feature in cinque minuti ma la review richiede il doppio, il lead time della fase di coding migliora e il ciclo complessivo no. Se genero cento test inutili, la coverage sale senza che salga la capacità di trovare regressioni. Se produco cinque alternative di implementazione, il «lavoro prodotto» cresce, e cresce anche il lavoro necessario per sceglierne una. Il numero è ancora lì, preciso come prima. È la freccia causale sotto il numero che non c’è più.

Il lavoro non scompare, cambia stato

La narrativa della produttività AI guarda quasi sempre al punto in cui il lavoro viene eliminato, e quasi mai misura con la stessa cura il lavoro che viene creato più avanti nella catena. Un agente genera in cinque minuti il codice che richiedeva due ore: risparmio nominale, 115 minuti. Poi il developer impiega venti minuti a capire che cosa è stato scritto; il reviewer ne impiega dieci in più perché il diff è tre volte più grande; emerge una regressione; si fanno due iterazioni; la documentazione va riallineata; qualcuno deve accorgersi della scelta architetturale implicita infilata al paragrafo tre. Il task costa comunque meno di prima. Ma non 115 minuti di meno. Il guadagno vero è il tempo eliminato meno il nuovo costo di verifica, meno il nuovo costo di integrazione, meno il rischio introdotto. La prima componente si misura con un cronometro. Le altre, in molte organizzazioni, non le misura nessuno.

Non è una mia impressione: è ciò che DORA sta documentando da due anni. Il report 2024 registrava che l’adozione dell’AI aumentava la produttività percepita dagli individui mentre peggiorava throughput e stabilità del delivery, con una stima diventata famosa: ogni 25% di adozione in più si associava a un calo dell’1,5% del throughput e del 7,2% della stabilità. Il report 2025, con l’adozione ormai al 90% degli sviluppatori, descrive l’AI come un amplificatore: accelera la generazione iniziale, ma una parte del tempo risparmiato viene reinvestita in auditing e verifica, e l’adozione più alta si associa insieme a throughput maggiore e a maggiore instabilità. Potremmo chiamarla verification tax. L’AI abbassa il costo della produzione, quindi produciamo di più; ogni output non deterministico va controllato, quindi cresce un’economia del controllo. Più il costo di generazione scende, più la quota del costo totale che ricade sulla verifica sale. Al limite teorico, con il costo di generazione a zero, il valore del processo sta quasi interamente in specifica, selezione, verifica e integrazione. Per un settore che ha passato mezzo secolo a misurare la produzione, è un ribaltamento completo.

L’analogia più onesta è una fabbrica. Se raddoppio la velocità della prima macchina della linea senza toccare le stazioni successive, non raddoppio la produzione: creo una coda. Nel software la coda è meno visibile, e appare come PR in attesa, decisioni architetturali sospese, test instabili, merge conflict, rework, incidenti. La lean production ha un nome esatto per il materiale che una fase produce e la successiva non riesce ad assorbire: inventario. E l’inventario non è un asset, è un costo. Va letto, aggiornato, testato, mantenuto, e alla fine spesso cancellato. L’output agentico che il sistema non riesce ad assorbire non è produttività. È inventario.

Il collo di bottiglia diventa visibile

Fin qui la lettura pessimistica. C’è però un rovescio, ed è quasi una buona notizia: la crisi delle metriche ci costringe a scoprire che cosa produceva valore davvero. Se scrivere codice diventa economico e la delivery non accelera in proporzione, significa che scrivere codice non era il collo di bottiglia che credevamo. Forse lo erano capire il problema, ottenere una decisione dal cliente, ridurre l’ambiguità dei requisiti, rivedere, integrare, validare, fare deploy, costruire fiducia. L’AI funziona come una macchina per far emergere la vera funzione produttiva dell’organizzazione: elimina un costo e mostra che cosa resta.

E ciò che resta, prima di tutto, è l’attenzione. Un essere umano può leggere una quantità limitata di codice, di PR, di alert, di documenti. Gli agenti non condividono questo limite, o non allo stesso livello. Quando il ritmo dell’output della macchina supera il ritmo dell’attenzione umana qualificata, l’organizzazione deve scegliere: accumulare coda, abbassare la profondità della review, automatizzare anche la review, ridurre l’output, o aggiungere selettivamente persone. La scelta più pericolosa è la terza, se viene fatta senza controlli indipendenti, perché produce un sistema in cui macchine generano, macchine approvano e l’essere umano legge una sintesi. Se un coding agent produce cento PR e un review agent ne approva novantacinque, il numero di PR approvate dice ancora meno di prima. Bisogna misurare quanto il reviewer trova davvero, quanto sono correlati i failure mode di generatore e revisore, quanti problemi arrivano comunque in produzione. La regressione è potenzialmente infinita, chi controlla il controllore, e la risposta non può essere un’altra metrica quantitativa: servono gate deterministici, eval indipendenti e outcome reali. È lo stesso argomento che ho fatto sul giudizio proprietario: il vantaggio non sta nel motore che genera, sta nei criteri con cui decidi se ciò che genera merita fiducia.

Il contatore dell’adozione

Gli strumenti, nel frattempo, moltiplicano ciò che si può contare. GitHub ha portato in disponibilità generale a febbraio la dashboard delle metriche Copilot, a giugno ha aggiunto ai report i crediti AI consumati, a luglio le metriche per repository, con le PR create e mergiate dal coding agent e le review fatte dall’agente di review, e una dashboard di impatto che classifica gli utenti in coorti di adozione, code-first, agent-first, multi-agent, ciascuna con la media di PR mergiate per utente e le righe di codice al giorno. Sono dati utilissimi per capire come viene usato lo strumento, e non ho nessuna ironia da fare su chi li costruisce. Diventano pericolosi nel momento in cui qualcuno li confonde con la domanda «quanto valore sta creando lo strumento». I token consumati non sono produttività. Le righe generate non sono produttività. Gli utenti attivi non sono produttività. Le PR create da un agente non sono produttività. Sono telemetria dell’adozione, e l’adozione è la premessa del valore, non il valore.

Che la confusione sia già in corso lo dice il fatto che DORA, a giugno, ha dovuto dare un nome alla degenerazione: tokenmaxxing, aziende che tengono classifiche interne dei dipendenti che consumano più token AI e li premiano per questo. Come spinta a far sperimentare i più riluttanti può perfino funzionare; come indicatore di performance è la parodia di tutto quello che questo saggio prova a dire, anche perché la stessa ricerca DORA registra che circa il 30% degli sviluppatori si fida poco o per niente dell’output dei modelli. La scena è quasi perfetta nella sua assurdità: abbiamo reso economica l’intelligenza, e adesso premiamo le persone perché ne consumano di più.

Il passo successivo lo riconosce chiunque abbia visto un’organizzazione da vicino. Il management osserva che l’AI ha aumentato la capacità del 40% e aggiorna i target: più 40% di ticket, di story point, di feature. Il team usa l’AI per raggiungere il nuovo target, il nuovo throughput diventa la baseline, arriva un modello migliore, si ricomincia. Il guadagno tecnologico non viene convertito in meno debito, migliore qualità, più discovery, più resilienza: viene catturato interamente dalla metrica. È un tapis roulant organizzativo, e ha una variante individuale ancora peggiore. Se valuto le persone su codice prodotto, ticket chiusi, PR aperte, task agentici completati, sto premiando esattamente ciò che la macchina produce quasi gratis, e sto penalizzando i comportamenti economicamente più razionali: fare meno modifiche, scrivere una specifica migliore, rifiutare il task, semplificare il sistema. I KPI individuali rischiano di selezionare con precisione il comportamento sbagliato.

C’è un parallelo che rende la trasformazione più leggibile. Ho scritto tempo fa che l’AI sta uccidendo il time & materials perché il tempo smette di essere una proxy accettabile del valore consegnato. Il timesheet e la productivity score muoiono per lo stesso identico motivo. Il timesheet assume che tempo equivalga a valore; la metrica di throughput assume che output equivalga a valore. L’AI rompe entrambe le equivalenze nello stesso momento, perché è la stessa equivalenza: il lavoro non vale più quanto tempo richiede, e il risultato non vale più quanto output contiene.

Misurare l’assorbimento

Se questo saggio deve lasciare una proposta operativa, è questa: spostare la misura dalla produzione all’assorbimento. Le domande vanno tenute separate, perché mescolarle è esattamente l’errore. Il sistema viene usato? È adozione. Che cosa produce? È attività. Quanta parte di ciò che produce l’organizzazione riesce a integrare davvero? È assorbimento. Quanto velocemente il lavoro attraversa il processo? È flusso. Produce l’effetto che volevamo? È outcome. E a quale costo complessivo, con quale debito residuo? È sostenibilità. Un’azienda che osserva 90% di adozione, più 80% di codice generato e più 50% di pull request e conclude «l’AI sta funzionando» ha risposto alle prime due domande e creduto di rispondere alle ultime quattro.

L’unità di misura verso cui tendere è il costo per outcome accettato. Non costo per token, non costo per riga, non tempo per generazione: il compute, il tempo umano di specifica e review, il rework, la quota di incidenti e rollback attribuibile alla modifica, divisi per i risultati che hanno superato review, test, delivery e un periodo di osservazione. È molto più difficile da misurare, ed è precisamente per questo che conta: la difficoltà della misura è quasi sempre proporzionale alla sua rilevanza.

Con un’avvertenza: «accettato» non può ridursi a «mergiato», altrimenti abbiamo solo costruito una proxy più comoda un gradino più in là. Una PR mergiata può essere sbagliata, una feature rilasciata può non essere usata mai, un refactoring può non cambiare niente, un documento può non toccare nessuna decisione. L’outcome dipende dal tipo di lavoro: per una feature è adozione e riduzione del carico di supporto, per un bug è la ricorrenza eliminata, per la security è il rischio materialmente ridotto, per un refactoring sono il costo di delivery e il tasso di incidenti nei mesi successivi.

Tre rapporti mi sembrano abbastanza semplici da sopravvivere a una riunione di direzione. L’Output Absorption Ratio: gli artefatti AI accettati e portati fino al risultato, divisi per gli artefatti AI prodotti. Se la generazione cresce del 300% e l’OAR crolla, non hai accelerato l’azienda: hai trasformato l’AI in un generatore di lavoro downstream. Il Verification Load Ratio: il tempo umano di verifica e rework sul tempo umano totale del workflow. Non va necessariamente minimizzato, in un settore ad alta criticità un carico di verifica alto è perfettamente razionale; serve a vedere se il risparmio ottenuto nella generazione è stato davvero guadagnato o solo trasferito altrove. E l’Autonomous Acceptance Rate: i task agentici accettati senza intervento sostanziale sui task completati, da leggere sempre insieme a defect escape e rollback, perché un 95% di accettazione con molte regressioni è pessimo e un 40% con altissima affidabilità può essere eccellente.

Nessuno dei tre deve diventare il nuovo KPI universale, e chi ha letto fin qui sa perché: diventerebbe il prossimo bersaglio di Goodhart. Il punto è costruire metriche in tensione, mai un numero solo da massimizzare. Che è poi la lezione metodologica più importante di DORA: le cinque metriche di delivery misurano insieme throughput e instabilità, includono dal 2024 il rework rate dei deployment, valgono per un servizio alla volta e non vanno trasformate in obiettivi individuali. Ogni metrica che premia quantità va accoppiata alla metrica che ne rappresenta il costo: generazione con rework, frequenza di deployment con instabilità, autonomia degli agenti con escalation umane, finding di sicurezza con finding validati. La tensione è ciò che impedisce alla proxy di diventare docilmente il target.

Elogio della produttività negativa

C’è una categoria di lavoro che non produce quasi nessun artefatto contabile: dire no a una feature inutile, semplificare una richiesta, scoprire la contraddizione nei requisiti, convincere il cliente a non costruire una cosa, fermare un progetto sbagliato, rifiutare un output plausibile ma falso, cancellare codice. In una cultura che misura la produzione, queste attività sono invisibili. Quando produrre diventa quasi gratuito, diventano la parte più preziosa del lavoro. L’agente propone cinque microservizi e l’architetto risponde uno. L’agente genera duecento test e l’ingegnere ne tiene trenta significativi. Il product owner elimina tre feature su quattro prima che esistano. Il valore del professionista diventa sottrattivo, e il senior di maggior valore potrebbe essere quello che permette al team di generare meno. Come lo misuri? Come conti la feature che non hai costruito e che ti avrebbe fatto perdere sei mesi? Servirebbe una contabilità controfattuale, debito evitato, incidenti evitati, manutenzione futura eliminata. Attribuire numeri precisi è quasi impossibile. Cambiare la direzione dello sguardo no.

C’è anche una ragione più sottile per cui l’abbondanza fa male, e riguarda la frizione. Di solito pensiamo che ridurre frizione sia sempre un bene, ma alcune frizioni svolgevano una funzione: scrivere una specifica costringe a pensare, preparare un report costringe a selezionare, una riunione costosa a volte, semplicemente, non viene convocata. Se una cosa richiedeva tre giorni, almeno qualcuno si chiedeva se valesse la pena. Quando richiede trenta secondi, quella domanda scompare insieme al costo. L’AI elimina il costo dell’atto e, con esso, una parte del filtro che decideva se l’atto meritasse di essere compiuto: era una frizione epistemica, non solo un attrito. Per questo credo che alcune organizzazioni dovranno reintrodurre frizioni deliberate, budget di task agentici, limiti sulla dimensione delle PR, quality gate, approvazioni: non perché la macchina produca male, ma proprio perché produce troppo bene a costo troppo basso. Sono decisioni di quella che chiamerei productivity governance: quale quota della capacità guadagnata convertiamo in più output e quale in migliore qualità, quanta produzione agentica il sistema può assorbire senza generare coda, quali output meritano di entrare nel sistema. L’AI non può prenderle al posto nostro, perché riguardano esattamente ciò che l’organizzazione considera valore.

Da qui anche la domanda giusta per un CEO. Non «quanto è aumentata la produttività grazie all’AI?», ma: quale vincolo del nostro sistema è stato rimosso, e quale vincolo è diventato dominante adesso? Se prima una feature richiedeva tre giorni e ora tre ore, benissimo: che cosa richiede più tempo adesso? La review, la decisione del cliente, il testing, la compliance, il deploy? Quello è il nuovo posto su cui lavorare. Altrimenti l’organizzazione finisce per riversare più materiale sullo stesso collo di bottiglia, e chiamare produttività la dimensione della coda.

Lo stesso film, in altri reparti

Il software è solo il caso più visibile. La compliance ha esattamente lo stesso problema: l’AI genera centinaia di policy, migliaia di controlli documentati, mapping normativi completi, report impeccabilmente formattati. Numero di policy, di controlli, di assessment: tutto può esplodere senza che la conformità reale aumenti di un millimetro. Ho scritto che il punteggio non è la conformità, e la crisi delle metriche AI-native è la stessa transizione vista da un altro reparto: da compliance output a compliance outcome, non documentazione prodotta ma capacità dimostrabile, quanti controlli funzionano davvero e quali evidenze lo provano.

La cybersecurity, uguale. L’AI trova più vulnerabilità, ottimo. Poi i maintainer devono deduplicarle, validarle, stabilirne la severità, correggerle, testare la patch, distribuirla. Se i finding crescono del 1.000% e le vulnerabilità corrette del 20%, non abbiamo migliorato la security: abbiamo allungato la coda. La produttività della macchina può diventare carico dell’istituzione.

E fuori dal software vale in generale. Se produrre articoli, immagini e report costa quasi zero, allora numero di pubblicazioni, volume, frequenza e lunghezza smettono di essere indicatori di capacità culturale, e il valore migra verso selezione, credibilità, originalità, fiducia. La crisi delle metriche AI-native è il caso particolare di una regola che vale ovunque: quando l’AI rende abbondante un output, le metriche costruite sulla scarsità di quell’output smettono di significare.

Misura ciò che resta scarso

La storia dell’informatica ha già visto questo film una volta. Le imprese investirono in computer per anni prima che la produttività comparisse nelle statistiche aggregate; Robert Solow lo fissò nel 1987 nella battuta più citata dell’economia dell’innovazione, l’era dei computer si vede ovunque tranne che nelle statistiche della produttività. La ragione non era che i computer fossero inutili: era che processi, organizzazioni e competenze erano ancora disegnati per il ritmo precedente, e ci vollero anni per riprogettarli. L’AI può produrre una versione accelerata dello stesso equivoco, con un’aggravante: stavolta gli strumenti generano da soli l’evidenza della propria adozione. Compriamo strumenti, misuriamo utilizzo, vediamo l’output esplodere, dichiariamo la produttività esplosa. Poi scopriamo che review, approvazioni, responsabilità e architettura erano rimaste tarate sul vecchio ritmo, e che il sistema non riesce ad assorbire ciò che la macchina produce.

Per gran parte della storia industriale abbiamo misurato il lavoro contando ciò che era costoso produrre: pezzi, ore, documenti, righe, ticket, transazioni. Finché qualcosa richiedeva tempo umano, la quantità prodotta conteneva almeno una traccia del costo necessario a produrla, e quindi un’informazione. L’AI rompe questa equivalenza, silenziosamente, un artefatto alla volta. Può produrre codice senza fatica, test senza fatica, analisi senza fatica, e può continuare a farlo anche quando nessuno è più in grado di leggere ciò che produce. La nostra prima reazione, comprensibile, è misurare quell’abbondanza e chiamarla produttività. È anche il modo più rapido per costruire organizzazioni che sembrano accelerare mentre accumulano materiale che qualcun altro dovrà verificare, integrare, mantenere o cancellare.

Prima dell’AI erano scarsi il tempo di scrittura, il tempo di coding, la capacità di produrre analisi e alternative. Le metriche misuravano quello, e avevano ragione: si misura il collo di bottiglia, non l’abbondanza. Adesso diventano scarsi l’attenzione, il giudizio, la fiducia, la stabilità, la capacità di decidere e quella di assumersi la responsabilità di un risultato. Le metriche devono trasferirsi dove si è trasferita la scarsità. Non misurare ciò che la macchina ha reso abbondante: misura ciò che continua a limitare il sistema.

La prima crisi dell’AI-native, se arriverà, non avrà l’aspetto di un collasso tecnologico. Avrà l’aspetto di un dashboard pieno di numeri eccellenti. Le macchine raggiungeranno gli obiettivi che abbiamo dato loro, le persone raggiungeranno i KPI che abbiamo costruito intorno alle macchine, e solo dopo ci accorgeremo che quegli indicatori descrivevano una scarsità che non esiste più. A quel punto toccherà fare la cosa che le metriche ci hanno permesso di rimandare per un secolo: decidere che cosa consideriamo valore. Forse è questa la conseguenza più profonda dell’AI sul lavoro. Non renderci più produttivi. Costringerci a capire, finalmente, di che cosa volevamo essere produttivi.

L'autore

Andrea MargiovanniAI

Seguo il rapporto fra AI e regolazione europea come fatto politico, non come spettacolo tecnico. Lavoro con team che devono renderla compatibile con AI Act, CRA, NIS2 senza ridurre la compliance a una checklist.

Vai al percorso →