Indice

• Da dove è nato il vibe coding?
• Perché così tanti team l'hanno adottato
• Codice funzionante e codice sicuro sono cose diverse
• Quattro incidenti, una sola causa
• Mantenere la velocità e reintrodurre la revisione

A luglio 2025 un'app ha lasciato aperto su internet un bucket di storage. Dentro c'erano i selfie e i documenti d'identità che le utenti avevano caricato per verificare il proprio account. Chiunque avesse l'URL poteva scaricarli. Circa 72.000 immagini sono state sottratte, tra cui circa 13.000 selfie e documenti di verifica. Il controllo degli accessi non era mai stato configurato, e l'app funzionava comunque senza problemi.

Quell'app era Tea. È uno dei quattro incidenti raccontati più avanti che risalgono alla stessa lacuna.

Da dove è nato il vibe coding?

Il 2 febbraio 2025 Andrej Karpathy, tra i fondatori di OpenAI ed ex responsabile dell'AI di Tesla, ha pubblicato su X una breve nota su un modo di lavorare che stava sperimentando. Si descrive a parole ciò che si vuole, si esegue qualunque cosa restituisca il modello e non ci si preoccupa del codice sottostante. Lo chiamò vibe coding, non sapeva ancora quello che tutto ciò avrebbe generato.

Il suo ambito era ristretto. Parlava di progetti da weekend, dove la posta in gioco è quasi nulla, e lui è un programmatore esperto che di aiuto non ha bisogno. Nel giro di un anno il termine è stato scelto come parola dell'anno da Collins e ha finito per indicare qualsiasi codice scritto con un LLM, compreso quello curato e rivisto. Simon Willison ha segnalato questa deriva a marzo 2025,sostenendo che dà un'idea sbagliata di come si fa programmazione assistita dall'AI fatta con responsabilità.

Oggi la stessa etichetta copre sia il giocattolo del weekend sia il servizio di pagamenti su cui gira un'azienda, e un'affermazione sulla sicurezza vale poco quando la parola significa entrambe le cose.

Perché così tanti team l'hanno adottato

Karpathy ha costruito in circa un'ora un'app iOS funzionante in Swift, senza alcuna esperienza precedente con il linguaggio, e molti altri lo hanno seguito. Secondo la survey di Stack Overflow, nel 2025, l'84% degli sviluppatori usa o prevede di usare strumenti di AI. Per prototipi e strumenti interni la velocità ripaga. I problemi arrivano quando la stessa abitudine incontra il codice che va in produzione.

Codice funzionante e codice sicuro sono cose diverse

Un modello viene addestrato a produrre codice che gira, e tratta la sicurezza come un aspetto secondario. Nel rapporto Veracode 2025, che ha coinvolto più di 100 modelli e 80 compiti di programmazione, i modelli hanno scelto l'opzione insicura nel 45% dei casi. Entrambe le versioni funzionano, e quella insicura è spesso il modello più frequente nei dati di addestramento. Chi rivede il codice senza competenze di sicurezza non vede la differenza.

Altri studi mostrano andamenti simili, con cifre diverse. CodeRabbit ha analizzato 470 pull request open source e ha rilevato che quelle co-firmate dall'AI contenevano in media circa 1,7 volte più problemi in totale e 2,74 volte più vulnerabilità di cross-site scripting. GitGuardian ha registrato 28,65 milioni di credenziali sensibili, chiavi API, password, URL di database e token privati scritti direttamente nel codice nei commit pubblici su GitHub nel 2025, il 34% in più rispetto all'anno precedente. Nello stesso rapporto, i commit co-firmati con Claude Code hanno fatto trapelare segreti nel 3,2% dei casi, contro una media di riferimento dell'1,5%.

Uno Studio di Stanford ha rilevato che chi usava assistenti AI scriveva codice meno sicuro nei compiti sensibili, pur essendo più convinto della sicurezza del proprio lavoro.

Anche i nomi dei pacchetti sono un punto debole. Uno studio presentato a USENIX Security 2025 ha generato 576.000 campioni di codice con 16 modelli: il 19,7% dei 2,23 milioni di pacchetti suggeriti non esisteva. Molti dei nomi inventati ricompaiono ripetendo lo stesso prompt, e questo consente agli autori di attacchi informatici di registrarli in anticipo e utilizzarli per insinuarsi nei sistemi, una tecnica nota come slopsquatting.

Anche sulla velocità c'è un divario tra percezione e misurazione. In uno studio randomizzato controllato di METR del 2025 (il paper completo è su arXiv), gli sviluppatori esperti che usavano l'AI hanno impiegato il 19% di tempo in più per completare i compiti, pur convinti di essere stati circa il 20% più veloci. Lo studio era piccolo, con 16 sviluppatori che lavoravano su codebase che conoscevano bene con strumenti dei primi mesi del 2025, quindi non descrive ogni team. Mostra però che la percezione della propria velocità può essere sbagliata, e i piani costruiti su quella percezione ereditano l'errore.

Quattro incidenti, una sola causa

A luglio 2025 l'agente AI di Replit (famosa piattaforma di Vibe Coding) ha cancellato il database di produzione dell'app di prova di Jason Lemkin, fondatore di SaaStr, nonostante un code freeze esplicito, facendo sparire i dati di circa 1.200 dirigenti e di quasi 1.200 aziende. L’agente di Replit gli ha detto che il ripristino era impossibile, ma non era vero. Il CEO dell’azienda ha definito l’episodio «inaccettabile» e Replit ha annunciato database separati per sviluppo e produzione.

Pochi giorni dopo la prima violazione di Tea (quella raccontata in apertura dell'articolo) , è emersa una seconda esposizione di oltre 1,1 milioni di messaggi privati , che ha portato a scatenare una class-action in California. A maggio 2025, la CVE-2025-48757 ha mostrato come app costruite con Lovable e Supabase siano state rilasciate senza row-level security, la regola che impedisce a un utente di leggere i dati di un altro. La falla ha riguardato 303 endpoint in 170 dei 1.645 progetti analizzati. All'inizio del 2026 Moltbook, un social network per agenti AI il cui fondatore ha dichiarato di averlo realizzato con il vibe coding, ha esposto circa 1,5 milioni di token di autenticazione API attraverso un database privo di row-level security, secondo i ricercatori di Wiz. ha esposto circa 1,5 milioni di token di autenticazione API through a database without row-level security, according to researchers at Wiz.

Ciascun caso si riduce a una misura di sicurezza di routine che un ingegnere esperto avrebbe aggiunto e che il modello ha omesso, perché il software funzionava lo stesso. Chi dava le istruzioni al modello non poteva accorgersi della lacuna, dato che riconoscerla è proprio la competenza che lo strumento doveva avere.

Mantenere la velocità e reintrodurre la revisione

Gli strumenti vanno tenuti. Dove non c'è nulla da perdere, il modello può andare libero. Dove ci sono dati reali e utenti reali, il codice generato va trattato come una prima bozza veloce che una persona legge e testa. Una breve checklist aiuta:

1. Decide the stakes before you start. A throwaway prototype and a service holding personal data call for different rules.
2. Tieni separati i database di anteprima, test e produzione. Così lo scenario peggiore viene eliminato alla radice.
3. Verifica esplicitamente i controlli di accesso. Partite dal presupposto che il modello non li abbia aggiunti: chiedetevi se un utente può leggere i dati di un altro e fate la prova.
4. Prima di ogni merge, lancia scansioni automatiche. Cercate credenziali scritte nel codice e pacchetti inesistenti.
5. Fai rivedere tutto ciò che è esposto agli utenti a una persona con competenze di sicurezza.
6. Conserva un registro indipendente delle modifiche. Il resoconto che lo strumento fa delle proprie azioni può essere sbagliato: l’agente di Replit ha descritto in modo errato sia la cancellazione sia il ripristino.

Neodata realizza sistemi di AI, forte di oltre vent'anni di ingegneria enterprise. Se il tuo team sta correndo con codice generato dall'AI e volete un secondo paio d'occhi su ciò che arriva in produzione, ne parliamo volentieri su neodatagroup.ai.