L’intelligenza artificiale accelera la generazione di codice, ma nelle aziende il salto di produttività resta spesso inferiore alle attese. Il motivo è semplice solo in apparenza: il collo di bottiglia non è più la scrittura del software, ma la capacità organizzativa di governare piattaforme, workflow, fiducia e compliance.
Nel dibattito tecnologico degli ultimi mesi, vibe coding è diventata una delle espressioni più usate – e forse abusate – per descrivere un nuovo modo di produrre software: si parte da prompt in linguaggio naturale, si itera rapidamente, e infine si ottiene codice in tempi drasticamente ridotti. Una pratica che si basa su un approccio esplorativo in cui si scrive codice “direttamente” a partire da intuizione e bisogno immediato, raffinando poi per prove ed errori successivi.
Indice degli argomenti
Vibe coding e produttività AI: la promessa della velocità
La promessa, dunque, è potente. Da assistenti per il completamento, i tool AI diventano sistemi che supportano task multi-step, aiutano a scrivere, testare e documentare software. GitHub ha documentato in uno studio controllato che gli sviluppatori con Copilot hanno completato un task il 55% più velocemente rispetto al gruppo senza assistenza AI. In altri termini: l’incremento di velocità nella fase di coding è concreto, reale.
Eppure, se alziamo lo sguardo e osserviamo i risultati aziendali, il quadro si complica. Il report DORA 2025 (DevOps Research and Assessment, pubblicato da Google Cloud) sottolinea che l’AI non migliora automaticamente la software delivery: tende piuttosto ad amplificare la qualità del sistema ingegneristico in cui viene inserita. Si evidenzia come il valore dell’AI si sblocca solo “reimmaginando il sistema di lavoro” in cui opera, e che i leader tecnologici dovrebbero trattarne l’adozione come una trasformazione organizzativa, non come semplice acquisto e adozione di tool. È qui che si colloca il vero paradosso della produttività del vibe coding: il codice arriva più in fretta, ma il valore non cresce alla stessa velocità.
Il coding accelera, la produttività organizzativa no
I numeri di adozione sono ormai difficili da ignorare. Secondo DORA, il 90% dei rispondenti utilizza l’AI al lavoro e oltre l’80% ritiene che abbia aumentato la produttività individuale. Anche Stack Overflow fotografa una penetrazione ormai mainstream: l’84% degli sviluppatori usa o pianifica di usare strumenti AI nel proprio workflow. Se ci fermassimo a questa lettura, dovremmo concludere che la questione è indirizzata: l’AI funziona, il fare coding è stato trasformato, la produttività è aumentata. Ma non è così. McKinsey osserva che, pur essendoci casi di beneficio, gli impatti enterprise-wide restano limitati: molte aziende vedono vantaggi in singoli use case, specialmente in ambito software engineering e IT, ma la traduzione in risultati economici e organizzativi diffusi è ancora immatura. L’AI incrementa volume e velocità di produzione del codice, ma senza adeguata disciplina ingegneristica quei guadagni non si trasformano automaticamente in migliori performance di delivery.
Il nodo, quindi, non è più la capacità di “produrre codice”, ma di assorbirlo. Se i team generano più output ma poi il testing, le review, la sicurezza, il rilascio e la governance non reggono quel ritmo, il vantaggio potenziale si disperde. È un rischio di “localized pockets of productivity” non ben assorbiti dal sistema organizzativo: i guadagni di velocità sono spesso inghiottiti da colli di bottiglia in fase di testing, security review e deployment complessi, e solo una piattaforma interna di qualità può mitigare questo rischio agendo come strato di distribuzione e governance dell’AI.
In altre parole: il problema non è che l’AI non sappia scrivere codice, ma che molte organizzazioni non hanno ancora ripensato il sistema che dovrà validare, distribuire e governare quel codice.
La vera sfida oggi si chiama fiducia
L’altro elemento notevole emerso nel 2025 è la crisi di fiducia. Stack Overflow segnala che più sviluppatori diffidano dell’accuratezza dei tool AI di quanti si fidino: il 46% esprime sfiducia attiva, contro il 33% che dichiara fiducia, e solo il 3% dice di fidarsi “molto”. Inoltre il sentiment positivo verso questi strumenti è sceso dal 70%+ del 2023-2024 al 60% nel 2025. Anche il report DORA rileva una tensione analoga: solo il 24% dichiara un livello alto di fiducia, mentre il 30% si fida “poco” o “per nulla”.
Un dato decisivo, perché separa nettamente l’adozione dall’industrializzazione. Un tool può essere utile anche se non è pienamente affidabile: lo posso usare per brainstorming, prototipi, documentazione. Ma se devo applicarlo in processi critici e sistemi regolati, la fiducia diventa requisito operativo. Non a caso Stack Overflow rileva che il 75% degli sviluppatori afferma che, in un futuro di AI ulteriormente avanzata, il motivo principale per cui continuerebbe a chiedere aiuto a una persona sarebbe “quando non mi fido delle risposte dell’AI”. Questa fiducia insufficiente spiega perché il vibe coding resti fortemente sbilanciato verso un uso in fase esplorativa. L’AI è dunque già ubiqua come supporto, ma non ancora normalizzata come motore principale di produzione del software professionale.
Cambia il lavoro degli ingegneri, non scompare
La narrativa semplicistica secondo cui l’AI ridurrà il bisogno di sviluppatori sta trovando sempre meno conferme. La maggior parte delle organizzazioni, e in particolare quelle più grandi e complesse, ha assunto per ruoli legati all’AI nell’ultimo anno, e software engineer, data engineer, AI product owner, data architect e machine learning engineer sono tra i profili più richiesti. Non è vero, quindi, che gli ingegneri servano meno: è che servono in modo diverso dal recente passato, in un passaggio da “doer” a “reviewer”: una quota significativa del codice generato dagli strumenti attuali richiede correzioni, e questo obbliga gli sviluppatori a spostarsi dal fare al valutare. In parallelo, cresce la domanda di profili senior capaci di governare architetture e orchestrare lavoro tra team, vendor e agenti.
È un cambiamento strutturale e culturale: meno tempo sulla digitazione pura, più tempo su specifiche, architettura, verifica, quality control, compliance. Se l’AI produce più output, il valore umano si sposta a monte e a valle: definire bene il problema, costruire il contesto giusto, verificare il risultato, presidiare i rischi. È questo il nuovo baricentro del software engineering.
Dove si crea il valore: piattaforme, dati, policy
Se la sola adozione del tool non basta, cosa distingue allora le organizzazioni che riescono a trasformare l’AI in vantaggio reale? DORA propone una risposta precisa con il suo AI Capabilities Model, che identifica sette capacità organizzative in grado di amplificare i benefici dell’AI: una posizione chiara e ben comunicata sull’uso dell’AI, ecosistemi dati sani, dati interni accessibili all’AI, pratiche solide di version control, lavoro eseguito in piccoli batch, focus user-centric e piattaforme interne di qualità.
È un passaggio culturale importante. L’AI non è una feature da aggiungere, ma una leva che rende più performanti, ma allo stesso tempo più critiche, le fondamenta note dell’ingegneria del software. Se i dati interni sono disordinati, i workflow sono opachi, le policy sono ambigue e le piattaforme non offrono feedback affidabili, l’AI non farà altro che aumentare il rumore più che il valore.
Tra queste capacità, la platform engineering emerge come vero moltiplicatore differenziante: quando la qualità della piattaforma è elevata, l’effetto dell’adozione AI sulla performance organizzativa diventa forte e positivo; quando la qualità è bassa, l’effetto è trascurabile. La piattaforma interna di qualità è così importante perché fornisce guardrail e capacità condivise che permettono di scalare i benefici dell’AI in modo efficace e sicuro.
Per un CIO o un responsabile engineering, il messaggio è netto: se l’AI accelera il singolo sviluppatore ma non esistono golden path, rollback semplici, test automatizzati, ambienti self-service, log comprensibili e policy chiare, il vantaggio si ferma in locale. Perché la produttività non è la somma delle righe di codice prodotte, ma la capacità dell’intero sistema organizzativo di portare software utile e affidabile sino all’utente finale.
Dal prototipo alla produzione: perché il vibe ha bisogno di specifiche
La seconda grande lezione riguarda il passaggio critico dall’esplorazione all’industrializzazione. Il vibe coding è fortissimo nelle fasi iniziali: riduce i costi di prototipazione, permette iterazioni veloci, abbassa la soglia di accesso. Ma appena cresce la complessità, emerge il costo della mancanza di specifiche. È esattamente il problema che AWS sta cercando di affrontare con Kiro, un tool che spinge i team oltre il vibe coding introducendo un workflow spec-driven: dai requisiti in linguaggio naturale genera user stories con acceptance criteria, design tecnico e task implementativi tracciabili. AWS descrive questa logica come un modo per mantenere il lato “fun” del vibe coding correggendone però i limiti: nei task complessi questo richiede troppa guida, può interpretare male il contesto e rende difficile tenere traccia delle decisioni prese lungo il percorso.
La differenza è cruciale per le organizzazioni mature: nel prototipo può bastare il prompt, in produzione invece servono artefatti condivisi: specifiche, criteri di accettazione, tracciabilità, testabilità, auditabilità. Kiro, ad esempio, non si limita a generare codice ma costruisce una specifica, la scompone in passaggi verificabili e consente al team di modificare ed arricchire il contesto a ogni fase. In altri termini, prova a trasformare conversazioni con il modello in documenti e processi riusabili. Per chi governa lo sviluppo software in azienda, questa è probabilmente la direzione più promettente: anziché opporre la velocità del vibe coding al rigore dell’ingegneria tradizionale, approntare un modello ibrido: esplorazione rapida all’inizio, formalizzazione progressiva, fino ad arrivare a software rilasciabile.
La governance non è un freno, è l’infrastruttura della fiducia
In Europa, questa discussione non va separata dal quadro regolatorio. L’AI Act richiede, per i sistemi ad alto rischio, che siano progettati in modo da consentire un’effettiva supervisione umana durante l’uso, e che raggiungano livelli appropriati di accuratezza, robustezza e cybersecurity lungo l’intero ciclo di vita. Il testo richiama inoltre obblighi di qualità gestionale, documentazione, logging automatico e azioni correttive.
Anche quando gli strumenti usati nello sviluppo software non ricadono direttamente nelle categorie high-risk, il principio organizzativo è già chiaro: più aumenta l’autonomia operativa dell’AI, più diventano necessari supervisione, log, metriche e meccanismi di intervento. La governance, insomma, non è il prezzo da pagare per usare l’AI, ma la condizione per potersene fidare. L’adozione efficace non nasce solo dal basso, dall’entusiasmo dei developer, ma dalla combinazione tra sperimentazione diffusa e responsabilità manageriale chiara.
La vera produttività è un problema di operating model
La conclusione, per molte organizzazioni, è in un certo senso controintuitiva. Per anni il vincolo era “scrivere software più in fretta”. Oggi quel vincolo si sta allentando e il problema diventa un altro: avere un operating model capace di convertire la nuova velocità in risultati affidabili, misurabili e governabili. L’AI è un amplificatore: se il sistema di sviluppo è forte, l’AI ne moltiplica i benefici. Se è fragile, ne accelera le disfunzioni. Per questo un dibattito maturo non dovrebbe concentrarsi solo su quale modello usare o quale agente integrare nell’IDE (Integrated Development Environment), ma su domande più concrete: abbiamo dati interni riusabili dall’AI? Le nostre piattaforme offrono feedback chiari? Possiamo “revertare” velocemente? Abbiamo specifiche condivise? Sappiamo misurare il valore generato? Abbiamo definito policy, responsabilità e livelli di supervisione?
Il vibe coding non è una moda passeggera, ma il segnale che la generazione del codice sta diventando più economica ed accessibile. Proprio per questo, il differenziale competitivo si sposta altrove: sulla qualità dell’organizzazione che sta intorno al codice. Per le imprese italiane, la sfida non è semplicemente “adottare l’AI nello sviluppo”: è costruire le condizioni perché quell’adozione produca software migliore, più sicuro, più governabile e più vicino ai bisogni reali di utenti e business. Senza questa trasformazione, il rischio è continuare a confondere un’accelerazione locale con un aumento di produttività complessivo.
Il paradosso del vibe coding, in fondo, è tutto qui: il software si può scrivere molto più velocemente di prima, ma il valore continua a dipendere da una “lentezza necessaria” con cui un’organizzazione può costruire fiducia, metodo e infrastruttura intorno a queste nuove pratiche di lavoro.
