AI e sviluppo software: lo specchio della maturità organizzativa

L’idea che l’AI debba automaticamente abbassare i costi del software è fuorviante: accelerare la scrittura del codice non rende più efficiente l’intero percorso che porta un’idea a generare valore in produzione. L’AI non è una “macchina di sconti”, ma un amplificatore del sistema: rende più visibili sia le buone pratiche sia le fragilità con cui business, IT e fornitori operano ogni giorno. 

Inserita in organizzazioni rigide, governate da tempi, budget e gare orientate al ribasso, l’AI rischia di diventare un altro argomento per ottenere sconti immediati. Ma inseguire lo “sconto AI” significa spesso comprare costi futuri: più debito tecnico, qualità instabile, minore scalabilità ed evolvibilità del sistema. 

Il vero potenziale emerge quando l’AI diventa un’occasione per ripensare la collaborazione tra business, IT e fornitori: cicli iterativi più rapidi, decisioni basate su evidenze, maggiore trasparenza su rischi e sul valore di business generato. In questo scenario l’AI non potenzia solo lo sviluppo, ma aiuta a evitare ciò che non serve, riduce gli sprechi e rafforza la qualità delle scelte. Il risultato, nel tempo, è un sistema più capace di generare valore, più solido, più evolvibile e con un costo totale di proprietà realmente inferiore.

Mi capita spesso, in conversazioni di business o durante attività di formazione manageriale, di sentirmi dire, talvolta anche come battuta, una frase di questo tipo: “Ora che c’è l’AI che scrive il codice, i costi della realizzazione del software devono necessariamente calare”. 

È una domanda naturale per chi guarda al fenomeno da fuori. Se gli strumenti di AI-assisted coding sono in grado di proporre porzioni di codice in pochi secondi, è intuitivo aspettarsi un minor impiego di risorse per lo sviluppo e, di conseguenza costi più bassi. Per un CIO impegnato in programmi ambiziosi di trasformazione digitale e sotto pressione per rispettare budget e scadenze, questa equazione è doppiamente allettante: offre una narrativa intuitiva da portare al board e sembra una leva immediata di negoziazione con i fornitori. 

Il punto è che questa equazione, pur comprensibile, non descrive come si genera davvero valore in un progetto software. Riduce lo sviluppo software a “scrivere codice più velocemente”, mentre costo e impatto dipendono soprattutto da ciò che accade lungo tutto il processo di realizzazione di un’applicazione software: dalla qualità della collaborazione cliente–fornitore, dal modo in cui si pianifica e si apprende, dal livello di evolvibilità dell’intero sistema, dalla capacità di governare il rischio operativo. 

In questo senso, l’AI non è un moltiplicatore lineare di produttività né un semplice argomento per rinegoziare le tariffe o le offerte economiche. È, molto più spesso, uno specchio: riflette e amplifica la maturità, o le fragilità, del sistema socio-tecnico costruito nella relazione tra cliente e fornitore. Per un CIO, dunque, la posta in gioco non è “ottenere uno sconto”, ma evitare la trappola delle promesse di risparmio immediato che spostano i rischi più avanti nel tempo e, in alcuni casi, li amplificano, rendendoli più difficili e costosi da gestire.

Negli ultimi anni si è consolidata una narrativa semplicistica: quella del “programmatore 10x”. Secondo questo racconto, strumenti come Copilot trasformerebbero un developer in uno straordinario moltiplicatore di produttività. Se il singolo sviluppatore produce più codice in meno tempo, allora, si pensa, tutto il progetto va più veloce e il costo del software deve diminuire. 

Questa logica appare intuitiva, ma si fonda su un malinteso. Non riguarda ciò che l’AI fa o non fa, ma come funziona realmente la Value Stream della costruzione del software. 

Lo sviluppo software non è una catena di montaggio in cui la parte principale è “scrivere codice”. È un flusso composto da molte fasi interconnesse. La scrittura del codice è solo uno dei passaggi e, nella maggior parte dei team, assorbe in media il 20–30% del tempo complessivo (c’è ampia letteratura che lo conferma [1]). 

In una software factory che lavora in modo professionale, le attività chiave possono essere sintetizzate così: 

 

• discovery continua e co-progettazione del valore (dominio, requisiti, metriche di successo ed outcome di business) in stretta collaborazione con il cliente; 
• progettazione architetturale evolutiva (emergent design) guidata dai requisiti, dall’evoluzione tecnologica, dai vincoli di contesto e dai principi di sicurezza e resilienza; 
• implementazione iterativa con qualità e sicurezza integrate (quality & security by design, TDD, refactoring, gestione del debito tecnico); 
• integrazione e delivery continua (CI/CD) per un flusso di rilascio automatizzato, validato e sicuro; 
• rilascio controllato e osservabilità del software in produzione con gestione operativa basata su SLA (Service Level Agreements), osservabilità proattiva e incident management; 
• feedback loop rapidi e allineamento costante con misurazione continua del flusso, validazione degli outcome di business e allineamento continuo tra team, cliente e stakeholder. 
  
   
  
  Questa serie di attività costituisce una solida Value Stream [6]: un insieme di passaggi collegati, ognuno dei quali deve funzionare perché il valore possa fluire dal bisogno iniziale al risultato in produzione. Se un solo passaggio accelera, ma gli altri restano invariati, il flusso complessivo (throughput) non cambia: si sposta solo il collo di bottiglia. 
  
  In questo quadro l’osservabilità non è più solo una metodologia di telemetria sistemistica, ma diventa una leva economica: permette di capire dove il flusso si inceppa, quali cambiamenti generano regressioni, quali parti del sistema stanno accumulando rischio. In un mondo in cui l’AI aumenta il volume e la velocità delle modifiche, trattare l’osservabilità come un costo da comprimere, anziché come un investimento strategico per governare la complessità, è sempre più pericoloso. Un CIO che non investe sull’osservabilità può ottenere una riduzione dei costi sul budget IT, ma spesso compra più incidenti, più rework e più esposizione operativa sul medio periodo. 
  
  Se anche l’AI portasse a zero il tempo di scrittura del codice, ridurrebbe il tempo complessivo solo di una frazione. È la classica situazione descritta dalla Legge di Amdahl: “Anche se una parte di un processo diventa rapidissima, la velocità totale del processo dipende da tutte le altre parti che non sono state accelerate” [2]. 
  
  Di conseguenza, anche assumendo, in modo ottimistico, che l’AI azzeri il tempo di scrittura del codice, l’effetto sul ciclo end-to-end sarebbe limitato, se tutto il resto rimane inalterato. Di più: se nella Value Stream l’attività di scrittura del codice è connessa in modo fragile al resto (architetture deboli, processi poco agili, collaborazione cliente-fornitore scarsa, forte pressione su milestone e scadenze), l’effetto può essere addirittura negativo. In pratica, si finisce per produrre più velocemente ciò che è mal progettato, mal governato e poco osservabile: codice che sembra “avanzare”, ma che nasconde errori, incoerenze e scelte subottimali che verranno pagate dopo, con rework più ampi, maggiore debito tecnico e un ciclo di sviluppo meno controllabile.

Negli ultimi mesi stanno emergendo evidenze oggettive che incrinano la narrativa secondo cui l’AI, da sola, renderebbe automaticamente più veloce lo sviluppo software. 

Non si tratta di negare che l’AI possa aumentare sensibilmente la velocità su molte attività: dalla prototipazione rapida, alla realizzazione di proof of concept, fino alla produzione di funzionalità di contorno in tempi prima impensabili. Questi effetti sono reali e già osservabili in molte organizzazioni. Ma alcuni studi, e qui ne cito un paio rilevanti (uno sperimentale, uno osservazionale) evidenziano su basi oggettive una dinamica più complessa: l’AI accelera una fase del lavoro, ma non necessariamente accelera il sistema. 

Il primo è lo studio METR 2025 [3], uno dei pochi esperimenti controllati condotti su sviluppatori impegnati su repository reali. Il risultato è controintuitivo: con l’AI gli sviluppatori impiegano in media il 19% di tempo in più per completare i task, pur essendo convinti di essere stati più veloci. Non è un paradosso: è il comportamento tipico dei sistemi complessi quando si ottimizza solo una fase. L’AI genera molte alternative plausibili; crea più varianti, più percorsi possibili, più decisioni da prendere. Il lavoro si sposta così dalla scrittura all’analisi: filtrare, comprendere, scegliere, integrare. In termini manageriali, aumenta il carico cognitivo e cresce il code churn, cioè la quantità di codice proposto, valutato, scartato o riscritto. 

Il risultato? La velocità con cui si produce codice cresce, ma la velocità e la qualità del flusso end-to-end non migliorano in modo proporzionale e, in molti casi, peggiorano. 

Il secondo segnale arriva dal DORA State of DevOps Report 2024 [4], una fonte molto autorevole sulle performance di delivery. Qui il fenomeno è osservato su scala organizzativa: l’uso estensivo di AI-assisted coding porta a un aumento del codice prodotto, ma anche a change set più grandi, review più complesse e rilasci più rischiosi. 

Questa combinazione, vale a dire più codice, change set più grandi, maggiore complessità, rende indispensabile ripensare anche le pratiche di qualità: 

 

• test automatizzati più estesi; 
• strategie di progressive delivery; 
• validazione in produzione; 
• meccanismi di quality gate più robusti. 
  
   
  
  Non basta “mettere l’AI nell’IDE”: occorre rafforzare l’intero sistema di testing e controllo, altrimenti il guadagno di velocità locale si traduce in più incidenti e più costi di remediation. 
  
  In sintesi: si produce più codice, ma in blocchi più difficili da assorbire per il sistema. Il flusso si appesantisce, non si alleggerisce. Questi dati non mettono in discussione l’utilità dell’AI. Mettono in discussione l’hype: se l’AI viene inserita in processi già fragili o poco osservabili, amplifica le fragilità invece di risolverle. 
  
  Un modo semplice per rendersi conto di queste fragilità è passare dalla domanda: “Quanto più velocemente stiamo scrivendo codice?” a quella “Come stanno cambiando change failure rate, MTTR, volume di rework e incidenti critici da quando usiamo l’AI?”. Se queste metriche peggiorano mentre il fornitore continua a parlare solo di “produttività”, il problema non è l’AI in sé, ma il modo in cui è stata introdotta nella Value Stream.

Estendendo lo stesso modo di ragionare all’intero ciclo di vita del software, la domanda chiave non è più “Quanto tempo risparmiamo nello scrivere codice?”, ma “Come l’AI sta cambiando il sistema di lavoro nella relazione cliente–fornitore?”. 

È qui che emerge il problema strutturale. In molti progetti ci si concentra ancora sugli output di processo: rispetto delle tempistiche, aderenza al budget, completamento delle milestone pianificate. Sono parametri necessari, ma descrivono soltanto se il progetto è avanzato “secondo il piano”, non se ciò che viene costruito genera valore reale per l’azienda. 

In un contesto in cui la trasformazione digitale è pervasiva e continua, i manager più illuminati sanno che limitarsi a controllare tempi e costi non garantisce risultati. È spesso una forma di rassicurazione, più che una leva di competitività. Un progetto può rispettare ogni milestone ed essere, allo stesso tempo, irrilevante per il business; può rimanere “on time & on budget” e non produrre alcun impatto misurabile per avvicinare l’azienda ai propri obiettivi di business. 

L’AI si inserisce proprio in questa zona di ambiguità. Se la relazione cliente–fornitore rimane ancorata alla logica del controllo dell’esecuzione, l’AI verrà inevitabilmente interpretata come uno strumento per comprimere ulteriormente tempi e prezzi. Diventerà l’ennesima leva tattica per “fare prima e spendere meno”, senza rimettere davvero in discussione che cosa si sta costruendo, come si prendono le decisioni, come si governa l’evoluzione del sistema. 

È qui che nasce il fraintendimento più pericoloso: l’idea che l’AI sia una scorciatoia che permette di ottenere lo stesso risultato “più velocemente”, invece di una tecnologia che chiede di ripensare l’intera collaborazione, non solo una sua fase. 

C’è un elemento ulteriore, spesso sottovalutato: l’impatto sulla sicurezza psicologica [5]. Si tratta di un effetto più sottile: soprattutto se sotto pressione in quanto chiamati alla compressione dei tempi di delivery, gli sviluppatori tendono a "chiedere all’AI" invece di confrontarsi con i colleghi. Nel breve periodo sembra efficiente, ma nel medio erode le pratiche di pairing, mentoring e revisione critica condivisa che sono alla base delle performance elevate dei team. Dal punto di vista delle aziende committenti, questo si traduce in maggiore vulnerabilità: meno persone comprendono davvero il sistema, aumenta la dipendenza da poche figure chiave o, peggio, da codice generato di cui nessuno è pienamente responsabile. 

Al contrario, in un contesto di fiducia e trasparenza l’AI accelera l’apprendimento, favorisce lo scambio tra colleghi, potenzia la qualità tecnica e riduce i rischi. È un discriminante decisivo: senza sicurezza psicologica, ogni miglioramento tecnologico è fragile. Nei sistemi complessi, e la realizzazione di software lo è a pieno titolo, l’efficienza locale non è mai garanzia di efficacia globale. 

Questo vale in particolare per le figure più junior. Lo sviluppo software rimane, di fatto, un mestiere da apprendere sul campo: si cresce osservando, chiedendo, sperimentando insieme a persone più esperte. L’AI può diventare un acceleratore potente di apprendimento, aiutando gli junior a esplorare soluzioni e a formulare domande migliori prima di coinvolgere i senior, ma non può sostituire il confronto umano. Pensare che “con l’AI non servano più junior” significa indebolire la capacità dell’organizzazione di rinnovare le proprie competenze nel tempo e aumentare il rischio di dipendenza da pochi specialisti. 

La verità è che il collo di bottiglia non è nella fase di scrittura del codice mediante un algoritmo generativo, ma nel modello organizzativo e relazionale. E finché non si affronta questa dimensione, ogni accelerazione prodotta dagli strumenti rimarrà confinata, rischiando di creare squilibri invece che benefici.

Se osserviamo i progetti che non solo arrivano in produzione, ma continuano a generare risultati tangibili nel tempo, emerge un tratto ricorrente: il valore non nasce dalla velocità di una singola fase, bensì dalla capacità di cliente e fornitore di lavorare in cicli iterativi di co-creazione, orientati a outcome di business misurabili [7]. È qui che si vede la differenza tra un software “consegnato” e un software che diventa asset strategico. 

In questo tipo di dinamica, l’AI mostra il suo potenziale reale. Non è il centro del processo, né un sostituto dell’ingegno umano: è un abilitatore che amplifica la qualità e la velocità delle decisioni condivise. Può accelerare la creazione di documenti di requisiti, proporre alternative di design, sintetizzare feedback degli stakeholder, analizzare dati di utilizzo e individuare pattern che aiutano a capire dove concentrare le energie. 

Ma l’accelerazione più significativa non nasce dagli artefatti generati. Nasce dal fatto che cliente e fornitore possono iterare più rapidamente, riducendo le incertezze e correggendo la rotta sulla base di informazioni più ricche e tempestive. Questo cambiamento non riguarda solo il fornitore: produce effetti diretti anche sulle attività interne del cliente, perché l’intero team congiunto (business, IT e software factory) cresce in allineamento, capacità decisionale e velocità di apprendimento. 

La differenza la fa il modo in cui si misura il progresso. Quando l’attenzione resta su milestone, ore rendicontate o avanzamento rispetto al piano, l’AI tende a essere interpretata come un semplice strumento per comprimere tempi e costi. Quando invece la conversazione si sposta su ciò che davvero conta, vale a dire adozione reale, impatto sui processi, riduzione degli errori, velocità con cui una funzionalità genera ritorno, allora l’AI diventa un alleato potente. Contribuisce a mettere in luce cosa sta funzionando e cosa no, rafforza il processo di prioritizzazione, alimenta il confronto con dati anziché opinioni. 

In questa prospettiva, le metriche servono come innesco di conversazioni di miglioramento, non come strumento di giudizio sui singoli. E perché queste conversazioni siano possibili, è necessario che nel sistema esista un minimo di “slack”: se i team operano stabilmente al 90–100% di utilizzo, non c’è spazio né per sperimentare nuovi modi di usare l’AI né per intervenire sui colli di bottiglia che le metriche rendono visibili. Tenere i team costantemente saturi è apparentemente efficiente, ma di fatto blocca la capacità di apprendere e ridurre strutturalmente i costi. 

In fondo, i principi alla base di Agile e DevOps (flusso continuo, feedback rapidi, apprendimento costante) sono ormai l’aria che si repira nei team più maturi. L’AI si innesta su questo terreno: ne amplifica le potenzialità se esistono piattaforme interne pensate con una logica di product e design per gli sviluppatori (Platform Engineering), ma fatica a produrre benefici duraturi quando gli strumenti rimangono iniziative isolate, lasciate alla buona volontà dei singoli, magari spinti ad aumenti di produttività dettati dalla sola pressione sulla riduzione delle tariffe giornaliere. 

È in questo contesto che l’AI si rivela realmente trasformativa. Riduce tempi e costi non perché “scrive il codice al posto degli sviluppatori”, ma perché rende il ciclo iterativo più rapido, più informato e meno soggetto a sprechi. Evita rework inutili, limita l’accumulo di debito tecnico, aiuta a non sviluppare ciò che non serve. In sintesi, rende il sistema complessivo più intelligente e più capace di apprendere. Per il CIO e la Direzione IT dell’azienda committente, in prospettiva, minori costi di manutenzione, meno incidenti, migliore prevedibilità del portafoglio e maggiore credibilità verso il board. 

La vera accelerazione non nasce quindi dall’IDE o dai tool AI, ma dalla relazione: quando cliente e fornitore lavorano come un unico sistema orientato al valore, l’AI diventa un moltiplicatore naturale. Non un automatismo tecnologico, ma la conseguenza di un modo diverso, e senza dubbio migliore, di costruire software.

Arrivati a questo punto, la frase iniziale: “Ora che c’è l’AI che scrive il codice, i costi della realizzazione del software devono calare” può essere riletta con maggiore lucidità. 

Se per “costi” intendiamo l’efficienza puntuale su attività ripetitive o standardizzabili, è ragionevole aspettarsi un miglioramento: alcuni lavori si comprimono, certi sprechi si riducono, parte dell’effort manuale viene automatizzato. È un tema legittimo, ed è giusto discuterne, anche in sede di negoziazione con i fornitori. 

Ma se per “costi” intendiamo il costo complessivo di un sistema nel tempo, vale a dire la sua capacità di evolvere, scalare, generare valore, ridurre rischi, adattarsi al business, allora la domanda cambia natura. Entra in gioco la qualità della co-creazione tra cliente e fornitore, la capacità di operare in cicli iterativi basati su evidenze, la flessibilità delle decisioni economiche, il modo in cui si controlla il debito tecnico invece di amplificarlo più velocemente. 

Nella pratica, l’AI tende a rendere più visibili tensioni che già esistevano: processi rigidi, governance basata quasi esclusivamente su tempi e costi, scarsa capacità di riallocare budget sulla base dell’apprendimento, ruoli poco allineati tra business, IT interno e software factory fornitrici. L’AI non crea questi problemi; li illumina. È una lente che mette a fuoco ciò che prima rimaneva sfocato: dove il flusso si inceppa, dove mancano informazioni, dove la collaborazione si irrigidisce, dove il sistema non è progettato per cambiare. 

Per questo l’AI non è né un alleato né un avversario. È un acceleratore neutro: amplifica ciò che trova. Se la relazione cliente–fornitore è pensata per generare valore e apprendimento continuo, la tecnologia diventa un moltiplicatore naturale. Se invece la relazione è costruita intorno all’idea di controllo, contrattualistica e verifica dell’avanzamento, l’AI può dare l’illusione di accelerare, ma rischia di trasformarsi solo in un argomento per abbassare i costi nel breve periodo, senza creare vero beneficio nel medio periodo. 

La domanda da porsi, quindi, non è: “Quanto possiamo pagare in meno ora che l’AI genera codice?”, 

ma: “Come possiamo usare l’AI per ripensare insieme il modo in cui il valore fluisce dalla prima idea fino all’impatto sul business, riducendo nel tempo TCO e rischio operativo?” 

È un cambio di prospettiva: dall’output all’outcome, dai task alle evidenze, dalla negoziazione di prezzo alla collaborazione sulle scelte essenziali. 

In questo scenario più maturo, la riduzione dei costi totali non tarderà ad arrivare. Ma non come conseguenza meccanica della generazione automatica di codice: piuttosto come esito naturale di un modo diverso di lavorare, in cui cliente e fornitore selezionano ciò che conta, eliminano il superfluo, progettano per l’evoluzione e usano l’AI come leva per iterare più velocemente e meglio. 

L’AI non riduce la complessità: la rende visibile. Mostra dove il valore scorre e dove si blocca, dove la collaborazione funziona e dove il sistema si irrigidisce. È questo il punto che farà la differenza: non quanto codice viene generato, ma quanto velocemente clienti e fornitori, collaborando, trasformano l’apprendimento in decisioni, rilasci e risultati. 

Chi saprà leggere con onestà ciò che l’AI mette in evidenza costruirà sistemi più evolvibili, più affidabili e, nel tempo, anche più economici. Gli altri continueranno a negoziare sul prezzo, senza accorgersi che stanno perdendo la parte più importante del vantaggio competitivo offerto dall’AI.

[1] Meyer, A. N., Barton, L. E., Murphy, G. C., Zimmermann, T., & Bird, C. (2017). "How Do Software Developers Use Their Time? A Re-Analysis of the Literature." IEEE Transactions on Software Engineering.  

[2] Amdahl, G. M. (1967). "Validity of the single processor approach to achieving large scale computing capabilities." AFIPS Conference Proceedings.  

[3] Ziegler, D., et al. (2024). "Does AI Help All Programmers? A Randomized Trial of AI-Assisted Programming on Complex Software." arXiv preprint arXiv:2407.03607.  

[4] Google Cloud. (2024). 2024 Accelerate State of DevOps Report: The significant impact of AI on software development. DORA.  

[5] Edmondson, A. C. (1999). "Psychological safety and learning behavior in work teams." Administrative Science Quarterly.  

[6] Poppendieck, M., & Poppendieck, T. (2003). Lean Software Development: An Agile Toolkit. Addison-Wesley Professional.  

[7] Laplante, P. A., & Flaxman, K. H. (2012). "The customer-supplier relationship in agile software development." IEEE Software.