Perché l’IA fallisce nella software delivery agile: esempi e soluzioni per Engineering Manager

Molti CTO si aspettano molto dall’uso dell’IA nella delivery software agile: più velocità, più automazione, più output. Spesso questo è vero nel breve termine. Eppure molti team e CTO non riescono a dimostrare come questa accelerazione locale si traduca in beneficio per il cliente e in valore aggiunto per il business.

Il problema è che, nell’entusiasmo per l’IA, le aziende ottimizzano le cose sbagliate: più token invece di più valore per il cliente, più codice invece di più fiducia, più agenti invece di sistemi di delivery migliori.

Questo articolo si collega volutamente ai nostri altri due contributi:

• IA nella sviluppo software agile: stato degli studi 2026 .
• Guida per CTO e Engineering Manager allo sviluppo software assistito dall’IA .

Qui si tratta del ponte tra le due cose: perché l’IA fallisce nella pratica nella delivery software agile? Gli esempi mostreranno in modo concreto cosa possono fare i manager e quali soluzioni reggono davvero.

Perché l’IA nella software delivery agile ottimizza così spesso verso il bersaglio sbagliato

Non appena l’IA viene introdotta come leva di produttività, in molte aziende accade qualcosa di molto prevedibile: ciò che è misurabile diventa l’obiettivo. Questo si riflette nel nuovo trend Tokenmaxxing. Pragmatic Engineer sul trend Tokenmaxxing

Con questo si intende che aziende o team considerano implicitamente o esplicitamente un alto consumo di token come segno di un buon uso dell’IA. Dal punto di vista economico e organizzativo, questo è pericoloso. Perché i token sono al massimo una misura di input, ma non una misura di valore.

Il modello è antico. Un tempo le “Lines of Code” venivano sopravvalutate come metrica; oggi lo stesso vale per il consumo di token o per le dashboard sull’uso dell’IA. In entrambi i casi vale una variante della legge di Goodhart: quando una metrica diventa un obiettivo, perde il suo valore come metrica. Martin Fowler sulle Lines of Code come problema di metrica, Wikipedia sulla legge di Goodhart

Per l’IA nella delivery software agile significa questo: chi massimizza l’attività nel breve periodo ottiene spesso più attività di IA. Ma non automaticamente una migliore delivery software agile.

Lo stato degli studi a riguardo è poco incoraggiante: a livello individuale si vedono già effetti di produttività significativi, mentre a livello di team e di organizzazione si osservano miglioramenti molto meno solidi. I dettagli li abbiamo riassunti qui: Stato degli studi 2026 sull’IA nello sviluppo software agile

Quattro esempi tipici di come l’IA fallisce nella delivery software agile

Il primo fallimento è banale: i team producono molte più modifiche, ma comprendono davvero una quota sempre più piccola di esse.

Per i manager, all’inizio spesso sembra una buona cosa:

• più pull request
• prime implementazioni più veloci
• più story “fatte”

Il conto arriva più tardi:

• le review diventano più superficiali
• la ownership si diluisce
• l’analisi degli incident richiede più tempo
• si evitano i refactoring, perché nessuno è più sicuro di cosa possa rompersi e dove

Kent Beck descrive nel suo articolo “Trust Factory” che pratiche come test, review, refactoring e delivery incrementale costruiscono soprattutto fiducia. Proprio questa fiducia viene meno quando l’IA produce più rapidamente di quanto il team possa comprendere, verificare e assumersi la responsabilità di. Kent Beck in Trust Factory sulla fiducia nell’ingegneria

Addy Osmani descrive un rischio simile come Comprehension Debt: quando i team rilasciano sempre più codice che non riescono più a comprendere attivamente, a ogni modifica cresce la distanza tra sistema e comprensione. Addy Osmani su Comprehension Debt

Questo coincide anche con risultati più ampi emersi dalla pratica: secondo un sondaggio Sonar riassunto nel 2026, la maggior parte degli sviluppatori non si fida completamente della correttezza funzionale del codice generato dall’IA, e una quota significativa considera persino la sua revisione più dispendiosa che controllare modifiche scritte da persone. Il problema quindi non è solo la scarsa qualità, ma anche il lavoro aggiuntivo di verifica e comprensione. ITPro sul sondaggio Sonar sulla Verification Debt

Il secondo fallimento è ancora più costoso per i leader: l’IA riduce il costo della produzione, ma non automaticamente il costo dell’errore.

Se i team hanno requisiti tagliati male, insufficientemente validati o coordinati solo internamente, l’IA accelera semplicemente il lavoro sbagliato. Kelsey Hightower lo riassume in modo molto diretto nel suo post su LinkedIn: “Productivity doesn’t matter if you’re working on the wrong thing.” Post LinkedIn di Kelsey Hightower sulla produttività sbagliata

Proprio in questa direzione argomenta anche Andrew Ng in una conversazione molto citata del 2025: l’IA ha accelerato molto il coding, ma così facendo si sposta il vero collo di bottiglia. Non è più l’esecuzione il problema principale, bensì la questione del prodotto:

Che cosa dovremmo costruire, in fondo, e con quale rapidità impariamo dal vero feedback degli utenti?

Fonte: Conversazione di Business Insider con Andrew Ng sul collo di bottiglia del product management

Ecco perché, nell’agile software delivery, l’IA può avere successo solo con una reale vicinanza al cliente. Se il percorso dal prompt al codice diventa più veloce, ma quello dal codice al feedback del cliente resta lento, aumentano soltanto l’output e il volume delle modifiche.

Anche la ricerca sul lavoro di prodotto agile mostra esattamente questo schema a un altro livello: in un industry case study sugli Agile Epics, i ricercatori descrivono come requisiti definiti male portino a churn, ritardi, problemi di qualità e costi inutili. L’IA non può eliminare magicamente questi colli di bottiglia. Può al massimo materializzarli più rapidamente. Studio ArXiv su Agile Epics e qualità dei requisiti

Per questo il contrappeso decisivo a un uso cieco dell’IA non è meno IA, ma una migliore agile delivery. Chi cerca le leve trasversali per ottenerla le trova qui: Guida al futuro dello sviluppo software agile supportato dall’IA

Molti scenari futuri dell’IA nella software delivery agile appaiono attraenti perché rendono la responsabilità elegantemente invisibile: un agente analizza il feedback degli utenti, il successivo scrive i requisiti, il successivo implementa, il successivo testa e il successivo fa il deploy.

Tecnicamente molto di questo è fattibile. Organizzativamente diventa rapidamente sfumato.

Soprattutto nello sviluppo software agentico, la vecchia domanda di management va posta con ancora più forza: chi decide? Chi verifica? Chi si assume le conseguenze? IBM formula il problema di base in una panoramica molto utile sull’AI decision-making: la responsabilità resta umana, soprattutto quando i sistemi preparano o accelerano decisioni. IBM sulla responsabilità nell’AI decision-making

Anche l’AI Agile Manifesto pone qui il giusto contrappunto: più intelligenza artificiale senza giudizio umano non è progresso, ma una strada sbagliata. AI Agile Manifesto in originale

Per questo non basta parlare solo delle capacità degli strumenti. Non appena gli agenti interpretano requisiti, eseguono modifiche o addirittura innescano azioni vicine alla produzione, la responsabilità deve diventare organizzativamente più chiara e più visibile.

Il quarto fallimento diventa spesso visibile solo con ritardo: singoli sviluppatori o team appaiono estremamente produttivi, mentre l’organizzazione nel suo complesso diventa più lenta.

Questo accade quando ciascuno ottimizza localmente con l’IA, ma quasi nessuno rafforza il sistema complessivo:

• I principi architetturali vengono applicati in modo incoerente
• gli stessi problemi vengono risolti più volte in parallelo
• i sistemi di review e test vengono aggirati
• le pipeline di delivery diventano un collo di bottiglia
• crescono il carico degli incident e il lavoro di rework

Birgitta Böckeler descrive nel suo colloquio con InfoQ su Harness Engineering perché una maggiore autonomia comporti sempre anche maggiori rischi e debba essere limitata tramite adeguati meccanismi di feedforward e feedback. Podcast InfoQ con Birgitta Böckeler su Harness Engineering

Che questo non sia un rischio teorico lo dimostrano diversi casi diventati pubblici. Secondo quanto riportato, nel 2026 Amazon ha inasprito le proprie guardrail interne dopo gravi serie di incidenti, in cui sono stati citati come fattore concausale anche sistemi agentici o vicini all’IA. La lezione che se ne è tratta era significativa: più modifiche documentate, più approvazioni, più “controlled friction” nei sistemi critici. In altre parole: non ogni accelerazione locale migliora il sistema complessivo. A volte rende solo più visibili, più in fretta, le sue vulnerabilità. Rapporto di Business Insider sulle guardrail IA rafforzate di Amazon

Una seconda, diversa forma della stessa entropia si vede con il cosiddetto Vibe Coding assistito dall’IA. Axios ha riportato nel 2026, citando ricercatori di sicurezza, centinaia di migliaia di artefatti pubblicamente accessibili, tra cui migliaia con dati aziendali sensibili. Qui non fallisce in primo luogo un singolo prompt, ma il sistema complessivo di standard, accessi, default, comprensione della sicurezza e governance. Rapporto di Axios su Vibe Coding e artefatti pubblicamente accessibili

In breve: più autonoma è l’IA, più importante è il quadro organizzativo e tecnico in cui opera.

Perché la produttività a breve termine e il tokenmaxxing sono la strategia IA sbagliata

Alcuni leader reagiscono alla nuova leva dell’IA con una conclusione semplice: allora dobbiamo solo imporre il più velocemente possibile il massimo utilizzo dell’IA.

Questa è esattamente la reazione manageriale sbagliata.

Perché?

Perché in questo contesto “short term productivity” di solito significa solo quanto segue:

• più codice generato
• più sessioni di AI
• maggiore consumo di token
• più attività risolte localmente

Ma tutto questo dice ancora ben poco sulle domande che per l’AI nella agile software delivery sono davvero decisive:

• È stato risolto il problema giusto?
• Il team capisce la modifica?
• La modifica può essere rilasciata in modo sicuro?
• Dopo la modifica, il sistema è migliore o più fragile?
• L’organizzazione impara più velocemente o solo in modo più frenetico?

Proprio per questo il Tokenmaxxing è un segnale d’allarme così buono. Mostra cosa succede quando le aziende trattano l’uso dell’IA come un fine a sé stesso. Allora i dipendenti massimizzano esattamente ciò che viene ricompensato in modo visibile, anche se così aumentano costi, entropia e navigazione alla cieca. Pragmatic Engineer sulla tendenza Tokenmaxxing

Jez Humble ha descritto in modo molto chiaro questo problema di management già molto prima dell’attuale ondata di IA: quando i manager si concentrano direttamente sulla produttività, spesso non si fanno proprio i miglioramenti a lungo termine. Per l’IA nella software delivery agile questo vale in modo ancora più marcato. Jez Humble su focus sulla produttività e mancati miglioramenti a lungo termine

Ciò che funziona invece: quattro soluzioni robuste per l’IA nella software delivery agile

1. Mantenere esplicitamente la responsabilità in capo all’essere umano

L’AI può accelerare, suggerire e alleggerire il lavoro. Ma non deve diventare una scusa per far sfumare la responsabilità decisionale e qualitativa.

In pratica significa:

• chiari owner per architettura, security e decisioni rilevanti per il prodotto
• nessuna metrica di successo che premi soltanto l’attività dell’AI
• regole esplicite di review e approvazione per le modifiche generate dall’AI

2. Costruire un engineering harness invece di limitarsi agli strumenti di AI

Molti team investono prima nei modelli e solo dopo nelle condizioni in cui quei modelli possono lavorare in sicurezza. Proprio questo va invertito.

Per un harness affidabile per l’AI nella agile software delivery servono ad esempio:

• buone specifiche
• piccoli pacchetti di lavoro verificabili
• test automatici
• analisi statica
• sandbox controllate
• chiari contesti architetturali
• feedback rapido da CI, delivery e produzione

Se questo ragionamento ti interessa, anche OpenSpec e il GitHub Spec Kit sono riferimenti utili sul tema del lavoro supportato da specifiche con l’IA: OpenSpec per lo sviluppo di prodotto basato su specifiche, GitHub Spec Kit per lo sviluppo guidato dalle specifiche

3. Rendere il feedback dei clienti più veloce della produzione di codice

L’AI è una leva di delivery sostenibile solo se vengono accelerati anche i cicli di apprendimento. Altrimenti si produce solo più velocemente lontano dalla realtà.

In concreto significa:

• release più piccole
• più esperimenti con vere anse di feedback con i clienti
• analisi più coerente dei dati di utilizzo delle funzionalità
• analisi più rapida dei segnali di supporto e degli utenti

Chi aumenta solo la velocità di coding, ma non la velocità e la qualità del feedback, non costruisce un’organizzazione AI-native, ma solo una “feature factory” più veloce, come la descrive John Cutler. Vedi: 12 segnali che stai lavorando in una Feature Factory

4. Prendere sul serio retrospettive e cicli di apprendimento

Quando l’AI nella agile software delivery fallisce, le cause sono spesso sistemiche. Allora serve a poco ottimizzare solo singoli prompt o strumenti.

I team hanno bisogno di routine in cui rendono visibili i pattern ricorrenti e li risolvono in modo sistematico:

• Dove perdiamo comprensione?
• Dove si accumula il collo di bottiglia delle review?
• Dove l’AI genera più lavoro di rifinitura che valore?
• Dove ottimizziamo la velocità locale a scapito dell’intero sistema?

Proprio per questo le retrospettive restano rilevanti. Non come rituale del passato Scrum, ma come meccanismo di apprendimento organizzativo in un ambiente con una maggiore frequenza di cambiamento.

Conclusione: l’AI nella agile software delivery raramente fallisce per una mancanza di AI

La vera ironia è: molte organizzazioni non falliscono con l’AI perché siano troppo prudenti, ma perché governano con una visione troppo corta.

Confondono la produttività a breve termine con la creazione di valore sostenibile e il miglioramento del sistema di delivery. Confondono il consumo di token con la creazione di valore. Confondono la generazione autonoma di codice con la maturità organizzativa.

La domanda guida migliore non è quindi: “Come facciamo in modo che i nostri team usino ancora più AI?”

Piuttosto:

• A quali condizioni l’AI migliora davvero la nostra delivery?
• Dove l’IA sta creando proprio ora nuovi colli di bottiglia nella catena del valore?
• Dove l’IA sta mettendo in luce carenze sistemiche che dobbiamo correggere?
• Quali capacità organizzative dobbiamo rafforzare affinché l’accelerazione non si trasformi in entropia?

Se per questo vuoi prima l’evidenza più sobria, continua a leggere qui: situazione degli studi sull’IA nello sviluppo software agile .

Se cerchi direttamente leve di management, vai avanti qui: Guida per CTO e Engineering Manager sull’IA nello sviluppo software agile .

FAQ sull’IA nella software delivery agile

Perché l’IA produce più output per il mio team, ma non una delivery migliore?

Perché più output non significa automaticamente delivery migliore. Se review, test e feedback non tengono il passo, aumenta soprattutto la complessità.

Che cosa significa Tokenmaxxing nello sviluppo software assistito dall’IA?

Tokenmaxxing significa fare dell’uso dell’IA o del consumo di token un obiettivo. Misura l’attività, ma non il valore.

Cosa dovrebbero fare gli Engineering Manager, invece di spingere solo sulla produttività con l’IA?

Dovrebbero rafforzare responsabilità, test, review e anse di feedback. Solo questo rende l’IA utile nel lungo periodo.

I team fortemente supportati dall’IA hanno ancora bisogno di rituali agile?

Sì, ma con un focus diverso. Meno cura dello status, più feedback, apprendimento e miglioramento continuo.

Come faccio, come Engineering Manager, a misurare se l'IA nello sviluppo software porta davvero valore?

Misura il Lead Time, il carico di lavoro di review, il tasso di errori e il beneficio per il cliente. Il puro output non basta.

Perché il mio team diventa più veloce con l'IA, ma i risultati non migliorano?

Perché più codice non produce automaticamente risultati migliori. Senza review, test e feedback puliti, aumenta solo l’entropia.

Quali KPI dovrei davvero monitorare per l'IA nello sviluppo software?

Monitora il tempo di attraversamento, il tasso di difetti, il rework, la sicurezza del deployment e il tempo fino al feedback del cliente. I soli token dicono troppo poco.

Come evito che il codice generato dall'IA rallenti il mio team in seguito?

Mantieni le modifiche piccole, testale accuratamente e pretendi una review chiara. L’IA può portare velocità, ma non sostituire la comprensione.