Da Vibe Coding alla Produzione: la Guida Completa in 10 Livelli

Vibe Coding: Perché il Prototipo Non è Ancora un Prodotto

Oggi puoi descrivere un'app a un assistente AI e vedertela apparire davanti in poche ore. Si chiama vibe coding e ha un effetto collaterale pericoloso: ti convince di aver quasi finito, quando in realtà hai appena iniziato.

Il vibe coding è uno strumento straordinario per i mock, le analisi e i primi prototipi, cioè proprio quelle attività che prima richiedevano settimane. Lo vediamo ogni giorno in Castaldo Solutions: fondatori e startupper costruiscono in autonomia il primo MVP, poi lo passano a noi per la parte di hardening, sicurezza e messa in produzione graduale.

La verità è semplice: fare tutto in vibe coding fino in fondo oggi è possibile, ma richiede una solida base tecnica che la maggior parte dei fondatori non ha. Tra un prototipo che gira sul tuo computer e un software che regge utenti veri, paganti, con dati reali, ci sono 10 livelli di lavoro che nessuna AI fa al posto tuo se non glielo chiedi, e che tu non chiedi perché non sai che esistono.

Questa è la mappa di quei 10 livelli. È il primo articolo di una collana: qui trovi la visione d'insieme, negli approfondimenti scendiamo nel dettaglio di ciascun livello.

I 10 Livelli per Portare un'App in Produzione

La piramide si legge dal basso verso l'alto. Alla base ci sono le fondamenta tecniche: se sbagli lì, tutto quello che costruisci sopra è fragile. In cima c'è la manutenzione, cioè quello che tiene viva l'app dopo il lancio.

Ogni livello che salti non sparisce. Diventa un problema silenzioso che ti presenta il conto quando meno te lo aspetti: di solito in produzione, con utenti veri che guardano.

Livello 0 - Che Stack Scegliere per Partire da Soli

Se sei un fondatore che parte da zero, senza un team ampio alle spalle, la scelta tecnologica è la decisione che condiziona tutto il resto. Il mio consiglio per la stragrande maggioranza dei casi è TypeScript.

Il motivo è pratico: TypeScript unifica backend e frontend sotto un unico linguaggio, ha un ecosistema enorme di framework e librerie ed è abbastanza completo da coprire quasi ogni esigenza di business. Un solo linguaggio significa meno contesto da gestire, meno errori di integrazione e una codebase che l'AI riesce a seguire meglio.

Per il database, PostgreSQL è il default sensato per quasi tutte le applicazioni. Se lavori con dati vettoriali può avere senso valutare alternative open source come Supabase, ma per il resto Postgres ti dà solidità e maturità. Aggiungi un client come Prisma e tieni lo schema del database sempre allineato alle entità della tua app, accelerando lo sviluppo.

Ne parliamo in dettaglio nell'approfondimento su stack e database per il vibe coding.

Livello 1 - Come Evitare che il Database Diventi una Bomba a Orologeria

Quando il database viene lasciato completamente in mano a un fondatore inesperto, succede quasi sempre la stessa cosa: colonne e relazioni morte, dati duplicati, informazioni disgregate su più oggetti perché manca un'analisi preventiva del modello.

Il risultato è una sporcizia dei dati che parte dal primo giorno e cresce con l'app. Più dati raccogli, più il problema si amplifica, finché ti accorgi che le informazioni non sono collegate nel modo giusto e che ogni report richiede acrobazie.

C'è poi un tema che nessuno controlla all'inizio: il connection pooling. Senza una gestione corretta delle connessioni, la tua app regge bene finché ci sei solo tu a provarla, poi crolla appena arrivano utenti reali in parallelo. Partire da un'analisi architetturale del database significa avere qualcosa che è già pronto a livello produttivo, non un castello fragile.

Livello 2 - Autenticazione: Perché Non Devi Scriverla da Solo

Uno degli errori più comuni nel vibe coding è trascinarsi un modulo di autenticazione completamente custom, scritto da zero. È un errore perché l'autenticazione è uno di quei pezzi dove non devi reinventare la ruota.

Esistono servizi e framework che ti risolvono il problema in modo sicuro e collaudato. Se vuoi un servizio gestito da terze parti, Clerk è un'ottima scelta. Se preferisci tenere l'autenticazione dentro la tua applicazione, Auth.js fa il lavoro.

Affidarti a soluzioni mature ti protegge da una categoria intera di vulnerabilità: login bucati, sessioni gestite male, account compromessi. C'è poi il lato visibilità: senza ruoli e senza Row Level Security (RLS), un utente può finire per vedere i dati di un altro. Approfondiamo tutto il tema sicurezza nell'articolo su autenticazione, segreti e vulnerabilità nel vibe coding.

Livello 3 - Dove NON Mettere il File .env (e Come Gestire i Segreti)

Questo è l'errore che non vedi subito. Te ne accorgi solo dopo, quando ti arriva una bolletta che ti fa bruciare l'intero account OpenAI in una notte.

Sempre più spesso i tecnici poco esperti mettono i file di ambiente in percorsi esposti al pubblico, con dentro chiavi API e token che finiscono indicizzati sul web. Una volta esposta, una chiave è compromessa, punto.

L'ideale non è nemmeno avere un file .env: è avere una struttura che salva tutte le variabili dentro l'ambiente o un secret manager, in modo che non esista un punto fisico da rubare. Aggiungi una rotazione periodica dei token e riduci drasticamente la superficie attaccabile. È noioso, ma è la differenza tra dormire la notte e svegliarsi con un conto a quattro cifre.

Livello 4 - Vulnerabilità e Dipendenze: il Controllo Obbligatorio Prima della Produzione

Questa è la parte più critica e, non a caso, quella più spesso ignorata. Non è un raffinamento: è un'attività obbligatoria prima di andare in produzione.

L'AI non ti scrive solo il codice. Ti porta anche le dipendenze, cioè le librerie su cui la tua app si appoggia. E qui c'è un problema strutturale: i modelli sono addestrati su versioni vecchie, quindi tendono a suggerirti librerie potenzialmente obsolete o deprecate, a volte con vulnerabilità già note e pubblicate.

Per questo la prima cosa da controllare sono le dipendenze e il codice deprecato. Strumenti come Dependabot di GitHub ti avvisano in automatico quando una libreria ha una falla nota e ti propongono l'aggiornamento. L'AI media questo non lo sa: tu devi saperlo.

Livello 5 - Codice Morto: lo Scheletro nell'Armadio del Vibe Coding

Il vibe coding lascia spesso dietro di sé codice morto: funzioni mai chiamate, logiche abbandonate, pezzi che non servono più. Ogni riga di codice morto è debito tecnico che ti porti dietro come uno scheletro nell'armadio.

Non è solo una questione di pulizia. Il codice morto è anche un rischio di sicurezza, perché fa parte di logiche che nessuno mantiene più e che possono nascondere falle. Avere una codebase pulita fin dall'inizio è cosa buona e giusta.

Qui c'è un punto che vale per tutto l'articolo: quando l'applicazione diventa grande, gli agenti AI non riescono più a vedere tutto il codice morto presente. Il valore del controllo umano, di un esperto che sa cosa cercare, aumenta proprio mentre crescono i limiti della tecnologia. Ne abbiamo parlato anche nella guida su come usare l'AI senza creare debito tecnico.

Livello 6 - Testing: Oltre l'Happy Path

Il vibe coding ti fa seguire sempre lo stesso percorso, l'happy path, e l'app sembra funzionare. Ma "funziona sul mio percorso" non è "funziona": non hai testato gli altri scenari, i diversi ruoli, né il carico reale.

Oggi gran parte dei test si automatizza con l'AI: Playwright e Puppeteer scrivono test end-to-end e unit che girano nel browser, su tutta la matrice di dispositivi e browser. Ma serve ancora l'occhio umano, soprattutto sul test book per ogni ruolo (non solo l'admin) e sul giudizio di UI che l'AI ancora non sa dare. E il backend va messo sotto stress e load test, perché se il volume supera la soglia con cui l'AI ha progettato l'app, il bug è già in architettura. Lo approfondiamo nell'articolo su testing oltre l'happy path.

Livello 7 - Compliance e Legale: GDPR, AI Act e Chi Possiede il Tuo Codice

Prima di andare in produzione devi avere il quadro normativo a posto: cookie, privacy, termini e condizioni popolati correttamente. Per farlo bene serve la consulenza di un avvocato legal tech, non un copia-incolla trovato online.

Andare avanti senza questo quadro non ti espone solo a grane legali come GDPR e AI Act. Ti espone su un fronte che quasi nessuno considera: la proprietà intellettuale. Se eroghi una consulenza o sviluppi per un cliente senza un contratto di licenza ben costruito fin dall'inizio, quel cliente può rivendicare parte del codice, soprattutto in caso di personalizzazioni. È una cosa da evitare assolutamente.

C'è anche un motivo tecnico per pianificare questo livello presto, anche se nella piramide sta a metà. Con normative come la legge 132 o l'AI Act, il rischio è dover fare interventi che snaturano l'applicazione: refactory enormi a fine progetto, e alcune funzionalità di business che semplicemente non si possono più fare. Meglio scoprirlo all'inizio che trovarsi brutte sorprese al traguardo. Ne parliamo a fondo nell'articolo su compliance by design, con AI Act, Legge 132/2025 e sanzioni; abbiamo dedicato approfondimenti anche all'AI Act per le aziende italiane e al ruolo del legal tech analyst.

Livello 8 - Infrastructure as Code: Ambienti Pronti in Minuti, Non in Giorni

Oggi puoi descrivere tutta la tua infrastruttura dentro file e container. Significa avere un ambiente di sviluppo prototipabile in minuti, non in giorni.

Il vantaggio non è solo velocità di setup. Con strumenti come Docker puoi far girare i test su database o infrastrutture effimere, create e distrutte solo durante l'esecuzione del test. Acceleri lo sviluppo e acceleri la fase di test, due cose che di solito rallentano enormemente un progetto fatto a mano.

È un livello che un fondatore o un tecnico junior raramente conosce, e che invece cambia completamente la qualità e la ripetibilità di quello che mandi in produzione. Niente più "funziona solo sul mio PC".

Livello 9 - Manutenzione: Backup, Cron e Notifiche che Funzionano Davvero

La manutenzione è l'ultimo tassello della piramide ed è quasi sempre quello impostato peggio fin dall'inizio.

Gli scenari classici li conosciamo bene: non esistono backup periodici, quindi un errore può cancellare mesi di dati. Vuoi le notifiche, ma non si attivano mai, perché non sono state attivate le code che le gestiscono. Operazioni banali come svuotare la cache del server non rientrano ancora in protocolli ben definiti che si possano delegare interamente all'AI.

Tutto questo verte su conoscenze tecniche difficili da delegare a un assistente: cron job, gestione delle code, backup e osservabilità (strumenti come Sentry per capire cosa si è rotto e PostHog per capire cosa fanno gli utenti). È lavoro che non si vede, finché non manca. Approfondiamo l'intera fase nell'articolo su come mettere in produzione un'app in vibe coding.

Il Vibe Coding Sostituisce lo Sviluppatore?

La risposta onesta è: in parte sì, e proprio per questo lo sviluppatore diventa più importante, non meno.

Gran parte del lavoro di scrittura del codice viene oggi accelerato dall'AI, ed è un bene. Ma tutta la conoscenza di messa in produzione e manutenzione, cioè i 10 livelli di questa guida, non è semplicemente sostituibile. Richiede esperienza, e richiede una manutenzione continua che troppo spesso viene ignorata.

La buona notizia è che oggi costruire un SaaS è più semplice, più rapido e più efficiente in termini di costi rispetto a pochi anni fa. La cattiva è che la facilità iniziale nasconde tutto quello che viene dopo. Prima di dire che il lavoro è finito, controlla di aver salito tutti e dieci i livelli.

Da Dove Partire

Se hai un prototipo nato in vibe coding e vuoi portarlo in produzione senza disastri, il punto di partenza è capire a che livello della piramide sei davvero. Noi lo facciamo ogni giorno: prendiamo MVP costruiti dai fondatori e li rendiamo sicuri, scalabili e pronti per utenti veri, passo dopo passo.

Parla con noi della tua app e scopri cosa ti separa dalla produzione.