L’intelligenza artificiale sta abbassando rapidamente una delle barriere che, fino a pochi anni fa, separavano un’idea dalla possibilità di trasformarla in un prodotto digitale. Attraverso il cosiddetto vibe coding, oggi è possibile descrivere in linguaggio naturale ciò che vogliamo realizzare e lasciare che strumenti e agenti AI generino interfacce, database, sistemi di autenticazione, API, integrazioni e una parte sempre più consistente della logica applicativa.
È una possibilità straordinaria, perché permette di sperimentare idee con tempi e investimenti molto inferiori rispetto al passato, rendendo accessibili capacità che prima richiedevano necessariamente competenze specialistiche.
Proprio mentre questa barriera si abbassa, però, ne emerge un’altra molto meno evidente: se non conosciamo il codice generato dall’AI, come possiamo stabilire che sia anche sicuro?
Il problema non riguarda necessariamente ciò che vediamo quando utilizziamo il prodotto, ma tutto quello che può accadere senza produrre un errore immediatamente riconoscibile.
Cos’è il vibe coding e perché la sicurezza diventa un problema
Il termine vibe coding viene utilizzato per descrivere un approccio allo sviluppo nel quale interagiamo principalmente con un modello attraverso il linguaggio naturale, lasciando che sia l’AI a occuparsi della generazione e della modifica del codice.
Martin Fowler propone una distinzione particolarmente utile: nel vibe coding possiamo arrivare a costruire un’applicazione continuando a chiedere modifiche all’LLM senza leggere necessariamente il codice che viene prodotto. Proprio questa caratteristica permette anche a persone senza conoscenze di programmazione di costruire software, ma introduce problemi potenziali relativi a correttezza, manutenibilità e sicurezza.
Non significa che utilizzare l’AI per programmare equivalga automaticamente a fare vibe coding, né che ogni applicazione costruita in questo modo sia vulnerabile. Il problema emerge soprattutto quando la capacità dell’AI di produrre il software supera quella dell’utilizzatore di comprenderlo e verificarlo.
Ed è qui che la sicurezza diventa particolarmente interessante.
Un software che funziona non è necessariamente un software sicuro
Immaginiamo di utilizzare un agente AI per costruire un piccolo SaaS. Gli descriviamo il prodotto e gli chiediamo di realizzare registrazione degli utenti, autenticazione, database, area riservata e sistema di pagamento; dopo diverse iterazioni, arriviamo a una versione apparentemente completa.
Iniziamo quindi a provarla: creiamo un account, effettuiamo il login, inseriamo alcuni dati, utilizziamo le diverse funzionalità e completiamo correttamente un pagamento. Tutto si comporta esattamente come avevamo richiesto e, non essendoci errori evidenti, potremmo ragionevolmente concludere che il prodotto funzioni.
Abbiamo, però, verificato soprattutto ciò che siamo in grado di osservare.
Non sappiamo necessariamente se un utente possa accedere ai dati appartenenti a un altro account, se le autorizzazioni siano applicate correttamente lato server, se determinati endpoint espongano informazioni che dovrebbero rimanere private oppure se credenziali, chiavi e configurazioni siano state protette adeguatamente.
Una vulnerabilità, infatti, non deve necessariamente impedire all’applicazione di funzionare. Il software può continuare a comportarsi esattamente come previsto mentre contiene un problema che diventerà evidente soltanto quando qualcuno proverà deliberatamente a utilizzarlo in un modo diverso da quello per cui è stato progettato.
La distinzione fondamentale è quindi questa: verificare che un prodotto faccia ciò che dovrebbe fare non significa aver verificato che non possa fare ciò che non dovrebbe fare.
Quali sono i rischi di sicurezza del vibe coding?
Le vulnerabilità che possono interessare il codice generato dall’AI non appartengono necessariamente a una nuova categoria: ritroviamo problemi già conosciuti nella sicurezza applicativa, ma il modo in cui il software viene generato e soprattutto verificato può modificarne il profilo di rischio.
Tra i problemi osservati nelle analisi recenti troviamo esposizione di segreti e credenziali, input non adeguatamente filtrati, controlli di accesso insufficienti, dipendenze non verificate e configurazioni non sicure. Una ricerca del 2026 condotta su applicazioni sviluppate attraverso vibe coding ha individuato, tra i pattern ricorrenti, proprio esposizione di segreti, input non filtrati e logiche placeholder, collegandoli anche a limiti degli agenti come perdita del contesto e ottimizzazione locale delle richieste.
IBM evidenzia analogamente rischi relativi a chiavi API e password inserite direttamente nel codice, SQL injection, API non protette, privilegi eccessivi, autenticazione inadeguata e utilizzo di librerie vulnerabili.
Il punto, ancora una volta, non è che l’AI inventi necessariamente nuove vulnerabilità, ma che la velocità con cui possiamo produrre software rischia di superare la capacità con cui riusciamo a controllarlo.
Codice generato dall’AI: quanto è realmente sicuro?
La ricerca su questo tema è ancora in evoluzione e i risultati dipendono fortemente da modello, prompt, linguaggio, tipo di applicazione e metodologia utilizzata; sarebbe quindi scorretto trasformare un singolo studio in una percentuale universale sulla sicurezza del codice generato dall’AI.
Le evidenze disponibili sono comunque sufficienti per mettere in discussione l’equivalenza tra correttezza funzionale e sicurezza.
Uno studio del 2025 ha costruito un benchmark composto da 200 task derivati da richieste reali di progetti open source. In una delle configurazioni analizzate, il 61% delle soluzioni generate risultava funzionalmente corretto, mentre soltanto il 10,5% soddisfaceva i criteri di sicurezza del benchmark. È un risultato relativo a uno scenario sperimentale specifico, non una misura universale del codice AI, ma rende evidente quanto le due dimensioni possano divergere.
Un altro studio pubblicato nell’agosto 2026 ha confrontato applicazioni generate con prompt normali e versioni degli stessi prompt contenenti requisiti espliciti di sicurezza. Nei dodici programmi analizzati, le versioni security-aware hanno prodotto 24 finding confermati contro i 51 delle versioni baseline; gli stessi autori sottolineano però che il campione è ancora troppo piccolo per generalizzare i risultati.
È interessante perché suggerisce anche qualcosa di positivo: la sicurezza del software generato dall’AI non è necessariamente un limite immutabile e può migliorare quando sicurezza, controlli e requisiti entrano esplicitamente nel processo di sviluppo.
Il vero problema potrebbe essere la capacità di verifica
Consideriamo due persone che utilizzano lo stesso modello per generare la stessa funzione.
La prima è uno sviluppatore con esperienza, che può leggere il codice prodotto, comprenderne la logica, riconoscere comportamenti sospetti, modificarlo e sottoporlo agli strumenti e ai processi di verifica necessari. L’AI aumenta enormemente la velocità dell’esecuzione, mentre le competenze dello sviluppatore mantengono un livello di controllo sul risultato.
La seconda persona non possiede conoscenze di programmazione e, grazie all’AI, riesce comunque a ottenere la stessa funzione. Se compare un errore può copiarlo nella conversazione, descrivere ciò che non funziona e chiedere al modello di correggerlo, continuando così lo sviluppo senza necessariamente comprendere ciò che accade sotto la superficie.
La differenza più importante emerge quando il software funziona, perché, se non compare alcun errore e tutte le funzionalità visibili si comportano come previsto, come può sapere che esiste qualcosa da controllare?
È qui che vedo una delle conseguenze più interessanti del vibe coding: l’AI sta riducendo enormemente la competenza necessaria per ottenere un risultato, ma non necessariamente quella necessaria per valutarlo.
In altre parole, sta separando due capacità che in passato erano molto più strettamente collegate: costruire un prodotto e comprendere abbastanza quel prodotto da poterlo validare.
L’AI può controllare il codice che ha generato?
Sì, e sarebbe sbagliato ignorare questa possibilità. Gli stessi strumenti possono essere utilizzati per analizzare il codice, individuare possibili vulnerabilità, controllare autenticazione e autorizzazioni, verificare la gestione degli input, analizzare dipendenze e configurazioni oppure suggerire test e correzioni.
Il problema nasce quando consideriamo questa possibilità equivalente a una garanzia.
Se una persona non possiede le competenze necessarie per valutare né il codice generato né l’analisi di sicurezza effettuata successivamente dall’AI, può verificarsi una situazione particolare: lo stesso paradigma tecnologico contribuisce a costruire il prodotto, viene utilizzato per stabilire se sia sicuro e, dall’altra parte, nessuno possiede gli strumenti necessari per capire se quella verifica sia stata sufficiente.
L’AI può quindi rappresentare uno dei livelli di controllo, ma la sicurezza di un’applicazione destinata alla produzione dovrebbe dipendere dal rischio effettivo e prevedere, quando necessario, ulteriori verifiche attraverso code review, test, analisi delle dipendenze e strumenti specifici di application security.
Vibe coding: prototipo e produzione non sono la stessa cosa
È probabilmente questa la distinzione più importante per un imprenditore.
Se utilizziamo l’AI per trasformare rapidamente un’idea in un prototipo, sperimentare un’interfaccia, verificare un workflow o costruire una demo, la riduzione della barriera tecnica rappresenta un vantaggio straordinario. Possiamo imparare più velocemente, investire meno nella fase iniziale e verificare alcune ipotesi prima di destinare risorse significative allo sviluppo.
Una review della letteratura pubblicata nel 2026 arriva a una conclusione compatibile con questa distinzione: le evidenze sui benefici del vibe coding risultano più solide per prototipazione e interfacce, mentre sono ancora più limitate per applicazioni destinate alla produzione, data-intensive e safety-critical.
La situazione cambia quando quello stesso prototipo deve iniziare a gestire account reali, dati personali, informazioni aziendali, pagamenti o processi critici. Da quel momento, una vulnerabilità non riguarda più soltanto il codice, perché le conseguenze entrano direttamente nel business.
Per questo il confine più utile non è quello tra software sviluppato da un essere umano e software sviluppato dall’AI. Con l’ingresso sempre più profondo degli strumenti AI nei normali processi di sviluppo, questa distinzione diventerà probabilmente sempre meno significativa.
La distinzione realmente importante sarà tra software sottoposto a verifiche adeguate al proprio livello di rischio e software portato in produzione semplicemente perché sembra funzionare.
Il problema non è sviluppare software con l’AI
Dire che chi non conosce la programmazione non dovrebbe utilizzare l’AI per sviluppare significherebbe ignorare una delle trasformazioni più interessanti introdotte da questa tecnologia.
Un imprenditore può oggi trasformare un’idea in un prototipo senza investire immediatamente migliaia di euro, un professionista può costruire piccoli strumenti per migliorare il proprio lavoro e un’azienda può sperimentare soluzioni che fino a pochi anni fa avrebbero richiesto tempi e risorse molto maggiori.
La domanda non dovrebbe quindi essere «è giusto sviluppare software con l’AI?», perché rischia di portarci verso una contrapposizione destinata a diventare sempre meno interessante.
Dovremmo chiederci qualcosa di diverso: quali rischi comporta ciò che stiamo costruendo e quali competenze o verifiche sono necessarie prima di metterlo in produzione?
Se stiamo realizzando una demo per validare un’idea, la risposta sarà una; se stiamo costruendo un’applicazione che gestisce dati personali, informazioni finanziarie, pagamenti o processi aziendali critici, sarà inevitabilmente diversa.
La tecnologia viene dopo la valutazione del contesto, del rischio e delle conseguenze, esattamente come dovrebbe accadere per qualsiasi altra decisione digitale. Questo mantiene l’articolo perfettamente dentro il principio Business First che abbiamo definito per il brand.
La vera sfida del vibe coding sarà imparare a verificare
Per molto tempo esisteva una barriera piuttosto semplice: se non sapevi programmare, difficilmente riuscivi a costruire autonomamente un’applicazione complessa. Quella barriera sta rapidamente scomparendo e considero questo cambiamento positivo, perché permette a molte più persone di trasformare le proprie idee in qualcosa di concreto.
Dobbiamo, però, evitare che la facilità di costruzione generi una falsa equivalenza tra «sono riuscito a realizzarlo» e «sono in grado di portarlo responsabilmente in produzione».
Più l’AI diventerà capace di occuparsi dell’esecuzione, più diventeranno importanti la capacità di definire ciò che deve essere controllato, la consapevolezza dei rischi e il giudizio necessario per capire quando il livello di verifica raggiunto sia sufficiente.
Perché il vero rischio del vibe coding non è che l’AI scriva necessariamente codice sbagliato, ma che nessuno sappia riconoscerlo quando lo fa.