Ogni demo di vibe coding è una storia del Giorno Uno. Un prompt, un’app funzionante, una schermata che sembra pronta per il lancio. Il problema è che il software non vive nel Giorno Uno. Vive nel Giorno Due, quando gli utenti reali effettuano l’accesso, i dati smettono di essere campioni e qualcuno deve cambiare qualcosa senza rompere tutto il resto. È in quel momento che la demo e il prodotto si rivelano essere due oggetti diversi.
Perché il Giorno Due è un meccanismo diverso
Il Giorno Uno chiede al modello di scrivere su una tela bianca, cosa in cui è bravo. Il Giorno Due gli chiede di modificare un sistema che ricorda solo parzialmente, cosa in cui non lo è. Il vibe coding è ancora uno strato di astrazione, non una via d’uscita dal software: non state scrivendo sintassi, ma state comunque gestendo stati, progettando schemi relazionali e gestendo casi limite, perché l’AI vi ha consegnato quella complessità invece di eliminarla.
L’artefatto si degrada man mano che cresce. Una volta che la codebase supera la finestra di contesto del modello, l’AI inizia a dimenticare le proprie decisioni strutturali e a proporre codice che contraddice i pattern precedenti. Il contesto limitato significa anche che riscrive funzioni di utilità che non può vedere al momento, lasciando logiche duplicate sparse nel progetto. Modelli addestrati su cutoff diversi scrivono per versioni contrastanti delle stesse librerie, introducendo un drift di versione. Ciò che resta è un codice Frankenstein: un mosaico di stili dove logica di interfaccia, query di database e regole di business sono aggrovigliate in file non pianificati, e ogni modifica successiva deve farsi strada attraverso tutto questo caos.
I fallimenti non si annunciano
Un crash è onesto; ti dice che qualcosa non va. I fallimenti del Giorno Due che fanno davvero danni sono quelli silenziosi. L’AI costruisce il percorso di successo specifico descritto dal prompt e ignora i casi che nessuno mostra nelle demo: modifiche simultanee di due utenti, un modulo che perde la connessione durante l’invio, un doppio clic su un pulsante, un input formattato male. Un piccolo errore di arrotondamento o di calcolo gira senza problemi in ogni transazione e riemerge mesi dopo in un report di fatturazione o in un conteggio di prenotazioni che non quadra più.
Il gap di fiducia è ciò che rende questo processo pericoloso anziché solo fastidioso. Un operatore non tecnico non può leggere il codice generato per confermare cosa faccia, e i test manuali verificano il ‘percorso felice’, non le eccezioni. Quindi l’app che “funziona perfettamente” nell’anteprima e l’app che corrompe silenziosamente un quarto dei suoi record possono essere, e spesso sono, la stessa app. Lo scopri da un cliente, non da un test.
La clausola della manutenzione
Qui è dove il Giorno Due si somma al resto del conto. Ogni modifica che apportate è una nuova generazione, e la generazione è dove risiedono sia i costi che i rischi. Rigenerare una funzionalità legata all’autenticazione significa lanciare di nuovo i dadi della sicurezza descritti in cosa significa effettivamente che ‘il 45% del codice AI è vulnerabile’, quindi uno strato che avevate già verificato deve essere verificato di nuovo. E ogni ciclo di correzione dei sintomi invece delle cause radice alimenta la tassa del fix loop: quel ciclo di debugging a pagamento che trasforma un abbonamento economico in uno a costo aperto, la stessa dinamica che distingue i contendenti in Lovable vs Bolt.
L’infrastruttura aggiunge le proprie sorprese del Giorno Due. Gli sviluppatori che scelgono l’auto-hosting per evitare il lock-in della piattaforma finiscono per sincronizzare a mano un database Supabase, un frontend Cloudflare Worker e una piattaforma cron; un disallineamento in uno solo di questi blocca tutto il sistema. Chi resta sull’hosting di una singola piattaforma eredita invece l’uptime, i prezzi e la roadmap di quella piattaforma. Nessuna delle due è l’opzione gratuita suggerita dalla demo.
Cosa continuare a generare e cosa no
L’analisi onesta non è che il vibe coding sia inutile; è eccellente per strumenti personali, prototipi e componenti personalizzati circoscritti dove l’ambito rimane piccolo. L’errore è applicarlo alle parti di un’app che devono sopravvivere alla manutenzione. Se state costruendo all’interno di una codebase reale e vi occuperete della revisione, uno strumento code-first come Cursor o una piattaforma cloud come Replit vi permette di controllare cosa cambia e quando.
Per le app aziendali - portali, strumenti interni, CRM, qualsiasi cosa con login, ruoli e dati reali - lo strato che si rompe nel Giorno Due è principalmente l’auth, i permessi e l’idraulica CRUD. Su una piattaforma come Softr questi elementi non vengono generati per progetto; sono infrastrutture di piattaforma configurabili, quindi cambiare un permesso è un’impostazione, non un ciclo di rigenerazione, e non c’è alcun fix loop in cui rientrare. Softr ha crediti AI per il suo Co-Builder, ma poiché tutto ciò che l’AI fa può essere fatto anche a mano, un saldo vuoto non blocca mai una correzione. Il Giorno Due più economico è quello in cui la parte più importante non è mai stata generata in primo luogo.