Apri Claude Code o Codex in una cartella vuota, gli dai il permesso di fare tutto da solo, scrivi “creami un sistema di prenotazioni con area clienti e pagamenti online” e vai a prenderti un caffè. Al ritorno trovi un’app che sembra completa. Con Lovable o Bolt succede lo stesso nel browser, e sempre più spesso a farlo è qualcuno in azienda, senza passare da uno sviluppatore.

Si chiama vibe coding. Per provare un’idea va benissimo. Per metterla in mano ai clienti, così com’è, no. In questo articolo trovi cos’è, dov’è il problema, gli errori più comuni e cosa fare prima di andare online.

In breve

Cos’è: farsi scrivere il codice dall’AI e pubblicarlo senza che nessuno lo controlli.

Dove va bene: prototipi, demo e strumenti interni senza dati dei clienti.

L’AI tende a scegliere la soluzione più comune e a riempire da sola quello che non le hai detto. Sotto una demo che funziona possono esserci falle di sicurezza e scelte che l’AI ha fatto al posto tuo.

Cosa serve: qualcuno con esperienza che controlli il lavoro prima che arrivi ai clienti. Se escono dati personali, ne rispondi prima di tutto tu.

Cos’è il vibe coding

Il vibe coding è un modo di creare software in cui descrivi a un’AI cosa vuoi, in linguaggio naturale, e accetti il codice che produce senza leggerlo. Il termine l’ha coniato Andrej Karpathy, tra i fondatori di OpenAI, il 2 febbraio 2025. Nella sua descrizione accetti tutte le modifiche e, parole sue, “dimentichi che il codice esiste” (Karpathy su X, traduzione nostra). Il significato è letterale. In inglese vibe vuol dire sensazione, e qui si programma a sensazione.

Si fa in due modi:

Con le piattaforme web (Lovable, Bolt, v0, Replit): scrivi una descrizione, la piattaforma genera l’app e la pubblica con un clic.
Con gli agenti di programmazione (Claude Code, Codex, Cursor): lavorano sul tuo computer o in cloud, creano i file, installano librerie, cioè codice scritto da altri, e lanciano comandi. Di serie chiedono conferma prima delle operazioni più delicate. In modalità automatica procedono quasi da soli, partendo da un solo prompt, cioè una sola richiesta scritta.

Lo strumento può essere lo stesso. Cambia chi controlla il risultato:

Chi fa cosa	Sviluppo assistito dall’AI	Vibe coding
Chi scrive il codice	L’AI	L’AI
Chi lo controlla e lo prova	Una persona competente	Nessuno
Chi risponde del risultato	Chi lo ha approvato	Tu, senza averlo visto

Allo sviluppo assistito dall’AI abbiamo dedicato un articolo a parte.

Il problema: parte benissimo, poi si inceppa

Il primo prompt sembra magia. Poi, con il passare delle ore, compaiono funzioni doppie e correzioni che rompono qualcos’altro. Un prompt più lungo o una chat nuova aiutano per un po’, poi il problema torna. Le cause sono cinque.

L’AI non conosce la tua azienda. Propone il modo più diffuso di fare una cosa, pensato per un’azienda qualsiasi. Dei tuoi clienti e delle tue regole sa solo quello che le hai scritto o che trova nei file. È come un collaboratore molto capace arrivato stamattina.
Quello che non scrivi lo decide lei. Dentro un “aggiungi il carrello” ci sono molte decisioni che non vedrai mai: quali dati salvare, cosa succede se il pagamento fallisce, dove ospitare l’app. L’AI sceglie, quasi sempre senza chiedertelo, e siccome il risultato gira niente sembra sbagliato.
Più la chat si allunga, più perde il filo. Nelle conversazioni lunghe la qualità tende a calare, e l’AI può dimenticare le istruzioni iniziali o reintrodurre errori già corretti. È un limite noto di questi modelli.
Nessuno scrive le scelte, fatte e non fatte. Nel vibe coding non resta traccia di cosa è stato deciso, perché, e quali alternative sono state scartate. Riga per riga il codice può anche essere pulito, ma manca il ragionamento che ci sta dietro. Chi arriva dopo, che sia un nuovo sviluppatore, un collega o la stessa AI in una chat nuova, del progetto non sa nulla e deve tirare a indovinare. E un ragionamento mai messo per iscritto non si recupera.
C’è troppo codice per leggerlo tutto. Il codice scritto dall’AI ormai non si riesce più a leggere per intero. Può anche essere scritto bene, ma è troppo, e arriva a una velocità che una persona non regge. Così si perdono di vista i legami nascosti tra le parti. Modifichi un file e se ne rompono altri, che non sapevi collegati. E quando sbaglia l’AI non avvisa, perché il risultato ha comunque un aspetto convincente.

Somiglia alla storia del genio della lampada. Esprimi un desiderio e speri che torni quello che avevi in mente. L’AI è velocissima, ma esegue. Stabilire se il risultato va bene per la tua azienda tocca a chi la usa, e nel vibe coding questo passaggio salta.

Il punto chiave

Il vibe coding si fida della sensazione che tutto funzioni. In produzione, al posto di quella sensazione, servono controlli rigorosi, fatti ogni volta allo stesso modo e su ogni parte dell’app. Quello che resta fuori dai controlli è quello che, prima o poi, si rompe davanti ai clienti.

Quando va bene e quando no

Va bene quando devi capire se un’idea sta in piedi:

un prototipo cliccabile da mostrare a qualche potenziale cliente;
una demo per un socio, un investitore o un bando;
piccoli strumenti interni, senza dati sensibili, da buttare quando vuoi.

Non basta quando il progetto va in produzione, cioè quando lo usano persone reali per cose reali: clienti che lasciano i loro dati, pagamenti, prenotazioni, pagine che devono farsi trovare su Google. È la differenza tra cucinare per gli amici e aprire un ristorante.

Aspetto	Prototipo	Produzione
Chi lo usa	Tu, il team, qualche tester	Clienti, fornitori, motori di ricerca
Dati	Finti o tuoi	Personali, spesso di terzi
Se si rompe	Riprovi	Perdi contatti, ordini, reputazione
Chi ne risponde	Tu, ma con poco in gioco	Tu, anche verso il Garante privacy
Manutenzione	Nessuna	Aggiornamenti, backup, monitoraggio

Gli errori più comuni, e cosa rischi

La demo è la punta dell’iceberg. Quello che conta sta sotto, dove di solito non si guarda.

Il punto chiave

Quasi tutti gli errori nascono dallo stesso punto: qualcosa arriva ai clienti, o ai dati veri, senza che nessuno l’abbia controllato.

1. Pubblicare codice che nessuno ha controllato

L’errore. L’app funziona, quindi va online. Ma un’app può funzionare alla perfezione e lasciare i dati dei clienti leggibili da chiunque: regole di accesso al database troppo larghe, chiavi e password visibili nel browser. L’AI non lo fa apposta. Se non le chiedi di pensare alla sicurezza, tende a fermarsi appena l’app funziona.

Cosa rischi. Dati esposti. Nel 2025 Veracode, che vende strumenti di analisi della sicurezza, ha messo alla prova oltre 100 modelli AI su 80 compiti scelti tra quelli in cui è facile introdurre una falla. Nel 45% dei casi il codice conteneva vulnerabilità tra le più diffuse nelle applicazioni web (Veracode, 2025). A marzo 2025 un ricercatore ha controllato 1.645 progetti nella vetrina di Lovable e in 170 ha trovato dati leggibili da chiunque, tra cui email, telefoni e dati di pagamento (Matt Palmer, 2025). Il ricercatore lavorava per un concorrente e lo ha dichiarato. Secondo Lovable, proteggere i dati di ogni app spetta a chi la pubblica.

2. Dare all’agente accesso ai dati veri

L’errore. Claude Code, Codex e gli altri agenti eseguono comandi: creano e cancellano file, modificano database e, se hanno le credenziali, pubblicano. Collegarli ai dati veri dell’azienda, senza un ambiente di prova separato, è un rischio operativo.

Cosa rischi. Di perdere i dati. A luglio 2025 Jason Lemkin, fondatore della community SaaStr, ha raccontato che l’agente AI di Replit aveva cancellato il database di produzione della sua app, nonostante gli avesse chiesto di non toccare nulla (Lemkin su X, 2025). I dati sono stati poi recuperati. Un’istruzione scritta nel prompt non basta a fermare un agente. Se le credenziali gli permettono di modificare un database, può anche cancellarlo.

3. Pensare che agli obblighi di legge ci pensi qualcun altro

L’errore. Dare per scontato che privacy e cookie siano a posto perché l’AI ha generato un banner.

Cosa rischi. Se dall’app escono dati personali risponde prima di tutto il titolare del trattamento, cioè l’azienda che usa l’app con i dati dei suoi clienti: quasi sempre tu. La piattaforma ha obblighi propri e deve avvisarti, l’AI non risponde di niente. Se è probabile che la violazione comporti un rischio per le persone, va notificata al Garante, dove possibile entro 72 ore da quando l’hai scoperta (Garante privacy). E dal 28 giugno 2025 i negozi online rivolti ai consumatori devono essere usabili anche dalle persone con disabilità. Sono escluse le microimprese, sotto le 10 persone e i 2 milioni di euro di fatturato o bilancio (AgID, 2026).

4. Non provare l’app come la userà un cliente

L’errore. Considerare finita una funzione quando sembra funzionare, senza provarla con utenti che sbagliano, dati imprevisti e tante richieste nello stesso momento.

Cosa rischi. Lentezze ed errori alla prima campagna pubblicitaria o al primo picco di traffico. Il collaudo vero lo fanno i tuoi clienti.

5. Non avere una persona che conosce il codice

L’errore. Tenere online un’app mai controllata, senza documentazione, che in azienda non sa spiegare nessuno.

Cosa rischi. Quando qualcosa si rompe serve uno sviluppatore che legga tutto da capo, e quelle ore le paghi tu. Ogni modifica richiede più tempo del previsto. Gli sviluppatori lo chiamano debito tecnico. È lo stesso meccanismo di cui abbiamo parlato raccontando quanto costa davvero un sito, dove quello che risparmi all’inizio rischi di spenderlo dopo.

6. Credere che online voglia dire trovato

L’errore. Molte app generate con l’AI costruiscono le pagine direttamente nel browser, con un linguaggio chiamato JavaScript. Google consiglia invece pagine che arrivano già complete, perché “non tutti i bot possono eseguire JavaScript” (Google Search Central, traduzione nostra).

Cosa rischi. Un sito che alcuni motori leggono in ritardo e altri non leggono affatto. Poi c’è da farsi trovare. Parole chiave, pagine per servizio e per città, scheda Google Business Profile sono decisioni di strategia SEO, e un prompt non le prende al posto tuo.

Vibe coding in azienda, senza sviluppatori

Sempre più aziende lo fanno. Qualcuno in ufficio, con Claude Code o Lovable, si costruisce il gestionale, il configuratore o l’automazione che prima avrebbe chiesto a un fornitore.

Va bene per uno strumento interno, senza dati dei clienti.
Serve esperienza quando lo strumento tocca i clienti, i pagamenti o il sito pubblico. Per giudicare quello che l’AI ha prodotto bisogna sapere cosa cercare, e chi non ha mai visto una falla di sicurezza non la riconosce in un codice che funziona.

Il punto chiave

L’AI amplifica chi la usa: in mano a uno sviluppatore esperto fa risparmiare giorni, in mano a chi non ha esperienza produce più in fretta problemi che nessuno vede.

Ci sono poi rischi che con il codice c’entrano poco:

lo strumento lo conosce una persona sola, e se cambia ruolo o va via non c’è chi sappia rimetterci mano;
non è stato deciso chi lo aggiorna, chi fa i backup e chi interviene se si ferma;
il tempo di chi lo costruisce e lo mantiene è un costo, anche se non arriva in fattura.

Fare da soli resta possibile. Conviene però far guardare il lavoro a qualcuno con esperienza prima che arrivi ai clienti. Di solito un secondo parere costa molto meno di un rifacimento.

La soluzione: l’AI dentro un processo

Rinunciare all’AI non ha senso, e noi per primi non lo facciamo. Abbiamo anche raccontato gli strumenti AI che usiamo, a partire da Claude Code. Farsi scrivere del codice è ormai alla portata di chiunque. Un prompt però non genera il giudizio sul tuo caso, cioè sapere cosa costruire e accorgersi quando quello che l’AI produce è sbagliato in modo sottile. Per questo con l’AI l’esperienza conta più di prima.

In pratica:

Prima la strategia. Cosa deve ottenere il sito per il tuo business, per chi, con quali pagine. Il codice viene dopo.
Controlli rigorosi su ogni modifica. Leggere a occhio tutto quello che l’AI produce non è più realistico. Ogni modifica passa da controlli fissi, sempre gli stessi, prima che una persona la approvi e ne risponda. Nessuna modifica va online senza averli superati.
Una copia di prova. Le modifiche passano da lì prima di arrivare al sito pubblico, e ogni rilascio si può annullare.
Manutenzione continua. Aggiornamenti periodici, backup giornalieri e controlli di sicurezza fanno parte dell’assistenza tecnica. Per mesi abbiamo pubblicato sul blog un report settimanale sulle vulnerabilità di WordPress.
Un referente. Se qualcosa si ferma, sai chi chiamare.

Lavoriamo così in tutti i nostri progetti di sviluppo web su misura.

Checklist: 5 domande prima di andare online

Non serve essere tecnici per farsele.

Una persona esperta ha controllato l’app, oltre a vedere che funziona?
Sai dove finiscono i dati dei tuoi clienti e chi può vederli?
Esiste una copia di sicurezza, ed è stata provata almeno una volta?
Se l’app si ferma sabato sera, sai chi chiamare?
Privacy, cookie e, se vendi online, accessibilità sono a posto?

Se a una di queste rispondi “no” o “non lo so”, prima di aprire ai clienti conviene un secondo parere.

Domande frequenti

Il vibe coding è sicuro?

Non di per sé. Il codice generato dall’AI può essere corretto o vulnerabile, e il vibe coding elimina proprio il controllo che distingue i due casi.

Posso mettere online un’app fatta con Lovable, Claude Code o Codex?

Sì, dopo una revisione: trattala come una prima versione. I controlli automatici di alcune piattaforme aiutano, ma non sostituiscono una persona esperta che controlla il codice e chi può accedere ai dati.

Un dipendente che non è uno sviluppatore può creare un’app aziendale con l’AI?

Sì, per strumenti interni che non trattano dati dei clienti. Se l’app tocca clienti, pagamenti o il sito pubblico, prima di usarla serve la revisione di una persona esperta.

Se l’AI scrive il codice, a cosa serve ancora uno sviluppatore?

A decidere e a controllare. L’AI scrive in fretta, ma non conosce la tua azienda e non risponde di quello che pubblica.

Ho già un’app fatta in vibe coding: devo rifarla da zero?

Non necessariamente. L’interfaccia e parte della logica possono restare, se superano una revisione. Le parti da controllare per prime sono l’accesso ai dati, il login e le chiavi scritte nel codice.

In sintesi

Il vibe coding ha reso economico provare un’idea, ed è una buona notizia. Quando però l’app va in produzione arrivano i dati dei clienti e gli obblighi di legge, e serve qualcuno con esperienza che l’abbia controllata e che risponda se si ferma.

Hai un prototipo, o uno strumento costruito in azienda con l’AI, e vuoi capire se è pronto per i clienti? Raccontaci il progetto. Lo guardiamo insieme e ti diamo un secondo parere: cosa tenere, cosa sistemare e quanto costa portarlo online con i controlli che servono.

Fonti

Andrej Karpathy, post su X del 2 febbraio 2025: origine del termine “vibe coding”.
Veracode, 2025 GenAI Code Security Report (30 luglio 2025): vulnerabilità OWASP Top 10 nel 45% dei casi di test, oltre 100 modelli, 80 compiti. Veracode vende strumenti di sicurezza.
Matt Palmer, dichiarazione su CVE-2025-48757 (29 maggio 2025) e record ufficiale CVE-2025-48757: 170 progetti esposti su 1.645 analizzati, gravità critica (CVSS 9.3). Lovable contesta la segnalazione e attribuisce a ogni cliente la responsabilità dei dati della propria app. All’epoca l’autore lavorava per Replit, concorrente di Lovable, e lo dichiara.
Jason Lemkin, post su X del 18 luglio 2025 e post sul ripristino: database di produzione cancellato dall’agente AI di Replit, dati poi recuperati.
Garante per la protezione dei dati personali, violazioni di dati personali: notifica entro 72 ore ove possibile, comunicazione agli interessati se il rischio è elevato.
AgID, Linee guida sull’accessibilità dei servizi (versione 1.0 del 4 marzo 2026): obblighi dal 28 giugno 2025, esenzione delle microimprese.
Google Search Central, “Understand JavaScript SEO basics”: raccomandazione su rendering lato server e pre-rendering.