Guida
Il vibe coding è un male? Cosa va storto e come controllare il codice
Il vibe coding non è un male di per sé: il rischio è rilasciare codice che nessuno ha letto. Gli errori ricorrenti degli assistenti AI, quando contano e come scovarli.
· 7 min di lettura · A cura del team vetkit
La risposta breve
No, il vibe coding non è un male di per sé. È un modo rapido per ottenere software funzionante e, per prototipi, strumenti interni e apprendimento, spesso è la scelta giusta. Diventa un problema in un punto preciso: quando codice che nessuno ha letto inizia a gestire utenti reali, dati reali o denaro reale. Il rischio non è che il codice l’abbia scritto un’AI. Il rischio è che nessuno lo abbia controllato.
Quindi la domanda utile non è “il vibe coding è un male?”, ma “cosa devo controllare prima che vada in produzione?”. Il resto di questa guida risponde proprio a questo.
Cosa significa vibe coding
Vibe coding significa sviluppare software descrivendo a un assistente AI ciò che si vuole e accettando il codice che scrive, per lo più senza leggerlo. Il termine è stato coniato da Andrej Karpathy all’inizio del 2025 per indicare un modo di lavorare in cui ci si abbandona alle vibrazioni e si dimentica perfino che il codice esista. Il risultato si giudica eseguendo l’app, non rivedendo le modifiche.
È una cosa diversa dallo sviluppo assistito dall’AI, in cui uno sviluppatore usa gli stessi strumenti ma continua a leggere, testare e assumersi la responsabilità di ogni modifica. La maggior parte dei progetti reali sta da qualche parte tra i due e scivola verso il vibe coding quando le scadenze si fanno strette.
Cosa va storto
Gli assistenti AI sono bravi a produrre codice che gira. Sono meno affidabili su tutto ciò che non emerge quando si prova l’app una volta sola. Gli stessi errori si ripresentano di continuo:
| Problema | Come si presenta | Perché non te ne accorgi |
|---|---|---|
| Segreti nel posto sbagliato | Una chiave API committata nel repository o distribuita nel bundle del browser | L’app funziona esattamente allo stesso modo in entrambi i casi |
| Controlli di accesso mancanti | Qualsiasi utente autenticato può leggere i record di un altro utente; tabelle del database senza regole a livello di riga | Fai i test sempre e solo con il tuo account |
| Pacchetti che non esistono | L’assistente inventa un nome di pacchetto plausibile, e qualcun altro potrebbe averlo registrato | Il comando di installazione va a buon fine |
| Codice incompleto | Funzioni segnaposto, rami TODO ed errori ignorati lasciati nel percorso principale | Il percorso felice funziona comunque |
| Input non attendibile usato direttamente | Dati della richiesta inseriti in query SQL, comandi di shell, percorsi di file o HTML | Con input normali tutto si comporta normalmente |
| Nessuna gestione dei guasti | Chiamate HTTP senza timeout, query dentro i cicli, nessuna segnalazione degli errori | Con dieci righe e un utente è veloce |
Niente di tutto questo è nuovo. Gli sviluppatori commettevano ciascuno di questi errori ben prima che esistessero gli assistenti AI. Con il vibe coding cambiano il volume e l’assenza della revisione: arriva più codice, più in fretta, e la persona che avrebbe individuato il problema non lo legge mai. Tre di questi temi sono trattati in dettaglio altrove su questo sito: chiavi API nel browser, pacchetti inventati e segreti esposti.
Quando conta e quando no
Il vibe coding è una scelta ragionevole quando un errore costa poco:
- Un prototipo o una demo che verrà buttata o riscritta.
- Uno script personale o uno strumento interno senza dati sensibili.
- Imparare un nuovo framework o esplorare un’idea.
Richiede un controllo prima del rilascio quando un errore costa caro:
- L’app gestisce account utente, pagamenti o dati personali.
- Contiene credenziali per altri servizi, come un provider LLM o un database.
- Altre persone dipenderanno dalla sua disponibilità, oppure qualcun altro dovrà manutenerla.
Il confine non è il modo in cui il codice è stato scritto, ma ciò che succede se il codice è sbagliato. Molti progetti superano quel confine senza che nessuno lo decida: la demo ottiene i primi utenti reali e nessuno torna indietro a leggerla.
Come mantenere la velocità ed eliminare il rischio
Non devi rinunciare alla velocità. Devi reintrodurre il controllo che il vibe coding salta.
- Leggi le modifiche che toccano denaro, login e dati. Puoi evitare di leggere il codice del layout. Non puoi saltare autenticazione, autorizzazione, pagamenti e tutto ciò che scrive nel database. La checklist per la revisione del codice generato dall’AI elenca cosa cercare.
- Fai i test con due account. Accedi come un utente e prova a leggere o modificare i record di un altro. Questo singolo test individua la classe di bug più dannosa nelle app sviluppate con il vibe coding.
- Verifica ogni nuova dipendenza. Conferma che il pacchetto esista, che sia quello che intendevi e che non sia stato pubblicato la settimana scorsa.
- Scansiona il repository prima del rilascio. Un audit automatico trova i problemi meccanici più in fretta di una persona: segreti committati, dipendenze vulnerabili o inesistenti, timeout mancanti e gestione non sicura dell’input. Il catalogo dei controlli di vetkit mostra le regole che esegue, e il Security Quick Scan gratuito copre segreti, vulnerabilità note delle dipendenze e postura di sicurezza di base.
- Chiedi all’assistente di correggere ciò che trova la scansione. Collega lo scanner al tuo coding agent, così i risultati tornano nella stessa conversazione. La guida MCP spiega come fare.
Quando sei pronto al rilascio, la checklist di sicurezza prima di rilasciare un’app sviluppata con il vibe coding ti guida passo passo nella decisione di rilascio.
Fonti e limiti
L’elenco dei problemi comuni riflette le categorie coperte dalle regole proprietarie di vetkit per rischi del codice AI, sicurezza, resilienza e accesso ai dati, verificate il 10 novembre 2026. È una descrizione di schemi ricorrenti, non una misura della loro frequenza. Il termine “vibe coding” viene dal post di Andrej Karpathy del febbraio 2025.
Una scansione automatica è materiale da rivedere, non la prova che un’app sia sicura. Legge il codice sorgente; non testa i permessi in produzione, la configurazione dell’hosting né le regole di business. Il test con due account e la revisione manuale descritti sopra restano compito tuo.