Il codice generato dall’intelligenza artificiale sta trasformando lo sviluppo software a una velocità senza precedenti. Ma i dati sulla qualità e sulla sicurezza raccontano un’altra storia: la produttività di oggi rischia di diventare il debito tecnico e normativo di domani. Cinque passi per governare il fenomeno, tra Cyber Resilience Act e responsabilità del produttore.
Indice degli argomenti
Cos’è il vibe coding e da dove viene
Nel febbraio 2025 Andrej Karpathy, ex direttore AI di Tesla e cofondatore di OpenAI, coniò un termine destinato a fare fortuna: vibe coding. Con questa espressione descriveva un modo di sviluppare software in cui il programmatore si limita a descrivere in linguaggio naturale ciò che vuole ottenere, lasciando che sia un modello di intelligenza artificiale a scrivere il codice accettando le modifiche proposte senza nemmeno leggerle, “abbandonandosi alle vibrazioni” e dimenticando, di fatto, che il codice esista.
Quella che Karpathy presentava come una pratica adatta a progetti personali e prototipi usa-e-getta è diventata, in poco più di un anno, un approccio mainstream allo sviluppo software. Già nell’estate del 2025 il Wall Street Journal documentava l’adozione del vibe coding da parte di ingegneri professionisti per casi d’uso commerciali. Il fenomeno non riguarda più soltanto startup e sviluppatori improvvisati: interi prodotti nascono oggi da codebase quasi interamente generate dall’AI.
L’adozione: numeri e legittimazione culturale
I numeri fotografano una trasformazione epocale. Secondo le stime di Gartner, entro il 2026 oltre il 60% del codice sviluppato nelle aziende sarà generato dall’intelligenza artificiale. GitHub Copilot scrive già circa il 46% del codice medio di uno sviluppatore che lo utilizza. Le piattaforme di vibe coding: da Lovable a Replit, da Cursor agli strumenti agentici integrati negli IDE, hanno raggiunto valutazioni miliardarie e una diffusione capillare.
La legittimazione culturale è arrivata dall’alto: a inizio 2026 persino Linus Torvalds, creatore di Linux e simbolo dell’artigianato del software, ha dichiarato di aver realizzato in vibe coding un tool di visualizzazione per un suo progetto personale, scrivendolo esplicitamente nel README. Quando il fenomeno tocca le colonne portanti della cultura open source, non è più una moda: è un cambio di paradigma.
I benefici sono reali
Sarebbe un errore liquidare il vibe coding come una scorciatoia per pigri. I vantaggi di produttività sono concreti e documentati: riduzione nell’ordine del 40% del time-to-market, prototipazione in giorni anziché mesi, possibilità di testare più idee a costi ridotti.
C’è poi una dimensione di democratizzazione che merita attenzione: professionisti privi di formazione tecnica: medici, avvocati, piccoli imprenditori, possono oggi costruire applicazioni funzionanti descrivendole a parole. L’abbassamento della barriera d’ingresso alla programmazione è un fatto storico, paragonabile per portata all’avvento del foglio di calcolo, che trasformò milioni di impiegati in “programmatori inconsapevoli” di modelli finanziari.
Il punto, dunque, non è se il vibe coding funzioni come leva di produttività: funziona. Il punto è cosa accade quando un output plausibile viene scambiato per un output affidabile.
Il rovescio della medaglia: i dati sulla qualità
Le prime analisi sistematiche sul codice generato dall’AI restituiscono un quadro preoccupante. Un’analisi condotta da CodeRabbit a fine 2025 su 470 pull request open source ha rilevato che il codice co-generato dall’AI contiene circa 1,7 volte più problemi “major” rispetto a quello scritto da umani, con vulnerabilità di sicurezza 2,74 volte più frequenti, oltre a tassi elevati di errori logici e misconfigurazioni.
Ancora più eloquente lo studio di Escape.tech, che ha scansionato 5.600 applicazioni pubblicamente accessibili costruite con piattaforme di vibe coding: oltre 2.000 vulnerabilità ad alto impatto e 400 segreti esposti:chiavi API e credenziali lasciate nel codice. In sintesi: circa un’app su tre costruita con strumenti AI è arrivata online con una falla seria, sfruttabile da chiunque.
Il nodo concettuale è che il vibe coding separa il costruire dal comprendere. Il codice che “gira” e il codice sicuro sono due cose diverse, e chi si limita a scrivere prompt spesso non sa riconoscere la differenza. Le vulnerabilità introdotte non sono nemmeno nuove: sono i grandi classici della OWASP Top 10: injection, autenticazione debole, segreti hardcoded, riprodotti però a una velocità che nessun processo di revisione tradizionale riesce a seguire. La pull request era un punto di controllo perché un essere umano la leggeva; al ritmo del vibe coding, nessuno la legge più per intero.
Gli effetti sistemici: open source sotto pressione
Gli effetti del fenomeno non si fermano al perimetro aziendale. Un paper accademico pubblicato a gennaio 2026, dal titolo provocatorio “Vibe Coding Kills Open Source”, sostiene che la diffusione del vibe coding stia erodendo l’ecosistema del software libero: i modelli linguistici gravitano verso le librerie più grandi e consolidate presenti nei loro dati di addestramento, omogeneizzando le scelte tecnologiche e rendendo quasi invisibili i progetti emergenti. E, a differenza degli sviluppatori umani, non segnalano bug ai manutentori né contribuiscono alle community.
Nel frattempo, i manutentori vengono travolti dal problema opposto: una marea di contributi e segnalazioni generate dall’AI di bassa qualità. GitHub ha descritto il fenomeno come un “Eternal September” dell’open source; il progetto cURL ha dovuto chiudere il proprio bug bounty program, soffocato dalle segnalazioni di sicurezza generate artificialmente. Il caso rsync, con utenti in rivolta dopo aver scoperto decine di commit firmati dall’AI in un software critico per le infrastrutture di backup di mezzo mondo, ha mostrato quanto la fiducia nella filiera del software libero sia diventata fragile.
Gli ingegneri Mario Zechner e Armin Ronacher hanno parlato di una crisi imminente di “vibe slop”: le aziende starebbero barattando produttività di breve periodo con problemi di lungo periodo: software instabile, interruzioni di servizio, vulnerabilità e debito tecnico crescente. È la definizione stessa di esternalità: la velocità non riduce il costo del software, lo sposta in avanti, dove si ripresenta sotto forma di incidente, data leak o manutenzione correttiva.
La risposta istituzionale e il nodo europeo
Le istituzioni hanno iniziato a muoversi. Al forum RSAC del marzo 2026, il direttore esecutivo del National Cyber Security Centre britannico, Richard Horne, ha definito il vibe coding una finestra temporale cruciale per la sicurezza informatica, invitando la comunità a modellare il cambiamento con criteri tecnici e normativi chiari anziché limitarsi a osservarlo. Le indicazioni operative: modelli addestrati secondo principi di security-by-design, tracciabilità della provenienza dei dataset, revisione, automatica e umana, del codice generato, aggiornamento continuo dei modelli di minaccia.
Ma è nel quadro normativo europeo che il tema diventa dirimente per le imprese italiane. Il Cyber Resilience Act impone ai produttori di software requisiti di sicurezza lungo tutto il ciclo di vita del prodotto, obblighi di gestione delle vulnerabilità e responsabilità documentali (a partire dalla SBOM, la distinta base del software). La nuova direttiva sulla responsabilità da prodotto difettoso estende esplicitamente al software la responsabilità civile del produttore. E l’AI Act aggiunge obblighi di trasparenza e governance per chi impiega sistemi di intelligenza artificiale nei processi produttivi.
La combinazione è potenzialmente esplosiva: un’azienda che rilascia in produzione codice generato dall’AI, non revisionato e vulnerabile, non sta solo accumulando debito tecnico, sta accumulando responsabilità giuridica. “Non sapevo cosa avesse scritto l’AI” non è una difesa: è un’ammissione di colpa organizzativa.
I cinque passi per attivare il vibe coding in modo sicuro
Come può, allora, un’azienda cogliere i benefici del vibe coding? Cinque passi, in sequenza logica: governance, supply chain, automazione, supervisione, persone.
Definire una policy d’uso e un perimetro
Prima ancora degli strumenti, servono le regole: quali tool sono autorizzati, su quali progetti, con quali dati. Va vietato l’inserimento di codice proprietario o dati sensibili nei prompt in assenza di garanzie contrattuali sul trattamento. E vanno adottati prompt di sistema a livello organizzativo, che impongano controlli e standard di sicurezza a ogni generazione di codice, indipendentemente da chi la richiede.
Presidiare la supply chain del software
OWASP colloca le vulnerabilità di supply chain tra i rischi principali dell’integrazione degli LLM nello sviluppo: modelli, librerie, plugin e dipendenze suggerite dall’AI entrano nel perimetro aziendale spesso senza alcuna verifica, allargando la superficie d’attacco senza che nessuno ne abbia reale percezione. Serve tracciabilità: SBOM obbligatoria anche, anzi, soprattutto, per il codice generato, e verifica sistematica delle dipendenze proposte dal modello.
Controlli automatici in pipeline
Se nessun umano può più leggere tutto il codice, i controlli devono diventare strutturali: gate SAST nella pipeline CI/CD che bloccano i rilevamenti ad alta severità, scanner di segreti, generazione automatica di test, fuzzing. La regola operativa è una sola: nessun codice generato dall’AI arriva in produzione senza scansioni di sicurezza automatizzate, e ogni codebase generata va presunta vulnerabile fino a prova contraria.
Human-in-the-loop dove conta
La revisione umana integrale è morta per stanchezza; quella selettiva è più viva che mai. Occorre definire le zone critiche: autenticazione, pagamenti, trattamento di dati personali, logica di business sensibile; dove la review umana e la firma di un responsabile restano vincolanti. Non è solo buona ingegneria: è la costruzione della catena di accountability che il Cyber Resilience Act e la direttiva sulla responsabilità da prodotto presuppongono.
Formazione e ownership
L’ultimo passo riguarda le persone. I team devono sviluppare una doppia competenza: comprendere il funzionamento (e i limiti) dei modelli generativi e padroneggiare le tecniche di verifica del codice generato. Sviluppatori e security officer devono collaborare nella definizione di limiti operativi e procedure di audit. E ogni modulo generato deve avere un owner umano identificato: il codice “orfano”: quello che nessuno ha scritto e nessuno capisce, è il primo candidato a diventare l’incidente di domani.
Dal vibe coding all’ingegneria agentica
Il vibe coding non si può fermare, e probabilmente non avrebbe senso provarci: i guadagni di produttività sono troppo rilevanti e la tecnologia continua a migliorare. La direzione più promettente è quella che alcuni chiamano agentic engineering: agenti AI che scrivono, testano e revisionano codice, ma dentro un quadro di supervisione umana strutturata mantenendo la velocità, recuperando il controllo.
La vera questione, insomma, non è tecnologica ma organizzativa e normativa. La storia del software insegna che il costo dell’assenza di controlli non è ipotetico: nel 2012 Knight Capital perse 460 milioni di dollari in 45 minuti per un frammento di codice dismesso e mai disattivato. Il vibe coding moltiplica per ordini di grandezza la quantità di codice che entra in produzione senza essere compreso da nessuno. Le aziende che sapranno reinvestire una parte del tempo risparmiato in validazione, governance e competenze trasformeranno il vibe coding in vantaggio competitivo durevole. Le altre scopriranno che il conto della velocità, prima o poi, arriva e con il Cyber Resilience Act arriverà anche con gli interessi.
Partecipa alla community