Il collo di bottiglia dell’IA: perché un codice più veloce non porta prodotti più veloci
Questo articolo è stato scritto con il supporto dell’IA e revisionato dal team agenthouse. Le illustrazioni sono generate dall’IA.
L’IA ha reso la scrittura del codice software più economica e molto più veloce. Molti team si aspettavano che le funzionalità arrivassero ai clienti alla stessa velocità. La maggior parte scopre che non è così. Un’idea del 1984 spiega perché.
Ogni processo è veloce solo quanto la sua fase più lenta
Nel 1984 il fisico e studioso di management Eliyahu M. Goldratt pubblicò The Goal (in italiano: L’obiettivo), un romanzo su un direttore di stabilimento che cerca di salvare una fabbrica in crisi. Il libro introdusse la teoria dei vincoli. L’idea di fondo è semplice: ogni fase di un processo ha il proprio throughput, e il sistema nel suo insieme non può mai produrre più della sua fase più lenta, il vincolo. Accelerare qualsiasi altra fase non serve. Si accumulano soltanto scorte davanti al collo di bottiglia.
Goldratt applicò l’idea dapprima ai reparti produttivi. In seguito la estese al project management, e libri come The Phoenix Project la portarono nell’IT e nello sviluppo software.
Il ritmo che fa avanzare il lavoro
I processi seguono un ritmo. Il Lean manufacturing lo chiama takt, dalla parola tedesca per «battuta»: il passo con cui il lavoro deve passare da una fase alla successiva. Goldratt descrisse la stessa cosa come un tamburo, battuto dal vincolo, che detta il passo a tutti gli altri.
Spesso il segnale è appena percettibile. Pensate al campanello nella cucina di un ristorante che avvisa il cameriere che un piatto è pronto da servire, o al fischio che autorizza la partenza di un treno. Quando ogni fase lavora allo stesso ritmo, il processo è in armonia.
Lo sviluppo software lo è raramente. Che sia a cascata o agile, i flussi perfettamente bilanciati sono l’eccezione: i requisiti si bloccano, le revisioni si accumulano, i rilasci aspettano i test.
Cosa cambia con l’IA: una fase è diventata molto più veloce
L’IA generativa ha accelerato esattamente una fase della catena: la scrittura del codice. Ciò che prima richiedeva giorni ora richiede ore, a volte minuti. Questo mette sotto pressione il processo da due lati.
A monte, la domanda «che cosa dobbiamo costruire?» diventa un vuoto. Quando l’implementazione non è più il fattore limitante, la qualità dell’input conta molto di più. Business development e product management devono comprendere le reali esigenze dei clienti più rapidamente e con maggiore precisione di prima. Altrimenti il team costruisce in modo efficiente funzionalità che nessuno vuole e nessuno paga. Un codice veloce non rende migliore una cattiva idea. La porta solo prima sul mercato.
A valle, si forma un nuovo collo di bottiglia. Gli sviluppatori che revisionano il codice generato dall’IA, i test manager, gli architetti e gli ingegneri DevOps si trovano improvvisamente a valutare molto più materiale. La fase di scrittura del codice è cresciuta di un ordine di grandezza. Le fasi di revisione, test e operations no.
Il risultato è quello che Goldratt avrebbe previsto: il lavoro in corso si accumula davanti al nuovo vincolo. La velocità percepita nel generare codice non si traduce in rilasci di funzionalità più rapidi. Questo vale soprattutto per le aziende che tengono ancora a un software manutenibile e funzionante, e fanno bene.
La soluzione: armonizzare l’intera catena, non una sola fase
Rendere una fase ancora più veloce non risolve il problema. Ciò che aiuta è supportare ogni fase con la stessa struttura agentica, così che a ciascuna si applichino aspettative chiare, dalla prima ipotesi di mercato fino alle note di rilascio. Chiamiamo questa struttura un harness di agentic engineering.
Validazione del mercato. Gli agenti aiutano i team a verificare le ipotesi, raccogliere evidenze e raggiungere il product-market fit prima di qualsiasi passaggio di consegne. Il risultato sono artefatti strutturati, non idee sparse.
Product management. Il product management trasforma questi artefatti in user story significative. Con lo stesso framework, ogni story ha il perimetro giusto, è testabile e soddisfa una chiara Definition of Ready (DoR) prima che inizi lo sviluppo.
Sviluppo e test. Il Test-Driven Development (TDD) viene pianificato direttamente sulla user story, insieme alle regole di governance del team. La qualità nasce alla fonte invece di essere scoperta in revisione.
Revisione e operations. I revisori non partono più da zero. Verificano un lavoro già realizzato secondo criteri concordati. È come avere l’ispettore della revisione auto che lavora accanto al meccanico, invece di aspettare in fondo alla linea.
Documentazione e go-to-market. La documentazione assistita dall’IA viene prodotta come parte del lavoro. Il product marketing e i team di supporto ricevono materiale accurato allo stesso ritmo con cui cambia il prodotto.
Quando ogni fase lavora allo stesso ritmo, la velocità guadagnata con la programmazione basata sull’IA arriva finalmente al cliente.
Tutta la storia in 18 secondi
Aprite l’animazione in una pagina dedicata (18 secondi, senza audio)
Per iniziare
Ogni parte di questo harness è disponibile nel framework open source di agentic engineering di agenthouse: ruoli, skill e processi di prodotto riutilizzabili, dalla validazione del mercato alla delivery, al supporto e all’apprendimento.