L'IA non ha reso l'ingegneria più economica. Ha solo spostato il conto a valle.
Ogni pitch per uno strumento di IA-coding ti vende sempre la stessa cosa: velocità. Scrivi la feature in minuti, non in giorni. Rilascia di più con meno persone. Le demo sono vere — la prima bozza arriva davvero in pochi secondi.
Poi il trimestre si chiude, e il conto spunta da una parte in cui non stavi guardando.
Un nuovo studio di Entelligence — un vendor, e ci torno tra poco — ha messo un numero su dove spunta. Su oltre un milione di pull request provenienti da 2.444 organizzazioni di ingegneria, hanno tracciato dove finisce davvero lo sforzo ingegneristico assistito dall'IA. Il dato in copertina: per ogni dollaro che un team spende in IA-coding, circa 18 centesimi diventano prodotto rilasciato. Gli altri 82 vengono consumati prima che una singola feature arrivi a un utente — spesi per correggere, rifare e revisionare ciò che gli strumenti hanno generato.
Quel numero non lo leggo dalla sedia dell'investitore, né da quella del vendor. Lo leggo da quella che occupo da vent'anni: la persona che deve difendere una voce di costo IA davanti a un CFO e tenere in piedi il turno di reperibilità che intercetta quello che gli strumenti hanno rilasciato. E da quella sedia, gli 82 centesimi non sono uno spreco. Sono la parte del lavoro che non si è automatizzata — ed è l'argomento più forte che abbia visto quest'anno sul perché l'ingegnere sia la parte che non puoi trasformare in merce.
L'IA ha reso economica esattamente una cosa: la prima bozza
Togli il marketing a un assistente di IA-coding e quello che ti vende è una prima bozza più veloce. Genera codice plausibile a partire dal contesto locale — il file in cui sei, la funzione qui sopra, gli schemi che ha visto un milione di volte. È un valore reale, e oggi è davvero economico.
Quello che non può fare è sapere quale di quegli schemi è già fallito nella tua produzione il mese scorso. Scrive a partire dal repository, mai dalla realtà: quale edge case hai provato e poi annullato, quale retry «ovvio» ha buttato giù il servizio di pagamenti a marzo, perché quel null check che tutti continuano a cancellare in realtà regge l'intero impianto. Il modello è il motore, e il motore è diventato economico — ho argomentato a lungo perché un motore economico non sia un'auto economica. Generare codice è sempre stata la parte facile. Rendere il codice generato vero in produzione è la parte difficile, e una prima bozza più veloce non la rende per niente più facile.
Gli 82 centesimi sono la parte che solo i tuoi ingegneri sanno fare
Guarda come lo studio scompone il dollaro, e l'idea di «spreco» si sgretola. Di quegli 82 centesimi: circa 44 vanno al lavoro reattivo — correggere bug e tenere in piedi i sistemi — 27 a rifare codice che non è sopravvissuto all'impatto con la realtà, e 11 alla revisione. Ognuna di queste è una decisione di giudizio a valle della generazione. Ognuna è il lavoro di decidere se la cosa plausibile che il modello ha scritto sia la cosa corretta da rilasciare.
Quel dollaro non è svanito. Si è spostato — dallo scrivere il codice al verificarlo, integrarlo e gestirlo in esercizio. È sempre la stessa mossa su cui continuo a insistere: il valore sale lungo lo stack, dallo strato che il modello può consegnarti a quello che non può. Più la generazione diventa economica, più la tua parte di dollaro si concentra dove serve un essere umano che ha già rilasciato in produzione. Chiamala la quota di lavoro reattivo — e nell'organizzazione mediana di questo dataset è il 44% di tutta la capacità ingegneristica, prima ancora di contare la coda lunga dove supera i tre quarti.
I revert crescono più in fretta del lavoro che li produce
Ecco il numero che dovrebbe preoccupare un CTO più degli 82 centesimi. Su dodici settimane, lo studio ha tracciato il volume settimanale di pull request salire 2,6× — e le PR annullate (revert) salire 3,7×. Il fallimento si accumula più in fretta dell'output. Non stai solo rilasciando di più; stai rilasciando di più che dev'essere poi ritirato.
Il meccanismo non è un mistero, e non è che gli ingegneri siano peggiorati. È che lo strato di revisione non è mai cresciuto insieme al volume. Quando moltiplichi 2,6× l'input di un processo di verifica senza far crescere la verifica, il tasso di errori che sfuggono sale per definizione. Lo stesso report lo dice chiaro: quasi metà delle PR viene approvata in meno di un'ora, la maggior parte dei commenti di revisione è rumore generato dai bot, e solo circa un quinto dei commenti viene mai preso in carico. Una riga su quattro scritta ogni settimana viene scartata nella stessa settimana. Puoi generare codice alla velocità della macchina. Non puoi revisionarlo alla velocità della macchina e continuare a chiamarla revisione — e il divario tra queste due velocità è esattamente da dove vengono i revert.
Questo è il numero di un vendor — ed ecco perché mi fido lo stesso della forma
Ora la parte che quasi tutti i resoconti hanno saltato. Entelligence vende la cura. Il loro prodotto chiude «l'anello tra il codice e la produzione» — che è, guarda caso, esattamente la cosa che il report conclude ti manchi. Quando chi vende un numero trae profitto dal tuo allarme, scontalo. Sempre.
Altri due caveat che il report è abbastanza onesto da dichiarare, e a cui devi aggrapparti. Non c'è nessuna baseline pre-IA — questa è una differenza di tasso su dodici settimane, non un prima-e-dopo, quindi «l'IA ha reso i team più lenti» è una lettura plausibile dei dati, non una dimostrata. E «82 centesimi di ogni dollaro IA» è un modello di dove va lo sforzo di ingegneria spinto dall'IA; non è l'82% dei soldi della tua azienda dati alle fiamme. Il report include perfino le cifre che giocano contro il suo stesso allarme: 18 centesimi arrivano davvero agli utenti, e quel tasso di approvazione sotto l'ora può essere il segno di un team sano e ben attrezzato tanto quanto di uno negligente.
Quindi non mi fido del numero perché un vendor mi ha disegnato un grafico. Mi fido della forma — generazione economica, verifica costosa, fallimento che si accumula — perché combacia con ciò che vedo accadere in produzione ogni mese. (Ho scritto a parte su come quella stessa forma sia stata piegata in qualcosa che non dice lungo la strada verso un titolo di Yahoo; l'inquadratura è una lezione a sé.)
Questo film l'abbiamo già visto — è la bolletta del cloud, uno strato più su
Se ti suona familiare, è giusto così. Quando il cloud ha reso economico il calcolo, la spesa non è scesa — si è spostata, ed è cresciuta, e ci abbiamo messo un decennio a inventare il FinOps per governare ciò che avevamo reso facile da consumare. L'IA-coding è quella stessa mossa uno strato più su nello stack: ha reso economico generare codice, e il costo si è spostato sul verificarlo e gestirlo in esercizio. I token sono la nuova voce di spesa, e — come ho già sostenuto — sono un costo da governare, non una produttività da festeggiare. L'ingegnere resta il moltiplicatore. È solo il conto ad aver cambiato indirizzo.
Cosa farei questo trimestre se fossi il tuo CTO
Una diagnosi senza azione è solo un'opinione. Cinque scommesse concrete:
- Misura il change-failure-rate, non il volume. Gli strumenti ottimizzano per il numero di PR; l'azienda paga per quante vengono annullate. Metti metriche di esito in stile DORA sulla dashboard che la tua leadership legge davvero, e osserva il tasso di fallimento insieme alla velocità, non al suo posto.
- Tratta le PR scritte dall'IA come una classe di difetti a sé. Etichettale. Confronta il loro tasso di revert e la vita media dei bug con le modifiche scritte da umani. Non puoi gestire un rischio che ti rifiuti di separare dalla media.
- Finanzia l'impalcatura, non solo il generatore. Gli 82 centesimi sono revisione, verifica e feedback dalla produzione. Spendi lì. Nel concreto: chiudi il tuo anello — rimetti ciò che è davvero fallito ed è stato annullato dentro il contesto da cui i tuoi strumenti generano, così la prossima bozza nasce dalla realtà e non dal repo.
- Conta gli ingegneri verso l'alto, non verso il basso. I team che tagliano organico perché «adesso il codice lo scrive l'IA» stanno licenziando le uniche persone che rendono il codice vero. Chi taglia più a fondo oggi passerà il 2027 a riassumere — il lavoro reattivo non sparisce quando spariscono i revisori, arriva solo prima ai tuoi utenti.
- Governalo come il cloud. Attribuzione dei token per workflow, un kill-switch su ogni agente, e uno strato di routing che manda i task banali al modello più economico che basta. Il costo fuori controllo in un'organizzazione IA raramente è un ingegnere chiacchierone; è un agente bloccato in un retry loop.
La linea che traccio
L'IA ha reso gratuita la prima bozza. Non ha reso gratuita la versione rilasciata, vera, che sopravvive — l'ha resa più preziosa, e ce n'è più da costruire di quanta ce ne sia mai stata. I 18 centesimi che arrivano ai tuoi utenti sono la parte facile. Gli 82 che non ci arrivano sono dove l'ingegneria vive davvero, e far finta che uno strumento abbia eliminato quel lavoro è il modo in cui finisci l'anno a spiegare un tasso di revert al tuo board.
Il modello è diventato economico. Il giudizio no. Se la tua strategia IA confonde queste due cose, non hai un team più veloce. Hai una pulizia più grande da fare.
Vedi il tuo tasso di revert salire più in fretta della velocità da quando hai introdotto gli strumenti IA? Parla con un CTO — ti aiutiamo a costruire lo strato di revisione e verifica che trasforma una prima bozza più veloce in qualcosa che puoi davvero rilasciare.
