[Shifted Bottleneck] When code is nearly free, where has the bottleneck of software engineering gone? The Transformation of Software Engineering in the AI Era — Learn AI Slowly #173
Quando il codice è quasi gratuito, il collo di bottiglia si sposta verso domanda, integrazione, verifica e allineamento
Quando la produzione di codice diventa quasi gratuita, il collo di bottiglia nella consegna del software non scompare: si sposta dal “scrivere codice” verso definire la domanda giusta, assemblare frammenti in un sistema funzionante, verificare che sia effettivamente corretto e allineare l’organizzazione. È una riedizione della Theory of Constraints nel settore software. Quarant’anni fa, la manifattura ha già percorso questa strada: ogni volta che un passaggio diventa più economico, il collo di bottiglia non svanisce — semplicemente si sposta verso il passaggio successivo più costoso. Capire questo ti permette di spiegare un enigma diffuso: gli strumenti di programmazione AI sono stati adottati in tutta l’azienda, scrivere codice è chiaramente più veloce, ma la velocità di consegna non è cambiata quasi per niente.
Un CIO di un gruppo manifatturiero mi ha mostrato i dati degli ultimi sei mesi. Il suo team IT, composto da oltre 80 persone, ha adottato pienamente gli strumenti AI di programmazione: guardando solo la produzione di codice, il numero medio di commit e la velocità di merge sono aumentati di oltre il 30%. Ma l’esperienza del business è completamente diversa: una piccola funzionalità di pianificazione intelligente richiede ancora almeno tre mesi dal lancio alla messa in produzione. Si aspettava un raddoppio della velocità, ma ha ottenuto solo “codice scritto più velocemente”. Le sue parole sono state chiare: “Ho speso milioni di euro per le licenze, e ho ottenuto sviluppatori più occupati e business più impazienti.”
Ha sbagliato la posizione del collo di bottiglia. Il vero collo di bottiglia era un’altra cosa: ogni nuova funzionalità doveva passare attraverso MES, ERP, sistemi di controllo qualità, terminali di reparto e un insieme di report normativi; l’integrazione e la messa a punto consumavano la maggior parte del tempo di sviluppo; mentre il codice generato dall’IA non aveva alcun checkpoint formale tra sé e l’ambiente di produzione. Anche se il codice viene scritto velocemente, si limita a fare la coda dietro un collo di bottiglia sbagliato.
1. L’industria manifatturiera lo sapeva 40 anni fa: il collo di bottiglia si muove
Per capire il presente, indossiamo prima gli occhiali che l’industria manifatturiera usa da 40 anni.
Nel 1984, l’esperto israeliano di origine fisica Eliyahu Goldratt scrisse il romanzo The Goal, che racconta come un direttore di fabbrica in procinto di fallimento riuscì a salvare un impianto. L’intero libro si riduce a una sola frase: la produzione di qualsiasi sistema è determinata dal suo elemento più stretto (il vincolo, ovvero il collo di bottiglia).
Allargare i componenti non vincolanti non migliora la produzione complessiva; solo allargando il collo di bottiglia stesso si accelera l’intero sistema. E non appena si allarga il collo di bottiglia, esso si sposta istantaneamente al prossimo punto più stretto. Questo è il Theory of Constraints (TOC).
Dopo 40 anni di automazione nel manifatturiero, la storia è quasi tutta una “corsa dei collo di bottiglia”. Quando le macchine CNC hanno reso la lavorazione più economica, il collo di bottiglia si è spostato al cambio di stampo e al controllo qualità; quando le linee flessibili hanno accelerato il cambio di stampo, il collo di bottiglia si è spostato alla pianificazione della produzione e alla coordinazione della supply chain; quando il MES ha reso la pianificazione più precisa, il collo di bottiglia si è spostato alla previsione della domanda e alla pianificazione inter-fabbrica. Ogni volta che si automatizza un tratto, il prossimo emerge. L’automazione non elimina mai i colli di bottiglia: li sposta semplicemente. Questa legge non è esclusiva del manifatturiero. Nel luglio 2026, nel podcast a16z Software in the Age of Agents, l’ex presidente di Windows di Microsoft Steven Sinofsky ha raggiunto la stessa conclusione usando esempi di software aziendale. Le sue parole esatte sono state:
“The long tail got no shorter. It just got longer in a different way.”
Ha citato il servizio clienti di Amazon: eliminare le chiamate telefoniche e far sì che il chatbot rilasci direttamente i prodotti sostitutivi. A prima vista risparmia manodopera, ma dietro le quinte scatta immediatamente la richiesta di un’analisi delle cause radice: “Come impedire che questo problema si ripeta?”, molto più complessa di gestire una chiamata. Lo stesso vale per i processi di rimborso: dopo l’accounting automatico tramite OCR, il compito del reparto finanziario diventa ottimizzare le spese di viaggio e confrontare dinamicamente i prezzi — il lavoro non è scomparso, si è semplicemente spostato dall’“inserimento” all’“analisi e decisione”. Un veterano di Microsoft e socio di a16z, senza ricorrere alla teoria di Goldratt, è giunto alla stessa conclusione raggiunta dall’industria manifatturiera 40 anni fa. Una proveniente dal reparto produzione, l’altra dal software aziendale: due percorsi indipendenti che convergono verso la stessa legge.
Ma va aggiunto un limite a questa legge, per evitare che venga letta come verità assoluta. Alcuni colli di bottiglia sono stati effettivamente eliminati in modo permanente: meccanografi, centralinisti, compositori di caratteri in piombo — queste professioni non si sono “spostate”, sono scomparse del tutto. La chiave per capire se un lavoro verrà spostato o cancellato sta nel vedere se la capacità liberata dall’automazione genera nuove domande (nella teoria economica, il paradosso di Jevons), oppure semplicemente fa contrarre la domanda esistente. La maggior parte dei compiti intorno ai sistemi centrali aziendali rientra nel primo caso: più veloce è il conto, più analisi dettagliate il management vuole vedere. Perciò la conclusione qui non è “l’automazione elimina quanti compiti?”, ma “sposta persone e budget dal livello automatizzato a quello appena emerso”. (Per un’analisi completa sulla lunga coda del trasferimento dal punto di vista del software aziendale, vedi l’appendice “La Stickiness del Software Aziendale”.)
Questo concetto è più vicino al software di quanto pensi. Nel 2013, Gene Kim ha quasi letteralmente trasferito la storia della fabbrica di Goldratt nel mondo dell’IT operations, scrivendo The Phoenix Project: come un CIO ha salvato un dipartimento IT sul punto di affondare l’intera azienda applicando la Teoria dei Vincoli. Quindi, “guardare al software con la mentalità dei colli di bottiglia della produzione” è un percorso già verificato, non una metafora tirata a caso. # 2. Torniamo al software: scrivere codice sta diventando l’anello più economico
Tre numeri chiariscono il concetto che “il costo di produzione del codice tende a zero”.
- Copilot: GitHub stessi ha rilevato che nei file con Copilot abilitato, circa il 46% del codice è stato generato da Copilot. Attenzione alla metrica: si tratta della percentuale all’interno dei file abilitati, non del 46% di tutto il codice su GitHub.
- Stripe: Il loro agente di coding interno, “Minions”, produce e merge ogni settimana oltre 1.300 PR (da 1.000 all’inizio, in costante crescita). C’è un dettaglio cruciale da ricordare: ogni PR deve essere revisionato manualmente prima del merge. Stripe ha automatizzato la “scrittura”, ma ha lasciato la “validazione” all’uomo. Questo punto sarà rilevante nella sezione 4.
- NVIDIA: Jensen Huang ha dichiarato pubblicamente che il 100% degli ingegneri NVIDIA usa strumenti di programmazione AI come Cursor; “lavorare senza AI” non è più accettabile in NVIDIA.
Se sovrapponi questi tre numeri, la conclusione è inequivocabile: il costo unitario per produrre una riga di codice sta rapidamente avvicinandosi a zero. La domanda acuta che ne segue è: se scrivere codice è quasi gratis, perché il software è ancora così costoso, lento e difficile da consegnare? La risposta è quella fornita dalla Teoria dei Vincoli: hai allargato la fase di “scrittura del codice”, ma il collo di bottiglia si è semplicemente spostato. Dove?
Tre: I colloqui si sono spostati in quattro luoghi
Questa volta, il colloquio si concentra su quattro fasi. Ognuna di esse è fuori dalla portata dell’IA a breve termine.
Prima fase: Definire la domanda giusta.
L’IA può scrivere in pochi secondi “la funzione che dici di volere”, ma non riesce a scrivere “la funzione che realmente ti serve”. La maggior parte dei progetti software fallisce perché il prodotto finito non viene usato da nessuno — perché fin dall’inizio non si è compreso a fondo quale problema si dovesse risolvere. Dopo che la produzione di codice è diventata più economica, “trasformare un problema aziendale vago in una specifica chiara, risolvibile e degna di essere risolta” (problem formulation) è diventata la capacità più rara e più costosa. I colleghi del settore manifatturiero lo sanno bene: se la linea di produzione o i disegni tecnici sono sbagliati, più efficiente è il processo di lavorazione, più pezzi difettosi vengono prodotti in serie.
Seconda fase: Integrazione del sistema.
L’IA è brava a generare “un pezzo di codice”, “una funzione”, “una pagina”. Ma un sistema pronto per la produzione è l’integrazione di centinaia di pezzi che devono scambiarsi dati, gestire i casi limite, mantenere la coerenza e resistere agli errori. Generare singoli pezzi è economico; assemblarli in un insieme affidabile è costoso. Questo costo deriva dall’allineamento organizzativo e architetturale — proprio ciò su cui si concentrano la legge di Conway e le team topologies (vedi i due articoli precedenti di questa serie). Torniamo al CIO manifatturiero citato all’inizio: il suo tempo non è stato speso a scrivere codice, ma a sincronizzare i sistemi MES, ERP, ispezione qualità e reporting.
Terza: Verifica. La quantità di codice esplode, la affidabilità è disomogenea. Chi decide “è corretto”? Test, code review, osservabilità, rollout graduale: il peso di questi processi di “verifica” non diminuisce, anzi aumenta. Questa è la bottiglia d’ingorgo più sottostimata, e quella con il riflesso più profondo nell’industria manifatturiera. Ne parleremo separatamente nella sezione 4.
Quarta: Allineamento organizzativo. Quando nel team entrano agenti AI, chi decide cosa fare, chi controlla, chi è responsabile dei risultati? È un’estensione della legge di Conway e delle team topology: l’allineamento organizzativo diventa esso stesso una bottiglia d’ingorgo. L’undicesimo articolo della serie affronterà in dettaglio: quando i nodi organizzativi non sono più solo umani, la governance diventa un vantaggio competitivo.
# 4. La ferita più profonda: la verifica, e cosa ci insegna davvero il "jidoka" di ToyotaTra le quattro bottiglie d’ingorgo, quella più spesso malinterpretata è la verifica. Molti la riducono a: “Poiché l’AI scrive veloce, facciamo più test”. È vero solo in parte. Per capire perché la verifica sia diventata costosa, dobbiamo prima chiarire correttamente il concetto di Jidoka — il più citato, e più malinteso, della filosofia Toyota.
Correggiamo subito un malinteso diffuso. Jidoka non significa “sostituire gli umani con AI o macchine”, né “trasformare gli umani in macchine, costretti a lavorare senza sosta”. Entrambi gli approcci sono esattamente l’opposto di ciò che intende Toyota.
Il termine “jidōka” contiene già la risposta. In giapponese, “automazione” è semplicemente “自動化”, ma Toyota ha scelto intenzionalmente “自働化”: il carattere “働” include il radicale “人” (uomo), sottolineando un’automazione “con un tocco umano”. Il suo significato preciso è: quando una macchina o una linea di produzione rileva un’anomalia, si ferma automaticamente per permettere a un operatore di intervenire, risolvere la causa radice e poi riprendere la produzione. Funziona con due meccanismi paralleli: le macchine sono dotate di rilevamento automatico delle anomalie e si fermano da sole; qualsiasi operatore sulla linea che noti qualcosa di sbagliato può tirare la corda dell’andon, fermando istantaneamente tutta la linea. La qualità non viene controllata alla fine, ma integrata in ogni singolo passaggio e risolta sul posto.
C’è una conclusione controintuitiva che trova un diretto parallelo nel software: più profonda è l’automazione, maggiore diventa il ruolo dei checkpoint di qualità e dell’intervento umano. La jidōka libera l’umano dall’operazione ripetitiva, rimettendolo nel ruolo chiave di “rilevare l’anomalia, fermare la linea, risolvere la causa radice”. Toyota concede agli operai di linea il potere di fermare l’intera produzione proprio perché sa che, per quanto potente sia l’automazione, serve sempre qualcuno in grado di dire “basta” quando qualcosa va storto. Questo è il vero significato del motto “dare intelligenza ai robot”: permettere alle macchine di fermarsi e chiamare l’uomo. L’uomo rimane sempre presente, incaricato di risolvere la causa radice.
Il software sta ripercorrendo questa strada, e lo sta facendo con grande fretta. La ricerca di GitClear sulla qualità del codice assistito dall’IA ha rilevato segnali di aumento di blocchi di codice ripetuti e di churn a breve termine: l’IA scrive veloce, ma scrive anche “che sembra corretto”. Quando un gran numero di righe di codice non è stato mai scritto manualmente da nessuno, il tradizionale meccanismo di fiducia basato sul “lo sviluppatore sa cosa sta facendo” fallisce. In questo contesto, ciò di cui hai bisogno è la versione software della corda di Andon e del sistema di arresto della linea:
- Test (unitari, di integrazione, end-to-end) passano da “fatti se possibile” a requisito obbligatorio: senza superarli, non si può mergiare;
- Il focus del Code review si sposta da “controllare lo stile” a “verificare l’intenzione e i confini”: cosa cerca di risolvere esattamente questo codice? Sono stati coperti tutti i casi limite?
- L’osservabilità (monitoraggio, log, tracing) diventa standard, perché il comportamento in produzione dice molto più del codice stesso;
- Il gray release / feature flag permette di validare prima il codice generato dall’IA su un piccolo gruppo di utenti, prima di rilasciarlo su larga scala.
Ripensando ai 1.300 PR della sezione precedente su Stripe: scrivere il codice è affidato all’agente, ma la fase di merge è rimasta interamente in mano alla revisione umana. Questo è un esempio vivente di jidoka nel software: automatizzare la produzione, ma lasciare la verifica all’uomo, e dare a quest’ultimo il potere di “bloccarla”. La produzione è diventata più economica, il controllo della qualità è diventato più costoso: questa è una regola immutata da 40 anni.
Cinque: Il premium della “definizione del problema”: Una capacità più preziosa del prompt
Se la verifica è un collo di bottiglia sottostimato, la “definizione del problema” è una capacità profondamente sottostimata.
Il prompt engineering ha avuto il suo momento di gloria, e molti hanno creduto che “saper scrivere prompt” fosse la competenza chiave. Ma il prompt è solo una tecnica per esprimere un problema. La vera rarità sta un passo avanti: problem formulation — trasformare un problema aziendale vago in una questione chiara, risolvibile e degna di essere risolta. Questo passaggio, l’AI non lo può compiere nel breve termine, perché deve aspettare che tu le dica prima: “Cos’è esattamente il problema?”.
I veterani dell’industria manifatturiera ne conoscono meglio di tutti il peso. Se un disegno tecnico o un percorso di lavorazione è sbagliato, anche la produzione e l’assemblaggio più efficienti genereranno solo errori su larga scala. Lo stesso vale nel software: se i requisiti sono mal definiti, l’AI ti aiuterà a produrre dieci volte più velocemente qualcosa che nessuno vuole.
Un criterio semplice: smetti di competere sulla velocità di scrittura del codice; allenati invece sulla chiarezza nella scomposizione dei problemi.
In un’organizzazione, questo significa istituire ruoli formali per la “definizione dei requisiti” e la “verifica e accettazione”, e non lasciare che siano compiti aggiuntivi dei developer. Dopo che l’AI ha reso l’implementazione economica, questi due ruoli hanno visto il più rapido aumento di valore.
Sei: Come appaiono i veri collo di bottiglia in quattro settori
Applicando il concetto di “trasferimento del collo di bottiglia” a quattro settori, si scopre che il vero limite non sta mai nella scrittura del codice.
Manufacturing. The central figure is the CIO introduced at the start. Functions like intelligent scheduling, quality traceability, and energy optimization are technically straightforward—many models are already available. The bottleneck lies in integrating and debugging the MES/ERP/quality inspection/reporting systems, along with on-site validation at shop-floor terminals. Code for these projects is often written quickly, but integrating MES/ERP systems can consume several times more time than writing the code itself. Only by placing acceptance testing directly at the shop-floor terminals and integration points can defects be caught on the spot, rather than surfacing only after production goes live.
Telecom / Carriers. A single plan change or enterprise专线 activation must traverse multiple domains: channels, billing, CRM, network provisioning, and field scheduling. AI has accelerated development within each domain, but end-to-end cross-domain integration and consistency validation remain the dominant time sinks. Carriers face a unique bottleneck: compliance and reconciliation. A billing discrepancy of even one cent is an incident—and the weight of verification exceeds that of any other industry. Take enterprise专线 activation: while AI speeds up development in each domain, end-to-end integration combined with billing reconciliation still often consumes the majority of the project timeline.
Finanza. Un aggiornamento di una regola per il rischio di credito o l’anti-lavaggio di denaro attraversa App, sistemi core, engine di risk management, data platform e reportistica normativa. Il peso della verifica qui è estremamente elevato: un solo errore può diventare un incidente di conformità. Il collo di bottiglia sta nella spiegabilità, tracciabilità e auditabilità: anche la regola scritta dall’IA è troppo precisa, se non riesce a rispondere al regolatore con “perché questa decisione?”, non può essere messa in produzione. L’iterazione delle regole anti-lavaggio è un esempio tipico: l’IA accelera la scrittura delle regole, ma la revisione della spiegabilità del modello e l’allineamento con i report normativi consumano spesso la maggior parte dell’intero ciclo.
E-commerce. Una funzionalità promozionale o di grande evento attraversa prodotti, transazioni, marketing, logistica e assistenza clienti. L’IA permette di scrivere pagine e API in modo estremamente rapido, ma il collo di bottiglia si sposta verso stress testing, coerenza dell’inventario, prevenzione delle frodi e reconciliation. Le piattaforme che cadono durante un grande evento non sono mai quelle con codice scritto lentamente, ma quelle con confini non verificati. La preparazione per un grande evento è un microcosmo: la pagina promozionale può essere generata dall’IA in pochi minuti, ma lo stress testing end-to-end e la verifica della coerenza dell’inventario spesso assorbono la maggior parte delle ore di preparazione.
La comune caratteristica di questi quattro settori è chiara: l’IA accelera il “scrivere”, ma blocca il “comporre, verificare, allineare”. Investire la capacità di sviluppo risparmiata in queste tre attività è l’unico modo per ottenere un vero aumento di efficienza.
Sette: Cosa succede se si sbaglia: i tre più comuni mismatch
Prima opzione: confondere “scrivere codice velocemente” con “consegnare più velocemente”.
È l’illusione più comune. Il codice è solo un anello della catena di consegna: allargarlo non accelera l’intera catena, ma accumula solo più prodotti parziali dietro il collo di bottiglia. La teoria dei vincoli chiama questo “inventario”; nel software, si chiama PR non approvate e branch non integrati. Il risultato? Sviluppatori più occupati, business più pressanti, output invariato — esattamente la situazione del CIO citato all’inizio.
Seconda opzione: accelerare la produzione eliminando i controlli di qualità.
È un errore tipico che viola il principio di jidoka. Qualcuno pensa: “L’IA scrive veloce e bene, possiamo semplificare il code review e tagliare i test”. Esattamente il contrario: più veloce è la produzione, più forte dev’essere la corda dell’andon. Rimuovere i gate di accettazione è come far girare a piena velocità una linea di montaggio senza nessuno a controllare: i difetti si moltiplicano e arrivano in produzione con maggiore rapidità.
Terza opzione: investire dove non c’è il collo di bottiglia.
L’integrazione è il collo di bottiglia, ma compri più licenze AI per la programmazione; la verifica è il collo di bottiglia, ma assumi più sviluppatori. La teoria dei vincoli lo ha già spiegato chiaramente: investire dove non c’è il collo di bottiglia non aggiunge valore al output totale — e peggiora solo i conti. L’ordine corretto è: prima identificare il collo di bottiglia, poi concentrare tutte le risorse su di esso.
VIII. Implicazioni per i decisori
Implicazione 1: Prima di acquistare strumenti, disegna una mappa dei colli di bottiglia.
Analizza le ultime tre consegne in cui ti sei bloccato: dove è andato realmente il tempo? Sei bloccato a scrivere codice, a integrare componenti, a trovare chi lo verifichi, o perché i requisiti non sono chiari? Se non riesci a identificarlo, stai solo speculando a livello tecnico. Una mappa dei colli di bottiglia vale più di qualsiasi lista di acquisti strumentali: può evitare almeno la metà degli investimenti IT inutili nelle grandi aziende.
Implicazione 2: Investi la capacità liberata nei requisiti e nella verifica.
L’AI accelera lo sviluppo, il che significa che hai risorse da riassegnare. Assegna formalmente queste persone ai ruoli di “definizione dei requisiti” e “verifica e accettazione”, e non lasciare che continuino a scrivere più codice. Il ritorno su questi due ruoli sta crescendo più velocemente nell’era dell’AI.
Implicazione 3: Installa una corda di Andon nel tuo software.
L’implementazione più diretta dell’automazione è impostare soglie rigide nel tuo CI/CD: non permettere il merge se i test falliscono, richiedere che il review verifichi intenzione e boundary, avviare il rollout in modalità gray-scale su piccola scala, e rendere l’osservabilità uno standard. Più la produzione è automatizzata, più questa barriera deve essere solida. È l’unico modo per impedire che “codice gratuito” diventi “incidente gratuito”.
Implicazione 4: Riorganizza il ruolo delle persone, non rimuoverle.
L’automazione porta a una stessa conclusione: più l’automazione si approfondisce, più le persone devono essere posizionate nei ruoli di “giudizio, verifica, analisi delle cause radice”. Liberale dalle operazioni ripetitive e riassegnale alla verifica e all’allineamento: questo è l’atto centrale del design organizzativo nell’era dell’AI, e sarà approfondito nelle prossime parti di questa serie.
9. Forse ti stai chiedendo
“Siamo solo in fase pilota con l’AI, davvero serve mappare tutti i colli di bottiglia aziendali?”
Anche in una fase pilota, bisogna prima capire: l’elemento su cui stiamo facendo il pilota, è davvero il collo di bottiglia? Se il punto critico è nell’integrazione o nella verifica, investire sull’AI nel “codice” significa spendere soldi dove non serve — esattamente il terzo errore descritto nella sezione 7. Fai prima una piccola diagnosi dei colli di bottiglia: solo così i soldi per gli strumenti saranno ben spesi.
“La fase di verifica non rallenterà la consegna?”
A breve ci sarà attrito, a lungo termine accelererai. La “velocità” senza checkpoint di accettazione è solo velocità nel spingere difetti in produzione — il costo del ripristino parte da dieci volte di più. L’esperienza dell’automazione è chiara: risolvere un difetto sul posto costa una frazione di quanto costa risolverlo quando è già scivolato a valle.
“Che c’entra tutto questo con la nostra trasformazione AI?”
C’entra direttamente. Il più comune errore nella trasformazione AI è assumere che il collo di bottiglia stia nel “codice / capacità produttiva”, e comprare un sacco di strumenti per allargare proprio quel punto. Fai prima la diagnosi del collo di bottiglia, poi decidi dove investire. Per questo ho posizionato “valutazione delle capacità” e “identificazione degli scenari di valore” all’inizio del framework “7 Passi per la Trasformazione AI”: prima capisci dove sta il collo di bottiglia, poi parli di strumenti.
Reverse self-check (don’t sugarcoat your answer): The last time you got stuck delivering something, where did the time really go—writing code, or piecing it together, validating it, and aligning it? Out of all the code your AI tools generate, how much actually ships stably and is actively used by real users? In your CI/CD pipeline, is there a hard gate that blocks merges unless tests pass? If you feel uneasy about even one of these three, don’t rush to buy more AI tools—first, find your actual bottleneck.
Next Steps
This is the third of 15 posts in the series “The Transformation of Software Engineering in the AI Era.” We’ve moved from Conway’s Law (organization shapes architecture) to Team Topologies (how to design teams), and now to bottleneck shifting (when code is nearly free, where does the bottleneck go?). The next post (No. 4) shifts to a more hands-on perspective: how to choose mainstream AI programming tools. But the conclusion may be counterintuitive: tool selection is ultimately an organizational decision—choose based on your maturity and governance level, not on “whose code looks coolest.”
Series Note: This series continuously tracks the latest evolution of AI programming tools, organizational structures, and software engineering paradigms—such as how Conway’s Law may evolve in the age of AI agents by 2026, or the maturity of emerging tool ecosystems. Follow this series for ongoing insights.
About This Series
La trasformazione dell’ingegneria del software nell’era dell’IA
È una serie di approfondimenti rivolta a CIO/CDO/CTO e responsabili della digitalizzazione nei settori delle telecomunicazioni, finanziario, manifatturiero ed e-commerce, composta da 15 articoli. Basata su oltre 200 articoli accademici e report di settore, offre riferimenti decisionali con annotazioni sui livelli di evidenza.
Sono un ex ingegnere IBM e coach certificato ICF, con esperienza diretta nell’implementazione di progetti IA e digitali per operatori di telecomunicazioni e grandi aziende. Qui scrivo giudizi pratici maturati accompagnando le imprese attraverso gli errori e le sfide reali.
Fonti di riferimento (tutte verificate)
a16z (2026). Software in the Age of Agents. The a16z Podcast. (La citazione di Steven Sinofsky, ex presidente di Windows di Microsoft: “The long tail got no shorter, it just got longer in a different way” — una conferma indipendente dalla prospettiva del software enterprise della legge del trasferimento del collo di bottiglia TOC; fonte primaria — audio originale del podcast. Posizione dichiarata: socio di a16z / ex executive Microsoft. Ospiti verificati: Seema Amble, socio del team enterprise di a16z; Steven Sinofsky, board partner ex presidente di Windows; Elena Burger, autrice di a16z; trasmesso nel luglio 2026.)
Goldratt, E. M. (1984). The Goal: A Process of Ongoing Improvement. (Fonte originale della Teoria dei Vincoli (TOC); romanzo ambientato in una fabbrica manifatturiera; fonte primaria.)
Kim, G., Behr, K. & Spafford, G. (2013). The Phoenix Project. IT Revolution Press. (Trasferisce direttamente la TOC di Goldratt nell’IT operations; il ponte tra manifattura e software; fonte primaria.)
Toyota. Toyota Production System — Jidoka (自働化). toyota-global.com (Jidoka = automazione con il carattere “人”; arresto della linea in caso di anomalia + intervento umano per risolvere la causa radice; sistema Andon; fonte primaria.)
GitHub (2022/2024). The Economic Impact of the AI-Powered Developer Lifecycle. (Copilot attiva il completamento in-file per circa il 46% del codice; la misura è “enabled in-file”; fonte primaria.)
Stripe (2025/2026). Minions: Stripe’s one-shot, end-to-end coding agents. stripe.dev/blog; InfoQ riporta oltre 1.300 PR settimanali con revisione umana completa (fonte primaria + secondaria)
NVIDIA / Jensen Huang. Dichiarazioni pubbliche secondo cui il 100% degli ingegneri utilizza strumenti di programmazione AI come Cursor (dichiarazione diretta)
GitClear (2025). AI-Assisted Code Quality Research. (Osserva un aumento del codice ripetitivo e del churn a breve termine sotto assistenza AI, supportando l’idea che “la verifica diventa più costosa”; fonte secondaria.)
Forsgren, N., Humble, J. & Kim, G. (2018). Accelerate. IT Revolution Press. (Le prestazioni di rilascio sono determinate da cultura, velocità di flusso e feedback, non dalla velocità di codifica individuale; fonte primaria.)
buymeacoffee
![[Shifted Bottleneck] When code is nearly free, where has the bottleneck of software engineering gone? The Transformation of Software Engineering in the AI Era — Learn AI Slowly #173](https://cdn.iaiuse.com/img/2026/07/13/d39583784356669e4e768cd4d75981e6.webp)
