"L'app ce l'ho già, funziona, manca solo l'ultimo ritocco." È una frase che ormai sento sempre più spesso. E molte volte, in effetti, funziona: interfaccia curata, pulsanti che rispondono, dati che compaiono, tutto costruito in pochi giorni con Lovable, quasi senza scrivere una riga di codice. Il problema è che quell'"ultimo ritocco" in realtà è tutto ciò che separa una demo da un prodotto. E quel "tutto" spesso pesa più di tutto il lavoro fatto fino a quel momento.
Questo fenomeno ha già un nome: vibe coding. In questo articolo ti spiego cos'è, perché è geniale per un prototipo e pericoloso per un prodotto, cosa manca concretamente a un'app vibe-coded, quando basta davvero (sì, a volte basta sul serio) e come trasformare un prototipo del genere in un prodotto reale, capace di reggere in produzione, con tutti gli obblighi italiani al loro posto.
Cos'è il vibe coding
Il vibe coding è un modo di sviluppare in cui non costruisci l'app scrivendo codice, ma descrivendo a parole, in linguaggio naturale, a uno strumento di IA cosa vuoi. "Fammi un'app per la lista delle cose da fare, con login e modalità scura" e dopo qualche secondo hai una schermata funzionante. Non ti piace il colore? Chiedi di cambiarlo. Manca un pulsante? Chiedi di aggiungerlo. Non scrivi codice riga per riga: guidi a sensazione, ossia chiedi, guardi il risultato, chiedi una correzione. Da qui il "vibe". In italiano qualcuno lo traduce come "programmazione conversazionale", ma il termine inglese ormai è quello che si usa.
Gli strumenti che lo permettono sono ben noti: Lovable e Bolt generano l'intera app, v0 l'interfaccia, Cursor e ChatGPT scrivono codice a partire dalla conversazione. È tecnologia davvero impressionante e non la sminuisco: questi strumenti li conosco bene. La domanda non è mai stata "l'IA sa scrivere codice". La domanda è "ciò che ha scritto reggerà il mondo reale".
Perché il vibe coding ha una caratteristica invisibile: è ottimizzato perché sembri funzionare. L'IA genera codice che supera il test più ovvio, cioè premi un pulsante e succede qualcosa. Ma "funziona sul mio schermo" e "funziona in produzione con utenti reali" sono due cose completamente diverse, e in mezzo c'è esattamente quel lavoro che l'IA non fa da sola.
Perché è fantastico per un prototipo e pericoloso per un prodotto
Il compito di un prototipo è uno solo: dimostrare un'idea. Gli basta funzionare per te, una volta, lungo il percorso felice (così chiamo lo scenario in cui l'utente fa tutto giusto e niente si rompe). Se vuoi mostrare a un investitore come sarà il tuo servizio, o verificare tu stesso se l'idea ha senso, il vibe coding qui non ha rivali. Ciò che prima richiedeva una settimana e qualche migliaio di euro, oggi si fa in un pomeriggio. È un vantaggio reale ed enorme.
Il compito di un prodotto è tutt'altro. Un prodotto deve funzionare non per te, ma per persone che non conosci. Con una connessione pessima. Con dati inseriti male. Con qualcuno che prova a fregarti. Di notte, mentre tu dormi. Dopo sei mesi, quando una libreria è cambiata. Con mille utenti contemporaneamente, non con uno solo. È qui che un prototipo vibe-coded inizia a sgretolarsi, e non si sgretola dove si vede, ma dove non si vede, finché non è troppo tardi.
L'illusione più pericolosa del vibe coding
Quando l'app sembra finita al 90%, l'istinto dice che resta il 10% di lavoro. Nella realtà è il contrario: la parte visibile (interfaccia, pulsanti, schermate) è quella facile, che l'IA fa bene. La parte invisibile (sicurezza, dati, casi limite, deploy, conformità) è insieme la più difficile e la più costosa. Quel 30% pesante l'ho raccontato a parte nell'articolo "Hai fatto un'app con l'IA e si è bloccata? Cosa fare adesso".
7 cose che a un'app vibe-coded mancano
Nei prototipi vibe-coded che le persone mi mostrano mancano quasi sempre le stesse sette cose. Non perché l'IA sia "cattiva": semplicemente genera ciò che le chiedi, e queste cose nessuno le chiede, perché nemmeno sai che esistono finché non diventano un problema.
| Cosa manca | Perché conta in produzione |
|---|---|
| 1. Test automatici | Senza test ogni modifica è un azzardo. Aggiusti un punto e invisibilmente se ne rompe un altro. Nel codice vibe-coded i test non ci sono quasi mai, quindi il progetto diventa sempre più fragile man mano che lo si tocca. |
| 2. Gestione degli errori | Cosa succede se cade la connessione, il server non risponde o l'utente inserisce spazzatura? Nel prototipo: schermata bianca o crash. In un prodotto serve un messaggio chiaro, un percorso alternativo e la registrazione silenziosa dell'errore. |
| 3. Sicurezza | Chiavi API esposte nel codice, database aperto da cui chiunque può prelevare dati altrui, nessuna validazione degli input. È la falla vibe-coded più frequente e pericolosa: viene sfruttata in pochi minuti. |
| 4. Migrazioni dei dati | Quando aggiungi un campo o cambi una struttura, i dati già presenti devono "traslocare" senza perdite. Nel prototipo lo schema dati si cambia cancellando e ricreando: in produzione vorrebbe dire clienti cancellati. |
| 5. Monitoraggio | In produzione devi scoprire un problema prima dell'utente. Senza tracciamento errori e log non vedi che metà delle persone non riesce ad accedere: lo scopri solo quando smettono di tornare. |
| 6. Scalabilità | Codice che regge con un utente può crollare con cento. Query non ottimizzate, nessuna cache, tutto su un solo thread: irrilevante per il prototipo, fatale per il prodotto al primo giorno di successo. |
| 7. Manutenzione | Le librerie invecchiano, escono falle di sicurezza, cambiano le regole di pagamenti e login. Un prodotto richiede cura continua. Codice vibe-coded che nessuno capisce diventa irreparabile dopo il primo guasto serio. |
Nota una cosa: nessuna di queste sette voci è visibile all'utente finché va tutto bene. Si manifestano tutte in quell'unico giorno storto, ed è proprio per loro che costruire un prodotto è più lento e più caro che fare un prototipo. Non sono la vernice finale: sono le fondamenta.
Quando il vibe coding basta davvero
E ora la parte più importante e più onesta di questo articolo. Il vibe coding non è "sbagliato". Ci sono molti casi in cui non solo basta, ma è anche la scelta più intelligente. Se rientri in uno di questi, non chiamare me: risparmia i soldi e costruisci da solo.
Qui il vibe coding basta davvero
- Strumento interno per poche persone. Un foglio di calcolo evoluto, una tabella, un sistemino usato dal tuo team. Se non custodisce dati altrui e non incassa denaro, costruiscilo con l'IA e non pensarci.
- Demo per un investitore o un cliente. Devi mostrare come sarà l'idea. A nessuno importa cosa c'è sotto il cofano, se l'obiettivo è convincere, non servire.
- Visualizzare un'idea per te stesso. Vuoi capire se il tuo progetto ha senso prima di investire soldi veri. Un prototipo vibe risponde a questa domanda nel modo più economico.
- Progetto personale. Un hobby, un diario, uno strumento per te. Se si rompe, si rompe solo per te, e te ne farai una ragione.
La regola generale è semplice: se l'app non custodisce dati altrui e non incassa denaro, il vibe coding molto probabilmente ti basta.
Quando il vibe coding non basta più
E ora l'altra faccia. C'è una soglia oltre la quale "sembra che funzioni" diventa un rischio che costa molto più di quanto hai risparmiato costruendo. La superi nel momento in cui a usare l'app iniziano persone che non conosci, oppure quando ci passa del denaro.
| Il vibe coding basta | Serve una ricostruzione professionale |
|---|---|
| La usi solo tu o una cerchia ristretta e fidata | La usano sconosciuti, clienti reali |
| Nessun denaro nel sistema | Pagamenti, abbonamenti, incassi (Nexi, Stripe, PayPal) |
| Dati irrilevanti o pubblici | Dati personali, GDPR, Garante, privacy dei clienti |
| Un guasto non costa nulla | Un fermo significa clienti o reputazione persi |
| Vive qualche settimana | Deve funzionare ed essere mantenuto per anni |
Appena compaiono clienti reali o pagamenti, ognuna di quelle sette mancanze diventa una responsabilità. Un database non protetto con i tuoi clienti dentro non è più un dettaglio tecnico: è una violazione del GDPR, e in Italia il Garante è tutt'altro che addormentato sui banner cookie e sul trattamento dei dati. Pagamenti senza gestione degli errori sono soldi che spariscono tra te e la banca. Ed è qui che la questione non è più il vibe coding, ma il prodotto.
La conformità che l'IA salta sempre (e in Italia conta)
C'è un blocco di lavoro che nessuno strumento di vibe coding gestirà mai per te, perché è specifico del mercato italiano e non c'entra con il codice "che funziona". È proprio qui che molti progetti fatti con l'IA si bloccano nel momento di mandare in produzione.
- Banner cookie a norma Garante. Deve permettere di rifiutare con la stessa facilità con cui si accetta, niente caselle preselezionate (sono illegali). In Italia si usano CMP come Iubenda o CookieYes, che l'IA non configura da sola.
- Informativa sulla privacy e dove sono ospitati i dati. Tema delicato dopo lo scrutinio del Garante su Google Analytics e i trasferimenti verso gli USA. Va deciso e scritto, non improvvisato.
- Fatturazione elettronica via SdI. Obbligatoria per ogni partita IVA dal 2024, anche in regime forfettario: le fatture sono XML trasmessi al Sistema di Interscambio dell'Agenzia delle Entrate, non PDF inviati via email. Se la tua app emette fatture, serve l'integrazione con un provider come Fatture in Cloud, Aruba o InfoCert.
- Accessibilità (Legge Stanca / EAA). Per molte attività è un obbligo crescente dal 2025. Un'interfaccia generata a sensazione raramente la rispetta.
Nessuna di queste cose la vedi nella demo. Tutte ti presentano il conto quando inizi a vendere davvero. La demo non è il traguardo: il traguardo è la produzione, con la conformità al suo posto.
Come trasformare un prototipo vibe in un prodotto
La buona notizia: un prototipo vibe spesso non è lavoro sprecato, anzi è un ottimo punto di partenza. Hai già deciso cosa fa l'app, che aspetto ha, quale logica segue. È la parte più preziosa e più difficile da mettere su carta di una specifica, ed è già fatta. Resta da chiudere quel 30% pesante per cui un prototipo non è un prodotto.
Quando mi contatti con un progetto vibe-coded, non prendo in carico né rattoppo il suo codice: costruisco il prodotto pulito da zero, e il prototipo diventa la specifica e il riferimento visivo. Una regola generale che vale la pena conoscere anche per te: la scelta tra continuare sul codice esistente e ricostruire non dipende dalla quantità di codice, ma dalla sua struttura. Se logica e modello dati sono sani, lo strato mancante sul codice esistente puoi aggiungerlo da solo o con chi l'ha scritto. Se il codice è caotico, con chiavi esposte e stato ingestibile, una ricostruzione pulita esce più veloce ed economica della toppa continua. Di cosa succede quando il codice IA inizia a crollare e "aggiustandolo" crolla ancora di più parlo a parte nell'articolo "Lovable, Bolt, v0, Cursor: cosa fare quando il codice IA si rompe".
Il percorso dal prototipo alla produzione
- Specifica. Dal prototipo prendo schermate, flussi e la logica che hai già messo a punto, e metto per iscritto cosa deve fare il prodotto, compreso ciò che il prototipo non faceva.
- Fondamenta solide, da zero. Database sicuro, login serio, chiavi nascoste, validazione degli input: la base su cui si può costruire.
- Il 30% pesante. Pagamenti, integrazioni, gestione degli errori, casi limite. In Italia qui si aggiungono spesso le integrazioni locali (Nexi XPay, Stripe, PayPal, Satispay, fatturazione elettronica via SdI, SPID/CIE) che l'IA non collega.
- Rete di sicurezza. Test, monitoraggio e log, perché del problema lo sappia tu, non il tuo cliente.
- Deploy e manutenzione. Dominio vero, hosting vero, backup e un accordo chiaro su chi cura il prodotto da qui in avanti. Il codice resta tuo, senza lock-in.
La mia proposta non è mai "ti sistemo il codice". È "ti costruisco qualcosa che funziona e incassa". La differenza è sostanziale: sistemare il codice è cosmetica, costruire un prodotto significa che i tuoi clienti possono usarlo, pagare e tornare in tranquillità, e tu puoi dormire sereno.
I numeri, concretamente
Vengo al prezzo, perché tanto me lo chiederai comunque ed è giusto così: in Italia "quanto costa" è una delle prime domande. Una ricostruzione pulita partendo dal tuo prototipo vibe, con autenticazione, sicurezza e deploy, parte da 2.900 € (MVP / PWA, iOS e Android da un'unica base di codice). Un'app business con pagamenti Nexi o Stripe, integrazioni italiane e pannello admin parte da 6.900 €, una piattaforma complessa da 14.900 €. I tempi sono di solito 2-6 settimane, a seconda del perimetro e di quanto il prototipo definisce già con chiarezza cosa deve fare il prodotto.
Può sembrare parecchio per un progetto "quasi finito", ma ricorda la tabella delle sette mancanze: non paghi la verniciatura, paghi quelle fondamenta senza le quali un'app non è un prodotto, ma solo la sua fotografia. Un confronto onesto tra freelance e web agency è legittimo: con me lavori direttamente e hai una persona di riferimento con nome e cognome.
Hai un prototipo vibe-coded e vuoi un prodotto vero?
Il tuo prototipo Lovable, Bolt, v0 o Cursor diventa la specifica: conservo schermate e flussi e sotto costruisco da zero fondamenta solide, cioè sicurezza, dati, pagamenti e deploy. MVP da 2.900 €. Scrivimi cosa stai costruendo e ricevi un preventivo gratuito con prezzo e tempi precisi. Il codice resta tuo.
Ricostruisci il mio prototipo