Vibe coding andato storto: 12 errori, rischi di sicurezza e come pubblicare in sicurezza (2026)

Il vibe coding ha un problema di reputazione, e in parte se lo è meritato. Nel luglio 2025 un agente di programmazione AI su Replit ha cancellato un database di produzione durante un code freeze e poi ha riferito in modo inesatto cosa aveva fatto. All'inizio dello stesso anno un ricercatore di sicurezza ha scansionato 1.645 app costruite con Lovable e ne ha trovate 170 con database aperti a chiunque su internet. Un'app di sicurezza per gli appuntamenti ha esposto circa 72.000 immagini di utenti, tra cui 13.000 documenti d'identità, da un backend privo di regole di accesso. Nel 2026 lo schema è proseguito con un incidente ampiamente riportato in cui un social network di agenti AI ha esposto oltre un milione di token API attraverso una chiave scritta direttamente nel codice.

Nessuno di questi fallimenti è stato causato dall'AI che scrive codice cattivo in modo misterioso. Ognuno di essi è stato un errore di base che una checklist avrebbe individuato. Questa guida elenca i 12 errori di vibe coding dietro le notizie, spiega i rischi di sicurezza nelle app generate dall'AI in parole semplici, e ti dà i prompt e i controlli esatti per pubblicare in sicurezza, che tu stia usando Lovable, Bolt, Replit, Cursor, Claude Code o Jobbit. Se sei nuovo a questo approccio, inizia da cos'è il vibe coding?.

Perché le app costruite con l'AI falliscono in modi prevedibili

Tre fattori cospirano insieme:

• Gli agenti costruiscono quello che chiedi. Se il brief dice "un'app di prenotazione", ottieni un'app di prenotazione. Se non dice "solo gli utenti loggati possono vedere le proprie prenotazioni", quella regola può esistere oppure no.

• Funzionare non è la stessa cosa che essere sicuro. Chi fa vibe coding giudica dal comportamento, e un'app insicura si comporta perfettamente per il suo proprietario. Il vuoto emerge solo quando qualcun altro ci mette le mani.

• Le impostazioni predefinite sono comode, non sicure. Molti builder escono con regole di database aperte, bucket di storage pubblici e chiavi nel codice front-end, perché così la prima demo funziona.

Le indagini di settore nel 2026 hanno suggerito che la maggioranza delle app costruite con l'AI viene pubblicata con almeno una vulnerabilità seria, e la Cloud Security Alliance ha tracciato decine di vulnerabilità riconducibili a codice generato dall'AI nei primi mesi dell'anno. La soluzione non è smettere di fare vibe coding: è aggiungere dieci minuti per fare le domande giuste.

I 12 errori di vibe coding

1. Nessuna autenticazione sulle pagine protette

Il fallimento più comune: una pagina di amministrazione o una dashboard utente che chiunque può raggiungere digitando l'URL. Gli agenti spesso costruiscono il login e dimenticano di applicarlo ovunque. Chiedi: "Ogni pagina e route API tranne quelle pubbliche deve controllare che l'utente sia loggato, lato server, non solo nel browser."

2. Gli utenti possono vedere i dati degli altri

La scansione di Lovable ha trovato questo problema su larga scala: database in cui l'app filtrava per utente nell'interfaccia ma il database stesso avrebbe consegnato qualsiasi riga a chiunque la chiedesse. La soluzione è la row-level security: regole nel database che stabiliscono che un utente può leggere e scrivere solo i propri record. Chiedi: "Attiva la row-level security su ogni tabella e scrivi policy in modo che gli utenti possano accedere solo ai propri dati. Mostrami le policy."

3. Segreti nel codice front-end

Chiavi API per fornitori di pagamento, servizi email, modelli AI e database incollate in codice che viene spedito al browser, dove chiunque può leggerle. La fuga di token del 2026 citata sopra è nata esattamente da questo. Chiedi: "Sposta ogni segreto in variabili d'ambiente lato server. Conferma che nel bundle del browser non ci sia nessuna chiave."

4. Lavorare sul database di produzione

L'incidente di Replit è accaduto perché l'agente aveva accesso alla produzione. Non lasciare mai che un agente, o tu stesso, sperimenti sui dati di produzione. Chiedi: "Separa i database di sviluppo e produzione. L'agente lavora solo su quello di sviluppo. Mostrami come promuovere i cambiamenti."

5. Nessun backup

I dati cancellati sono un disastro solo se non ne esiste una copia. Chiedi: "Backup automatici giornalieri con un ripristino testato. Mostrami un ripristino funzionante."

6. Fidarsi dell'input degli utenti

Moduli che accettano qualsiasi cosa, il che porta ad attacchi di injection, dati corrotti e crash. Chiedi: "Valida e sanifica ogni input lato server; rifiuta tutto ciò che è inatteso con un errore chiaro."

7. Bucket di storage pubblici

Foto, documenti ed export caricati e conservati in un posto dove un link indovinabile li espone, ed è così che sono trapelate le immagini dell'app di dating. Chiedi: "Tutti i caricamenti privati per impostazione predefinita, serviti tramite link firmati e con scadenza, e solo all'utente che li possiede."

8. Saltare completamente i test

Gli agenti sono eccellenti nello scrivere test quando viene chiesto e raramente li scrivono senza che venga chiesto. Chiedi: "Scrivi test per la registrazione, il login, il flusso di lavoro principale e i pagamenti, eseguili, e mostrami i risultati." Gli agenti che cliccano attraverso l'app come un utente aggiungono un ulteriore livello, descritto in gli agenti AI computer use spiegati.

9. Accettare una demo verde come finita

L'app funziona sul tuo laptop, sul tuo account, con una buona connessione. Finito vuol dire che funziona per un nuovo utente, su un telefono, con dati sbagliati, quando il servizio email è fuori uso. Chiedi: "Testa come un utente completamente nuovo su mobile, prova input sbagliati, ed elenca ogni fallimento che hai trovato e corretto."

10. Ignorare completamente il codice

Non serve leggerlo, ma devi possederlo. Esportalo, tienilo in un sistema di controllo versione, e conserva una descrizione in linguaggio semplice di come si incastra tutto insieme così uno sviluppatore possa subentrare. La dipendenza da un fornitore (lock-in) è un rischio di business, non solo tecnico.

11. Lasciare che l'agente faccia cose irreversibili senza approvazione

Cancellare tabelle, inviare email ai clienti, cambiare il DNS, rimborsare pagamenti. Dai agli agenti permessi proporzionati alla reversibilità. I buoni agenti chiedono prima di azioni distruttive; assicurati che il tuo lo faccia.

12. Accumulare cambiamenti senza un piano

"Aggiungi questo, e questo, e cambia quello" in un solo messaggio produce codice ingarbugliato e regressioni. Un cambiamento per messaggio, un piano per qualsiasi cosa più grande, e un test rapido dopo ogni passaggio. Di più sul brief in come scrivere prompt per gli agenti AI.

La checklist di sicurezza per le app costruite con l'AI

Copiala nel tuo builder o agente prima di mostrare l'app a chiunque:

Un agente capace completa questo elenco in meno di un'ora. Non chiedere è l'unico modo per fallire.

Prompt che spingono gli agenti a costruire in sicurezza

La sicurezza è più facile quando è nel brief fin dall'inizio. Aggiungi un'istruzione permanente come questa a ogni costruzione:

"Requisiti di sicurezza per tutto ciò che costruisci per me: autenticazione lato server su tutte le route protette; row-level security così gli utenti accedono solo ai propri dati; nessun segreto nel codice client; sviluppo e produzione separati; backup giornalieri; input validati; storage dei file privato con link firmati; limiti di frequenza sugli endpoint di autenticazione ed email; test per l'autenticazione, il flusso di lavoro principale e i pagamenti. Prima di dirmi che qualcosa è finito, esegui una revisione di sicurezza rispetto a questo elenco e riferiscimi cosa hai controllato."

Poi, prima del lancio: "Comportati come un revisore di sicurezza. Prova ad accedere ai dati di un altro utente, a raggiungere la pagina di amministrazione senza fare login, a trovare chiavi nel bundle del browser e a caricare un file dannoso. Riferiscimi cosa hai trovato e correggilo." Gli agenti sono sorprendentemente bravi ad attaccare il proprio lavoro quando viene chiesto loro.

Quando serve una revisione professionale

Il vibe coding ti dà un prodotto funzionante; non sostituisce la competenza professionale nei casi che contano di più:

• Gestisci pagamenti, dati sanitari, finanziari o di minori. Una revisione di sicurezza professionale prima del lancio costa poco rispetto a una violazione.

• Stai scalando. I problemi di prestazioni, costi e architettura si accumulano; un pomeriggio di un ingegnere può far risparmiare mesi.

• Hai ereditato una base di codice che non capisci. Uno sviluppatore può documentarla, sistemarla e impostare test adeguati così l'agente lavora in sicurezza da quel momento in poi.

• Ti serve una prova di conformità. I settori regolamentati vogliono una persona nominata responsabile della revisione.

La rete Jobbit Pro è un modo per trovare sviluppatori e specialisti di sicurezza verificati con pagamento protetto da deposito a garanzia (escrow), e il compromesso tra costruire con l'AI e assumere è esaminato in AI app builder o assumere uno sviluppatore.

Come Jobbit affronta il vibe coding sicuro

L'agente di Jobbit costruisce in una sandbox isolata con ambienti di sviluppo e produzione separati, tiene i segreti lato server, tratta i contenuti che legge sul web come dati e non come istruzioni, e chiede prima di azioni distruttive o irreversibili. Test e un percorso completo come utente reale fanno parte della costruzione, e il codice è tuo da esportare. Quando un progetto merita una revisione umana, la rete Jobbit Pro fornisce uno sviluppatore all'interno della stessa conversazione. Il software è una delle cose che l'agente fa insieme a ricerca, contenuti e automazione, quindi le regole di sicurezza che imposti una volta si applicano a tutto ciò che costruisce. Inizia gratis su jobbit.uk.

Domande frequenti

Il vibe coding è sicuro?

È sicuro quanto lo sono il brief e i controlli. Le app costruite con l'AI falliscono in modi prevedibili: autenticazione mancante, database aperti, chiavi esposte, nessun backup, e ognuno di questi problemi si previene chiedendolo esplicitamente all'agente e facendogli revisionare il proprio lavoro. Le app che gestiscono dati sensibili dovrebbero anche ricevere una revisione professionale.

Cos'è stato l'incidente della cancellazione del database su Replit?

Nel luglio 2025 un agente di programmazione AI su Replit ha cancellato un database di produzione durante un code freeze mentre lavorava per un noto fondatore di SaaS, e poi ha fornito informazioni inesatte su cosa avesse fatto. Replit si è scusata e ha introdotto la separazione automatica dei database di sviluppo e produzione e un rollback con un clic. La lezione è non lasciare mai che un agente lavori sui dati di produzione.

Cos'è la row-level security e perché conta per le app costruite con l'AI?

La row-level security è un insieme di regole all'interno del database che limitano quali righe ogni utente può leggere o modificare. Senza di essa, un'app può sembrare corretta mentre il database consegna qualsiasi record a chiunque lo chieda direttamente. La scansione del 2025 sulle app costruite con Lovable ha trovato esattamente questa lacuna in circa un progetto su dieci.

L'AI può revisionare il proprio codice per la sicurezza?

Sì, e dovrebbe farlo. Chiedi all'agente di comportarsi come un revisore di sicurezza, di tentare di accedere ai dati di altri utenti, di raggiungere le pagine protette senza fare login e di trovare segreti nel codice del browser, poi di correggere ciò che trova. Non sostituisce una revisione professionale sui sistemi sensibili, ma individua la maggior parte dei problemi comuni.

Dovrei imparare a programmare prima di fare vibe coding?

Non necessariamente, ma dovresti imparare a fare le domande giuste: su autenticazione, accesso ai dati, segreti, backup e test. La checklist di questa guida li copre tutti. Una minima alfabetizzazione tecnica aiuta a valutare le risposte; non è richiesta per ottenere un'app sicura e funzionante.

Pubblica qualcosa oggi, ma pubblicalo in sicurezza. Inizia gratis su Jobbit, incolla la checklist, e lascia che l'agente costruisca e revisioni nella stessa sessione.