L'AI sopra il workflow attuale non funziona. Né per il senior, né per l'azienda

C'è un senior che conosco che usa Claude come "Google più veloce". Apre la chat, fa una domanda, copia la risposta, torna a lavorare esattamente come prima. È bravo, il suo flusso funziona da quindici anni, e l'AI ci è atterrata sopra come un widget in più nella barra degli strumenti. Gli ho chiesto cosa fosse cambiato nel suo modo di lavorare. Mi ha risposto: "Niente, faccio le stesse cose, solo che cerco le cose più in fretta".

A scala più grande succede la stessa identica cosa. Un'azienda firma duecento licenze AI per il team di sviluppo. Stesso processo di approvazione, stessi handoff tra team, stessi ruoli, stesso modo di fare le review. La direzione aspetta il salto di produttività che ha letto nei keynote. Passano sei mesi e il salto non arriva. La conclusione che circola nei corridoi è "l'AI è sopravvalutata".

Non è sopravvalutata. È che l'hanno incollata sopra un flusso che non è cambiato di un millimetro. Lo stesso errore, a due scale diverse. E non è la prima volta che l'industria lo commette — è almeno la terza, e ci sono i numeri per dimostrarlo.

Il senior che usa l'AI all'1%

Partiamo dal singolo, perché è la versione più facile da vedere allo specchio.

Usare l'AI come autocomplete potenziato o come motore di ricerca più rapido non è sbagliato. Funziona, fa risparmiare qualche minuto, è meglio di niente. Ma è la frazione più piccola di quello che lo strumento può fare. Nei rilevamenti di Faros AI, basati su telemetria reale e non su sondaggi, la maggioranza degli sviluppatori usa solo l'autocomplete: le capacità avanzate restano in larga parte inutilizzate. È il flusso di sempre con un assistente incollato sopra.

Il salto vero è un altro, e cambia la natura del lavoro. Non "l'AI mi suggerisce la prossima riga", ma "delego all'AI un task intero e io faccio il direttore d'orchestra". Non leggo il codice riga per riga sperando di intercettare il bug, ma costruisco un meccanismo di verifica che lo intercetta al posto mio. Non un agente alla volta in modalità lineare, ma più agenti in parallelo, ognuno isolato nel suo spazio.

Di questo piano individuale ho già scritto in dettaglio in Il paradosso della velocity AI: il singolo dev accelera, ma si ferma a una frazione del potenziale per ragioni che sono in parte di incentivi, in parte di abitudine. Qui mi interessa il passo successivo, perché lo stesso meccanismo che blocca il senior blocca anche l'azienda intera — solo che a livello aziendale costa molto di più.

L'azienda che compra le licenze e aspetta il salto

Quando porti questo all'organizzazione, i numeri diventano impietosi.

Il dato che spiazza arriva ancora da Faros AI, nella versione 2026 del loro report sul paradosso della produttività: 22.000 sviluppatori, 4.000 team, telemetria reale. I team ad alta adozione AI completano il 21% di task in più e mergiano il 98% di pull request in più. Sembra il sogno. Poi guardi il resto.

Metrica (team ad alta adozione AI)	Variazione
Task completati	+21%
Pull request mergiate	+98%
Tempo di review delle PR	+91%
Dimensione media delle PR	+154%
Bug per sviluppatore	+9%

Il singolo dev produce di più e più in fretta. Ma le PR diventano più grosse del 154%, quindi più difficili da rivedere; il tempo di review cresce del 91%; i bug salgono del 9%. Il collo di bottiglia non è sparito: si è spostato. Prima era la scrittura del codice, ora è l'approvazione umana di una mole di codice molto più grande. La frase del report è chirurgica: "any correlation between AI adoption and key performance metrics evaporates at the company level" — qualsiasi correlazione tra adozione AI e metriche di performance evapora a livello aziendale.

Evapora. Il singolo va più veloce, l'azienda sta ferma. Perché tutto quello che è cambiato è la velocità a monte, mentre il processo a valle — review, handoff, QA, gate di approvazione — è rimasto identico a prima. È la legge di Amdahl applicata all'organizzazione: un sistema va veloce quanto il suo anello più lento, e se acceleri solo l'anello che già non era il problema, il sistema nel complesso non si muove.

Non è un caso isolato di un singolo report. Il MIT, nel suo "The GenAI Divide: State of AI in Business 2025", ha analizzato 300 deployment pubblici e intervistato decine di executive, arrivando a una cifra diventata famosa: il 95% dei pilot GenAI aziendali non produce impatto misurabile sul P&L. Su una spesa enterprise stimata tra i 30 e i 40 miliardi di dollari. E la causa principale, scrivono, non è il modello — i modelli funzionano — ma la cattiva integrazione e le priorità disallineate. Gli strumenti generici "non imparano e non si adattano ai workflow" aziendali, e nessuno ha cambiato i workflow per andargli incontro.

I dati sul ROI 2026 chiudono il cerchio. Solo il 29% delle aziende riporta un ritorno significativo dalla GenAI; il 48% definisce l'adozione "una grande delusione". E la spiegazione è la frase che dovremmo incorniciare: "roughly 80% of the work required to move from pilot to production is data engineering, governance, workflow integration, and measurement infrastructure". Circa l'80% del lavoro per passare dal pilot alla produzione è integrazione e processo, non modello. Detto altrimenti: il grosso del ROI viene dal ridisegno del workflow, non da quale modello hai scelto.

Comprare la licenza è la parte facile e veloce. È anche la parte che non produce il valore.

Non è la prima volta. È almeno la terza

Qui c'è la parte che mi interessa di più, perché toglie all'AI l'aura di novità assoluta e ci ricorda che questa lezione l'abbiamo già imparata e dimenticata due volte.

Nel process management c'è un detto che gira da decenni: se automatizzi un processo disordinato, ottieni un processo disordinato automatizzato. Non è una citazione testuale di nessuno in particolare — viene spesso attribuita a Bill Gates, ma quella è una parafrasi popolare. Il concetto verbatim, da The Road Ahead del 1996, è più sobrio e più preciso: l'automazione applicata a un'operazione efficiente ne amplifica l'efficienza; applicata a un'operazione inefficiente, ne amplifica l'inefficienza. L'AI è automazione, e amplifica. Punto. Se il flusso sotto è buono, l'AI lo rende migliore. Se è cattivo, lo rende più velocemente cattivo, con più rumore.

Sei anni prima, nel 1990, Michael Hammer aveva scritto su Harvard Business Review un pezzo dal titolo che è già la tesi: "Reengineering Work: Don't Automate, Obliterate". Hammer, ex docente di computer science al MIT, aveva osservato che le aziende mettevano l'informatica sopra i processi esistenti e non vedevano ritorni — stavano solo accelerando lavoro che non aggiungeva valore. La sua metafora è perfetta per il 2026:

"It is time to stop paving the cow paths. Instead of embedding outdated processes in silicon and software, we should obliterate them and start over."

Smettere di asfaltare i sentieri delle mucche. I sentieri delle mucche sono i percorsi tortuosi che il bestiame aveva tracciato nel tempo seguendo l'abitudine, non la logica. Asfaltarli significa cementare una via storta solo perché è quella che c'è già. L'AI incollata sul workflow attuale è esattamente questo: un sentiero di mucche asfaltato di fresco, liscio e veloce, che però porta nello stesso posto storto di prima.

Una nota onesta, perché Hammer va citato come metodo e non come modello da copiare: il Business Process Reengineering che ne seguì ebbe fallimenti enormi e si guadagnò la reputazione di scusa per i licenziamenti. Hammer e Champy insistettero che i tagli non fossero il punto, ma il danno reputazionale rimase. Prendo da Hammer l'idea — ridisegnare invece di sovrapporre — non l'esecuzione, che spesso fu disastrosa proprio per eccesso di zelo.

Perché la tecnologia da sola non basta mai

Il fondamento economico di tutto questo lo ha messo Erik Brynjolfsson con il concetto di Productivity J-Curve, nel paper "The Productivity J-Curve: How Intangibles Complement General Purpose Technologies".

L'idea è questa. Le tecnologie a uso generale — l'elettricità, il computer, e oggi l'AI — non producono valore da sole. Lo producono solo se accoppiate a investimenti complementari intangibili: ridisegno dei processi, riqualificazione delle persone, ristrutturazione dell'organizzazione. Questi investimenti costano, richiedono tempo e non si vedono nei bilanci nel modo giusto. Nei primi anni la curva di produttività scende — paghi i costi del ridisegno prima di raccoglierne i frutti — e solo dopo, quando i complementi maturano, risale. Da qui la forma a J: prima giù, poi su.

Curva a J della produttività: prima il ridisegno costa, poi il valore arriva

Il punto centrale per noi è uno solo: comprare lo strumento è la parte facile e immediata. Il ridisegno organizzativo è la parte lenta, costosa, faticosa — ed è quella che genera il valore. Chi compra la licenza e si ferma lì resta inchiodato nella parte discendente della J, vede i costi e non i ritorni, e conclude che lo strumento non funziona. Non è lo strumento. È che il complemento non si compra: si pratica.

Tre nomi, tre decenni, una sola lezione. Hammer nel 1990 (il metodo: ridisegna, non sovrapporre), Gates nel 1996 (il principio: l'automazione amplifica, nel bene e nel male), Brynjolfsson tra il 2018 e il 2021 (la prova economica: serve il complemento organizzativo, e arriva in ritardo). Ogni volta che è arrivata una tecnologia nuova abbastanza grande, l'abbiamo riscoperta da capo. L'AI nel 2026 è l'ennesima riedizione dello stesso copione.

Cosa significa ridisegnare davvero

"Ridisegnare il workflow" suona come una di quelle frasi da slide di consulenza che non vogliono dire niente. Quindi rendiamola concreta, prima lato dev, poi lato azienda.

Per chi scrive codice, l'ecosistema 2026 è già attrezzato per il flusso ridisegnato. Il passaggio è da assistente a orchestratore:

Dalla riga al task. Smetti di chiedere "completa questa funzione" e inizi a delegare unità di lavoro intere a un agente che pianifica, esegue, gestisce i merge conflict e ti riporta indietro un risultato da validare.
Dal seriale al parallelo. Con git worktree ogni agente lavora in una copia isolata dello stesso repository, in una working directory diversa, senza pestare i piedi agli altri. Più agenti girano in parallelo su pezzi indipendenti. Attenzione a non esagerare: spawnare un agente a ogni occasione è un anti-pattern, e ho provato a tracciare il confine in subagents, quando dividere e quando no.
Dalla lettura riga per riga alla verifica strutturata. Se le PR diventano il 154% più grandi, leggerle a mano una per una è esattamente il collo di bottiglia che Faros misura. La risposta non è leggere più in fretta, è cambiare come si verifica: test, controlli automatici, e un agente avversariale che attacca il codice invece di un umano che lo scorre sperando di vedere il bug. È il red teaming dell'AI coding — un workflow ripensato attorno al fatto che ora il codice arriva in quantità diversa da prima.

Per l'azienda, il dato Faros dice anche dove ridisegnare, perché ti indica con precisione dove si è spostato il collo di bottiglia:

La code review. Se la review è diventata il collo di bottiglia (+91%), accelerare ancora a monte non serve a niente. Serve cambiare come si revisiona: review assistita, controlli automatici sui rischi reali, gate mirati invece di lettura integrale.
Gli handoff. La risposta non è fare gli stessi passaggi di mano più in fretta, ma avere meno passaggi di mano. Ogni handoff è una coda, e l'AI riempie le code più velocemente.
La QA. L'AI introduce rischio in punti specifici — secondo Opsera, vendor, il codice AI-generato porta dal 15 al 18% in più di vulnerabilità di sicurezza; Faros misura +9% di bug. Il ridisegno sposta la verifica esattamente lì dove il rischio aumenta.
I ruoli. Se i senior, sempre secondo Opsera, ottengono guadagni di produttività molto superiori ai junior, il ridisegno tocca anche come si formano e si impiegano i junior — non basta "diamo a tutti la stessa licenza" e sperare.

Questo è il senso di "amplifica". L'AI sopra un buon processo di review lo rende migliore. L'AI sopra un processo di review già intasato lo intasa di più. Lo strumento non crea il problema: lo moltiplica. È lo stesso DNA argomentativo di quando ho scritto che l'industria del software era già un disastro prima dell'AI — l'AI non ha portato il disordine, ha solo alzato il volume di quello che c'era già.

La prudenza è razionale, ma ha un prezzo

Ora la parte onesta, perché finora potrebbe sembrare che basti "ridisegnare tutto" e via. Non è così, e chi vende quella semplicità sta vendendo un sogno.

Ridisegnare un processo è difficile, costoso e rischioso. Nel breve il vecchio processo funziona ancora — porta in produzione, paga gli stipendi, tiene in piedi l'azienda. Smontarlo significa accettare un periodo di resa peggiore prima del miglioramento: è letteralmente la parte discendente della J di Brynjolfsson. Chi è prudente e non rompe ciò che funziona ha una logica solida dalla sua parte. Non sta sbagliando per pigrizia.

Ma la prudenza ha un costo opportunità, ed è esattamente nei numeri che abbiamo visto: licenze che restano sotto-utilizzate, velocità che evapora alla review, il 95% dei pilot senza impatto, il 29% di ROI significativo. I soldi non scompaiono perché l'AI non funziona. Scompaiono perché si è comprato lo strumento senza fare il lavoro che lo rende redditizio.

E c'è un punto che tengo a dire chiaro, perché va contro la narrazione del "ridisegna tutto": non tutti i workflow vanno ripensati. Se un processo funziona e l'AI non aggiunge valore in quel punto specifico, lasciarlo stare è la decisione giusta, non la pigra. Il ridisegno è uno strumento mirato, non una crociata. L'"obliterate" di Hammer va dosato — il BPR fallì spesso proprio per averlo applicato come dogma a tutto, anche dove non serviva. La domanda non è "come incollo l'AI ovunque", e nemmeno "come ridisegno tutto". È: in quali punti specifici del mio flusso l'AI sposta davvero un collo di bottiglia reale, e in quali sto solo asfaltando un sentiero di mucche?

È un problema di immaginazione, non di strumento

Torno al senior dell'inizio. Il suo "faccio le stesse cose, solo più in fretta" non è una critica all'AI. È una fotografia precisa del problema: ha cambiato la velocità di un'azione, non ha cambiato il modo di lavorare. E l'azienda con le duecento licenze ha fatto la stessa cosa su scala, comprando uno strumento e lasciando intatto tutto ciò che lo circonda.

Lo strumento è pronto. I modelli del 2026 sono ottimi, gli orchestratori esistono, i worktree funzionano, il red teaming è alla portata di chiunque abbia un pomeriggio. Quello che manca non è la tecnologia. È l'immaginazione di un processo diverso — la capacità di guardare il proprio flusso e chiedersi non "dove infilo l'AI", ma "come lavorerei se questo flusso lo disegnassi oggi, sapendo cosa l'AI sa fare".

È un lavoro che non si compra con una licenza e non si delega a un vendor. Si fa, lentamente, accettando di stare un po' nella parte bassa della J prima di risalire. È scomodo. Ma è l'unico punto dove il valore è davvero stato, ogni volta, negli ultimi trent'anni.

Fonti: