IA: l'illusione della produttività - ll problema dei colli di bottiglia

Nel precedente articolo di questa serie, AI: l'illusione della produttività, abbiamo esplorato il problema del sovraccarico di coordinamento: quando più agenti IA lavorano in parallelo, il lavoro non consiste più nello scrivere software, ma nel gestirlo, arbitrando tra agenti che non convergono e decidendo, ciclo dopo ciclo, di quale output fidarsi. Questa volta guardiamo a ciò che i tre problemi visti finora davano per scontato: che valesse la pena ottimizzare la velocità di scrittura del codice. Nella maggior parte delle organizzazioni, non è mai stato così.

***

La velocità di scrittura del codice raramente è ciò che si frappone davvero tra un'organizzazione e la consegna di software valido. Molto più spesso, il vero collo di bottiglia si trova a monte: sapere cosa costruire, per chi, perché, con quali compromessi, e come dovrebbe funzionare realmente. Altrettanto spesso, si tratta di avere un'architettura abbastanza solida da consentire che le risposte a quelle domande possano essere implementate in modo pulito. Sono problemi di prodotto e di giudizio ingegneristico, non di velocità di battitura del codice. Concentrare  l'IA sulla velocità di coding  (un passaggio che, nella maggior parte dei team, non è mai stato il collo di bottiglia)  non velocizza il sistema ma produce più output contro specifiche mai davvero messe alla prova, sopra architetture mai davvero sottoposte a stress test, e crea una sensazione convincente di progresso mentre il vero vincolo resta intatto, più difficile da vedere di prima.

Questo argomento si appoggia direttamente sulla Teoria dei Vincoli di Eliyahu Goldratt, esposta nel suo romanzo del 1984 The Goal. La tesi centrale afferma che il throughput di un sistema dipende dal suo passaggio più lento, il vero collo di bottiglia. Migliorare qualsiasi altro passaggio non aumenta il throughput complessivo: si limita ad accumulare scorte inutilizzate subito a monte del collo di bottiglia, in attesa che questo le smaltisca. La formulazione ampiamente attribuita a Goldratt lo dice più efficacemente di quanto potrei fare io: "An hour saved at the non-bottleneck is a mirage. (Un'ora risparmiata su un “non-collo-di-bottiglia” è un miraggio."). 

Vorrei estenderla leggermente: ottimizzare la cosa sbagliata va oltre il semplice lasciare invariata la velocità del sistema, arriva a peggiorare attivamente le cose. Generando più output contro una specifica poco chiara e un'architettura poco curata in fase di progettazione, il coding accelerato dall'IA genera la sensazione di progresso mentre il vero vincolo resta intatto. Tempo, attenzione e budget fluiscono verso il passaggio visibilmente occupato, e lontano da quelli che ne avevano davvero bisogno.

Nel software, in particolare, credo che questo si manifesti in due ambiti più di ogni altro. Il primo è la chiarezza di prodotto: cosa stiamo davvero costruendo, per chi e perché.  Nessuna velocità di coding, per quanto elevata, risponde a queste domande che diventano sempre più difficile da porsi una volta che il codice è già in fase di sviluppo, perché una pipeline in rapida evoluzione crea una pressione intrinseca a continuare a seguire il piano piuttosto che fermarsi a verificare se sia ancora quello giusto. Il secondo è l'architettura: chiedersi se il sistema è progettato  bene, con confini  chiari e compromessi onesti, da consentire l’aggiunta di nuovo codice senza che l'intero sistema diventi più difficile da comprendere a ogni commit. Nessuno di questi ambiti  diventa più facile da gestire quando l'IA scrive il codice più in fretta. Al contrario, diventano più difficili, perché il volume di decisioni incorporate in quel codice (decisioni su struttura, su ambito, su cosa una feature debba davvero fare)  aumenta allo stesso ritmo del codice, senza un corrispondente aumento del ragionamento che avrebbe dovuto precedere ciascuna di esse.

Quanto visto finora trova conferma anche nella realtà. Tra il 2025 e il 2026 moltissime aziende hanno scommesso sulla stessa ipotesi: tagliare ruoli puntando sull'IA. Prese insieme, queste scelte hanno dato vita a un esperimento economico su ampia scala, e i risultati meritano di essere presi sul serio perché mettono in ballo somme non piccole. La società di staffing Robert Half ha trovato che circa tre HR manager su dieci negli Stati Uniti (le stime variano dal 29 al 32% a seconda delle rilevazioni) che avevano tagliato un ruolo principalmente a causa dell'IA,avevano già ricoperto di nuovo la stessa posizione o una simile, e Forrester Research ha rilevato che il 55% dei datori di lavoro oggi si pente dei tagli guidati dall'IA.

Due casi specifici rendono concreto questo meccanismo. Ford ha assunto, promosso o richiamato in servizio 350 ingegneri esperti nell'arco di circa tre anni, dopo che sistemi di controllo qualità basati su IA e 900 telecamere di ispezione guidate da IA non erano riusciti a individuare difetti che gli ingegneri più esperti vedevano immediatamente. A giugno 2026, Ford si è piazzata al primo posto nello studio JD Power Initial Quality per la prima volta in sedici anni, e il suo CEO ha attribuito agli ingegneri rientrati centinaia di milioni di dollari di risparmi su garanzie e richiami. La competenza che ha davvero protetto la qualità del prodotto è stata il vero vincolo per tutto il tempo; la velocità di progettazione non ha mai contato davvero.

L'assistente AskHR di IBM automatizza in modo efficiente il 94% delle richieste HR di routine. Il restante 6%,  casi che richiedono giudizio etico, richiede ancora l’intervento  di una persona. La risposta di IBM è stata triplicare le assunzioni entry-level invece di continuare ad apportare modifiche all'IA, esplicitamente per proteggere la pipeline che produce il giudizio che l'IA non riesce a replicare.

Entrambi i casi condividono la stessa forma, ed è la forma su cui vorrei che un team di ingegneria si soffermasse: l'IA in questione non è mai stata a corto di output. Era carente nella capacità di giudicare quale dovesse essere l'output e perché, esattamente il livello che questo  articolo ha sostenuto essere il vero collo di bottiglia anche nella maggior parte del lavoro software, non solo nelle richieste HR o nel controllo  qualità. Naturalmente non ogni  licenziamento attribuito all'IA in questo periodo è stato un vero fallimento di capacità; alcuni erano semplici tagli ai costi che utilizzavano l’IA come comoda giustificazione. Questo non cambia il punto di fondo, ovvero che il divario tra la narrativa sull’IA e la realtà effettiva era abbastanza ampio da assorbire entrambi i tipi di casi.

Nulla di tutto ciò significa che l'IA non abbia alcun valore nello sviluppo software. Si tratta di sostenere che i guadagni di produttività che l'IA può davvero offrire sono oggi indirizzati su una parte del sistema che raramente era, in primo luogo, ciò che limitava l'output,  mentre i due aspetti che davvero lo limitavano, la comprensione del problema e una progettazione adeguata per risolverlo, non diventano più veloci e, semmai, vengono ancora più trascurate, perché un livello di coding che ormai procede abbastanza in fretta crea l’ illusione che la parte difficile sia già stata risolta.

Nessuno dei quattro problemi sopra citati è davvero distinto dagli altri. Si intrecciano in due loop di feedback, uno a livello del singolo sviluppatore e l’altro a livello dell'organizzazione, e ciascuno rinforza silenziosamente l'altro.

A livello individuale: un prompt superficiale (il tema del primo articolo di questa serie) produce un output che viene revisionato con un’attenzione compromessa (come raccontato nel secondo articolo). Quella revisione perde dei dettagli. Ciò che si perde emerge a valle come bug, rilavorazioni, incidenti. La rilavorazione si aggiunge al carico cognitivo che aveva reso superficiale il prompt in primo luogo. Il circolo vizioso si chiude su se stesso  e l’esecuzione simultanea di più agenti (l'argomento del terzo articolo) accelera simultaneamente ogni fase.

A livello organizzativo: il coding accelerato dall'IA sulla base di specifiche poco chiare produce più output non validati. Più output non validati comportano più rilavorazioni e più pivot di prodotto. Rilavorazioni e pivot creano pressione ad andare ancora più veloci. Andare più veloci significa ricorrere di più all'IA. Ricorrere di più all'IA lascia meno spazio  (cognitivamente e in agenda)  alla riflessione a monte (chiarezza dei requisiti, validazione di prodotto, compromessi architetturali onesti) che avrebbe prevenuto la rilavorazione fin dall'inizio.

L'inversione percettiva di METR si colloca esattamente nel punto in cui questi due cicli si incontrano, e credo sia per questo che è l'ancora giusta per l'intero pezzo. La sensazione di produttività sopravvive a entrambi i livelli per la stessa ragione: l'output continua ad apparire visibilmente, sia a livello individuale, sia nella pipeline organizzativa. I cicli tengono tutti impegnati. Essere occupati sembra sinonimo di essere produttivi. Così il debito, a entrambi i livelli, si accumula  in modo invisibile, fino a quando non si traduce in un mancato rispetto delle scadenze, in un problema di qualità o, come ormai mostra un'intera ondata di marce indietro sulle assunzioni,  in un prodotto costruito su una premessa che si è rivelata non reggere.

Non c’è un elenco ben definito di soluzioni in arrivo. Non credo che questo problema si risolva con una tecnica di prompting migliore, un pattern di orchestrazione degli agenti più intelligente, o una nuova dashboard di produttività. Sono tutti strumenti legittimi, ciascuno nel proprio ambito, ma nessuno di essi tocca ciò che credo stia davvero succedendo.

A livello individuale, l'IA premia la chiarezza di pensiero prima del prompt e la profondità di attenzione durante la revisione, entrambe le quali richiedono di trattare la concentrazione come una risorsa realmente limitata. Le pratiche attuali con cui oggi si lavora con questi strumenti (più agenti in esecuzione, iterazione più veloce, output visibile più alto) amplificano le pressioni che consumano la concentrazione necessaria a svolgere bene entrambe le attività.

A livello di interazione, il modello di chat su cui questi strumenti sono costruiti è pensato per l'iterazione continua, mentre i problemi tecnici complessi richiedono davvero una concentrazione sostenuta. Lo stato di flow che gli sviluppatori esperti hanno passato anni a costruire è la precondizione per poter giudicare se ciò che l'IA ha prodotto sia effettivamente buono, ed è proprio per questo che non può essere sospeso per la durata di una sessione con l'IA. .

A livello organizzativo, l'IA premia i team che hanno già svolto il duro lavoro di chiarire i propri processi  a monte,  poiché amplifica qualsiasi cosa le venga data in pasto. Per i team che non hanno fatto quel lavoro, invece, amplifica il rumore, riempie la pipeline con elementi sbagliati più in fretta, e rende il vero vincolo più difficile da trovare, non più facile.

Il che mi porta all'unica domanda che credo valga davvero la pena porsi prima di applicare  l'IA a qualsiasi parte di un workflow, e non è "possiamo andare più veloci qui?" ma la domanda di Goldratt, riformulata per questo momento: "È questo il vincolo?". Per la maggior parte dei team, nella gran parte dei contesti che ho osservato, la risposta sincera è no.

Se il settore sia in grado di porsi quella domanda con sincerità,  visto che gli strumenti sono così convincenti, i benchmark così visibili, la pressione competitiva così intensa,  davvero non lo so. Non credo che lo sappia ancora nessuno. Non ho intenzione di far finta di saperlo chiudendo con una soluzione preconfezionata.

La domanda resta in sospeso. Credo sia giusto che resti così.

***

Questo è il quarto e ultimo articolo della serie AI: l'illusione della produttività. Nei quattro problemi analizzati (la qualità dell'attenzione, lo stato di flusso, il sovraccarico di coordinamento e i colli di bottiglia) si ripete sempre lo stesso schema: l'IA amplifica il pensiero quando può contare su una progettazione chiara e solida, se questa manca, non riesce a colmare il vuoto da sola. La parte difficile resta sempre la stessa: capire cosa costruire e costruirlo su un'architettura abbastanza solida da sostenerlo.

Vi siete persi gli articoli precedenti della serie? Potete recuperarli qui:

• Il problema della qualità dell'attenzione - primo articolo

• Il problema dello stato di flow - secondo articolo

• Il problema del sovraccarico di coordinamento - terzo articolo

***

Abbiamo scritto questo articolo con il supporto dell'AI. Se vuoi saperne di più su come usiamo questi strumenti per la scrittura, ecco la spiegazione.

***

Riferimenti

• Eliyahu M. Goldratt, The Goal: A Process of Ongoing Improvement (North River Press, 1984) - book; the widely-attributed formulation cited in this piece could not be traced to a specific page/edition, see Part IV's editorial notes in the companion outline

• CNBC, Employers who laid off workers citing AI are already starting to regret it (July 2026)

• Forbes, Ford Hiring 350 Engineers After AI Failed Shows Human Value In AI Era (June 2026)

• Axios, IBM plans to triple entry-level hiring this year because of AI (February 2026)