Vibe coding: la demo è magica. Ma la tua app regge davvero in produzione?

Il vibe coding è production-ready? Per i prototipi e i tool interni sì — e in modo brillante. Per un'app pubblicata negli store, con utenti veri e dati veri, da solo no. I veri limiti del vibe coding non stanno nel codice che scrive: stanno in tutto quello che la produzione richiede attorno a quel codice.

È la stessa industria del no-code ad aver cominciato a dare un nome alla frattura. Lo State of No-Code 2026 di Caspio descrive un'AI che tira il mercato in due direzioni opposte e arriva a una formula senza giri di parole: “La divisione non è 'AI buona contro AI cattiva'. È usa e getta contro durevole” (disposable vs. durable).

Cosa rende usa e getta un prototipo creato in vibe coding, allora? Non la demo — tutto quello che le sta intorno. Sette muri, ciascuno invisibile sullo schermo di un laptop, ciascuno concretissimo il giorno in cui provi a pubblicare. Tre di questi — il codice nativo, la pubblicazione negli store e il ciclo di vita dell'app — sono così specifici del mobile che gli abbiamo dedicato un approfondimento a parte; qui prendono il loro posto nel quadro d'insieme.

Muro 1 — Hosting e proprietà

Va detto, a onor del vero: in genere il codice è tuo. La documentazione di Lovable lo dice esplicitamente, e puoi esportarlo su GitHub. Quello che non possiedi è tutto ciò che serve al codice per girare. Per impostazione predefinita la tua app vive sul cloud gestito del fornitore — Lovable Cloud, l'hosting di Bolt, Vercel — con backend, database e pipeline di build gestiti da loro, ai loro prezzi, alle loro condizioni. Possedere il sorgente di un'app la cui infrastruttura appartiene a qualcun altro è come possedere il progetto di una casa costruita su un terreno in affitto. Produzione significa che qualcuno risponde di quell'infrastruttura per anni: uptime, backup, rinnovi, bollette. Nella demo, non lo fa nessuno.

Mutualizzazione. Una piattaforma SaaS gestisce un'unica infrastruttura per tutte le sue app, operata da un team il cui unico mestiere è tenerla in piedi — e il costo è già compreso nell'abbonamento, non scoperto a cose fatte. Ogni app che abbiamo pubblicato ha girato su questo modello dal primo giorno.

Muro 2 — Backend e dati

Il livello dati di un prototipo è ottimizzato per la demo: esiste, risponde, fa la sua figura. I dati di produzione hanno requisiti più duri — migrazioni, backup, ambienti che separano i test dalla realtà. A luglio 2025 quella lezione è finita sui giornali, quando l'agente di Replit ha cancellato un database di produzione durante un code freeze esplicito, spazzando via i record di oltre 1.200 dirigenti. Replit ha risposto annunciando la separazione automatica tra database di sviluppo e di produzione, colmando una lacuna che per i sistemi di produzione è il minimo sindacale.

E oltre il database, la produzione è il posto dove vivono i problemi operativi meno glamour. L'email transazionale è il classico: un fondatore SaaS ha raccontato su r/SaaS di avere “spesso meno del 50% di tasso di consegna” su infrastruttura email condivisa. Nessun prompt sistema la deliverability.

Un backend nato prima della tua app. Su una piattaforma gestita, il livello dati — migrazioni, backup, separazione tra test e produzione — è stato ingegnerizzato una volta, da professionisti, e viene messo alla prova ogni giorno da tutte le app che ci girano sopra; il nostro solo modulo e-commerce è in produzione per migliaia di merchant. L'idraulica poco glamour è il lavoro quotidiano di un team di piattaforma, non la tua scoperta della terza settimana.

Muro 3 — Autenticazione e sicurezza

È il muro meglio documentato, perché i ricercatori non smettono di misurarlo. Lo studio Veracode 2025 su oltre 100 modelli ha rilevato che il codice generato dall'AI introduce vulnerabilità della OWASP Top 10 nel 45% dei task testati. Un benchmark accademico pubblicato a dicembre 2025 ha misurato il divario nella sua forma più cruda: l'agente migliore produceva soluzioni funzionalmente corrette il 61% delle volte, ma solo il 10,5% delle sue soluzioni era sicuro. E nel 2025 è stata registrata una CVE che documenta l'assenza di Row-Level Security nelle app generate da Lovable — il ricercatore di sicurezza Matt Palmer ne ha scansionate 1.645 e ne ha trovate 170 che esponevano dati, incluse chiavi API e informazioni finanziarie. Quando Escape.tech ha scansionato oltre 5.600 app vibe-coded in produzione a ottobre 2025, ha trovato più di 2.000 vulnerabilità e oltre 400 segreti esposti.

Niente di tutto questo significa che i modelli siano scarsi. Significa che la revisione di sicurezza è un requisito di produzione che un prototipo, per definizione, non ha mai attraversato.

Sicurezza scritta una volta, ereditata da tutti. L'autenticazione di piattaforma è un'unica codebase temprata da anni di traffico reale, e quando qualcosa va corretto la patch si scrive una volta sola — deployata lato server all'istante, incorporata nella build successiva di ogni app. È la differenza strutturale tra un login mantenuto da ingegneri e migliaia di login generati, ognuno dei quali reinventa da solo le proprie regole di accesso.

Muro 4 — Pubblicazione negli store

Ecco il fatto che la maggior parte dei tutorial sul vibe coding salta a piè pari: la maggior parte degli strumenti prompt-to-app costruisce web app, non app mobili. Le FAQ di Lovable lo dicono senza giri di parole: “No, Lovable si concentra sulle applicazioni web”. v0 genera codice web deployato su Vercel. Bolt è l'eccezione parziale — la sua integrazione con Expo genera vero codice React Native — ma le build dei binari, i developer account e la review di Apple restano interamente un problema tuo.

Il workaround che si sente suggerire più spesso — impacchettare la web app in un guscio nativo — si scontra con la Guideline 4.2 di Apple: “La tua app dovrebbe includere funzionalità, contenuti e interfaccia che la portino oltre un sito web reimpacchettato”. Nell'esperienza del nostro team di publishing, i reviewer testano regolarmente le app offline; un wrapper che mostra una schermata bianca dice loro tutto. E la review non perdona nemmeno le app vere: Apple respinge circa il 42% delle prime submission (baseline Apple, misurata sulle app inviate dal nostro team di publishing negli ultimi 12 mesi). Abbiamo scritto una guida su perché Apple respinge le app e come rimediare.

La pubblicazione come processo industriale. Una piattaforma compila binari progettati per superare la review, e quando Apple o Google alzano l'asticella — nuove etichette privacy, nuove scadenze SDK, nuovi controlli di completezza — si aggiorna una volta e ogni app che pubblica eredita la correzione. Quindici anni di submission negli store sono una forma di capitale che nessun prompt può generare.

Muro 5 — Funzionalità native del dispositivo

Le funzionalità che rendono un'app mobile preferibile a un sito web sono esattamente quelle su cui una web app impacchettata arranca. Le notifiche push sono l'esempio più lampante: su iOS il web push funziona solo per le web app installate manualmente sulla schermata Home — mai nel browser. Fotocamera, modalità offline, biometria: ognuna richiede plugin nativi da aggiungere, configurare e mantenere a mano, fuori da tutto ciò che l'AI ha generato. Una demo web “mobile-friendly” e un'app nativa sono due specie diverse che indossano la stessa interfaccia.

Nativo fin dalle fondamenta. Su una piattaforma che compila vero Swift e vero Kotlin, push, fotocamera, offline e feedback aptico sono componenti già pronti, mantenuti a ogni release di iOS e Android — lo strato che fa sembrare un'app professionale è il punto di partenza, non un ripensamento.

Muro 6 — Regeneration drift: il codice che si riscrive da solo

Chiamalo regeneration drift, la deriva da rigenerazione: ogni nuovo prompt rigenera il codice su un contesto leggermente diverso, e il fix di ieri può sparire in silenzio nella generazione di oggi. Addy Osmani, engineering lead di Google Chrome, ha battezzato lo schema “two steps back”, due passi indietro: “Provi a correggere un piccolo bug… L'AI suggerisce una modifica che sembra ragionevole… La correzione rompe qualcos'altro”. I dati concordano: l'analisi di GitClear su 211 milioni di righe di codice modificate ha trovato i blocchi di cinque o più righe duplicate aumentati di 8 volte nel 2024, e la quota di codice rivisto entro due settimane dalla scrittura è quasi raddoppiata dal 2020. Una codebase che non sta ferma è una codebase su cui non puoi promettere niente — men che meno a un utente che ha trovato un bug.

Fondamenta che non si muovono. Su una piattaforma, l'AI genera solo il sottile strato personalizzato sopra un sostrato versionato e testato — autenticazione, checkout, CMS e design system fanno parte del sostrato, e nessun prompt lo rigenera mai. La deriva resta confinata allo strato personalizzato invece di investire l'intera app: il checkout su cui fai affidamento non può riscriversi in silenzio.

Muro 7 — Privacy e conformità

Un'app pubblicata porta con sé obblighi legali che una demo non incontra mai. Le etichette privacy di Apple e il modulo Sicurezza dei dati di Google Play richiedono entrambi di dichiarare quali dati raccogli, dove vanno e chi li tratta — domande a cui uno stack creato in vibe coding spesso non sa rispondere, perché un default da qualche parte ha piazzato i dati dei tuoi utenti su un'infrastruttura che non hai mai scelto. Il GDPR alza ulteriormente l'asticella: un consenso specifico e non aggregato, una residenza dei dati che puoi davvero dichiarare, una lista di responsabili del trattamento che conosci davvero. Niente di tutto questo si vede in una demo. Tutto questo salta fuori in una review dello store o, peggio, in un reclamo.

Conformità gestita una volta, a monte. Un unico sforzo legale e ingegneristico a livello di piattaforma — nel nostro caso: tutti i dati ospitati in Europa, gestione del consenso integrata, rilevamento automatico dei permessi richiesti da ogni funzionalità — serve tutte le app e resta aggiornato man mano che le regole evolvono. I nostri motori di compilazione fanno un passo in più: una libreria entra nel binario solo se la funzionalità che la usa è attivata, così le app non si limitano a dichiarare meno: contengono meno.

I sette muri del vibe coding — riepilogo

Sette muri, sette domande. Le risposte di piattaforma qui sopra sono le nostre; queste domande sono tue. Rispondi pensando al tuo prototipo:

1. Chi gestisce l'infrastruttura su cui gira — e la gestirà ancora tra due anni?
2. Dove vivono i dati, e cosa succede quando lo schema dovrà cambiare?
3. Qualcuno che sa leggere il codice ha rivisto l'autenticazione e le regole di accesso?
4. È in grado di produrre un binario iOS e Android firmato che superi la review degli store?
5. Sa inviare una notifica push a un telefono bloccato?
6. Puoi correggere un bug tra sei mesi senza rigenerare — e rompere di nuovo — tutto il resto?
7. Il flusso di consenso e il trattamento dei dati reggerebbero un reclamo GDPR?

Tre o più “no” (o “non lo so”), e quello che hai in mano è un prototipo. Il che non è un fallimento — un prototipo è una cosa genuinamente utile: valida un'idea in un pomeriggio e quasi gratis. Il fallimento sta solo nella confusione: pianificare un lancio, una base utenti e un business su qualcosa nato per essere usa e getta.

La conclusione non è “evitare l'AI”. La generazione di codice con l'AI la usiamo ogni giorno nei nostri team di ingegneria — il nostro CMO lo diceva già ad aprile 2025, insieme all'avvertenza che il settore ha poi confermato: “Senza conoscenze di programmazione ci si ritrova rapidamente sopraffatti o bloccati, perché l'AI può creare incoerenze significative se usata senza la supervisione di un esperto umano”.

La conclusione è puntare la velocità dell'AI su fondamenta che arrivano fino agli store. È tutta qui la logica dell'AI Extension Builder (attualmente in Beta, disponibile per tutti i clienti), la risposta di GoodBarber alla domanda prompt-to-app: descrivi una funzionalità a parole tue, un agente AI la costruisce — ma la costruisce dentro una piattaforma, su API documentate, così il risultato eredita tutto quello che a un prototipo manca. Il design segue automaticamente il design system della tua app. La sezione arriva negli store sotto forma di autentici binari Swift e Kotlin, attraverso la stessa pipeline di pubblicazione che gestiamo dal 2011 — con un team di publishing che recupera il 91% dei primi rifiuti di Apple quando capitano (ultimi 12 mesi).

I muri 2 e 3 — backend e sicurezza — ricevono lo stesso trattamento. Quando una sezione costruita dall'AI deve salvare dati, l'integrazione Supabase crea per te la struttura del database, nel tuo progetto Supabase, su un'infrastruttura che controlli tu — e ogni tabella nasce con le policy di Row-Level Security attive di default. È esattamente il punto di rottura documentato nella CVE di Lovable, gestito prima ancora che tu sapessi di dovertene preoccupare. E il cuore della piattaforma — hosting, database, notifiche push, analytics e pagamenti — è compreso in un unico abbonamento: niente pila di servizi terzi da assemblare, mettere in sicurezza e pagare separatamente. Costo totale di possesso: circa un decimo dello sviluppo su misura.

Ci sono dei limiti, ovviamente. GoodBarber è costruito per le app di contenuti e il commercio mobile; un videogioco o un marketplace fortemente personalizzato escono da quel perimetro, e per quei progetti un prototipo in vibe coding consegnato a un team di sviluppo è la strada più naturale. Dentro quel perimetro, però, l'approccio piattaforma è ciò che trasforma la velocità dell'AI in un'app che puoi pubblicare — e far funzionare nel tempo.

Il prossimo passo, in concreto:avvia una prova gratuita, apri una sezione “Create with AI” e descrivi la funzionalità che hai creato in vibe coding lo scorso weekend. Gli stessi cinque minuti. Questa volta, dietro al risultato c'è una pipeline verso gli store.

Si può pubblicare sull'App Store un'app creata in vibe coding?

Non direttamente, nella maggior parte dei casi. Lovable e v0 producono applicazioni web: non esiste un binario iOS o Android da inviare. Impacchettare la web app in un guscio nativo è possibile, ma la Guideline 4.2 di Apple respinge le app che si riducono a “un sito web reimpacchettato”. Bolt può generare codice React Native via Expo, ma build, developer account e review dello store restano a carico tuo. Le strade affidabili sono due: ingaggiare sviluppatori per industrializzare il codice, oppure ricostruire su una piattaforma che compila binari nativi e gestisce la pubblicazione. Per l'analisi completa lato mobile, leggi cosa gli strumenti di vibe coding dimenticano di dirti sulle app mobili.

Il vibe coding è production-ready?

Per prototipi, tool interni e progetti del weekend sì — ed è eccellente. Per app di produzione con utenti reali, la risposta misurata è: non senza una revisione ingegneristica. Il codice generato dall'AI introduce vulnerabilità di sicurezza nel 45% dei task testati (Veracode, 2025), e un benchmark accademico ha trovato le soluzioni del suo agente migliore funzionalmente corrette il 61% delle volte ma sicure solo il 10,5% delle volte (arXiv, dicembre 2025). Essere production-ready non è questione di codice che gira: è questione di hosting, dati, revisione di sicurezza, pubblicazione negli store, funzionalità native, stabilità del codice e conformità — i sette muri del vibe coding.

Cos'è il regeneration drift nel vibe coding?

Il regeneration drift — la deriva da rigenerazione — è quello che succede quando ogni nuovo prompt rigenera il codice su un contesto leggermente diverso, così il fix di ieri può sparire in silenzio nella generazione di oggi. Addy Osmani chiama il circolo che ne risulta lo schema “two steps back”, due passi indietro; l'analisi di GitClear su 211 milioni di righe modificate ne ha misurato l'impronta: blocchi di codice duplicato aumentati di 8 volte nel 2024. È il motivo principale per cui un'app creata in vibe coding diventa sempre più difficile da mantenere quanto più a lungo continui a lavorarci a colpi di prompt.

Apple ha vietato le app create in vibe coding?

No — e la distinzione conta. A marzo 2026 Apple ha bloccato gli aggiornamenti delle app delle piattaforme di vibe coding come Replit e Vibecode in base alla Guideline 2.5.2, che vieta le app che scaricano ed eseguono codice. La misura colpisce gli strumenti in quanto app iOS, non le app costruite con l'AI. Apple ha dichiarato a MacRumors di non avere regole specifiche contro le app create in vibe coding. Una singola app costruita con l'AI affronta invece l'asticella ordinaria: funzionalità minima (4.2), spam (4.3) e completezza — la stessa review che affronta ogni app.

Quando conviene passare da un prototipo in vibe coding a un app builder?

Nel momento in cui il prototipo deve diventare lo strumento quotidiano di qualcuno: utenti reali, presenza negli store, aggiornamenti, un backend che persiste. È una soglia di responsabilità, non di competenza: il giorno in cui altre persone dipendono dall'app, qualcuno deve rispondere dei suoi sette muri. Tieniti il prototipo; ha fatto il suo lavoro validando l'idea. Poi ricostruiscilo dove quei muri sono già il mestiere di qualcun altro — binari nativi, pubblicazione negli store, hosting e manutenzione compresi. Come ha detto il nostro CMO, il vibe coding si rivolge a un pubblico di esperti; un app builder è costruito per tutti gli altri.

Quanto costa davvero pubblicare negli store?

Un account Apple Developer costa 99 dollari all'anno; un developer account Google Play prevede un pagamento unico di 25 dollari. Poi arriva il costo vero: preparare le build, gli screenshot, le dichiarazioni privacy e sopravvivere alla review — Apple respinge circa il 42% delle prime submission (baseline Apple, misurata sulle app inviate dal nostro team di publishing negli ultimi 12 mesi). La nostra guida passo passo alla pubblicazione copre tutto il processo, e il nostro servizio di pubblicazione lo fa al posto tuo.