Ship Fast, Stay Safe: prototipazione AI che sopravvive in produzione

Dalla demo vibe-coded al grado produzione — la disciplina in mezzo. Basato sul webinar Supabase con Zimo (Brthrs Agency), Harry (Imaginary Space) e Victor (Performanze).

C'è una GIF con cui Zimo di Brthrs Agency ha aperto la sua demo. Un treno, che viaggia a piena velocità — ma non su rotaie. Semplicemente attraversando il terreno aperto, funzionale e caotico. Così appaiono la maggior parte dei prototipi vibe-coded dopo sei settimane in produzione.

L'onda dei build AI è reale. Tempi che un tempo significavano sei mesi e un vero team di ingegneria significano ora un pomeriggio e un account Lovable. Non è hype — è la realtà operativa per agenzie, fondatori e CTO di questo webinar. Ma la velocità senza architettura è solo debito che si accumula silenziosamente finché qualcosa non si rompe davanti a un cliente.

Lo stesso pattern si mostra nel servizio clienti alimentato da AI. Distribuire Fin o qualsiasi agente AI su una knowledge base frammentata produce lo stesso risultato — avvio rapido, plateau precoce, frustrazione crescente. Gli strumenti sono diversi. La modalità di fallimento è identica.

Ecco cosa fanno diversamente le persone che distribuiscono effettivamente sistemi AI in produzione.

La regola 80/20 di cui nessuno parla

Il framework di Zimo era diretto: "Passo l'80% del mio tempo a pianificare. Il restante 20% a implementare."

Questo è l'opposto di come la maggior parte dei fondatori affronta gli strumenti AI. Aprono Lovable, digitano una richiesta di funzionalità, e accettano il risultato. Il risultato è ciò che lui chiama "intelligenza media" — il modello fa pattern-matching contro i suoi dati di training e vi dà la versione più generica di ciò che avete chiesto.

L'acceleratore è l'ingegneria di contesto, non l'arte del prompting. La distinzione conta. Il prompting è la formulazione. L'ingegneria di contesto è caricare l'IA con il giusto ambiente — intenzione utente, documentazione tecnica, vincoli di business — prima che tocchi una singola riga di codice.

Il suo workflow specifico: estrarre la documentazione Supabase pertinente prima della pianificazione, far cercare al modello il giusto approccio di implementazione, generare un piano strutturato, poi fare una seconda passata dicendo "sei un ingegnere junior incaricato di implementare questo piano — rivedi la documentazione e segnala ogni domanda che hai." Questo loop cattura i problemi architetturali prima che diventino problemi di produzione.

L'insight chiave: la documentazione è contesto. La doc di Supabase è leggibile da esseri umani, ma anche da AI. Alimentarla nella fase di pianificazione significa che il risultato riflette le vere best practice, non medie statistiche.

"Lento è fluido, fluido è veloce. Ci vuole molto tempo per pensare a cosa vogliamo realmente costruire — ma se diamo tutto questo come contesto all'IA, possiamo andare molto veloci nell'implementazione."

Lovable ne ha fatto da allora il default. La Plan Mode (febbraio 2026) mostra un piano di costruzione strutturato prima che venga generato anche una sola riga di codice. La Chat Mode (giugno 2026) va oltre — si inizia ogni nuovo progetto in una conversazione di pianificazione, e Lovable pone domande chiarificatrici sul vostro pubblico target, le vostre funzionalità e i vostri vincoli tecnici prima di toccare una riga di codice. Gli errori di AI che costano di più crediti risalgono quasi sempre a un prompt vago. Lo strumento ora vi spinge a correggere questo fin dall'inizio.

I progetti che si bloccano sono quasi sempre quelli che hanno saltato la fase di pianificazione. Lovable ha ora integrato questa frizione per design.

La sicurezza non è un problema per dopo

Ogni panelist ci è tornato indipendentemente: il lavoro di sicurezza fatto dopo il lancio è dieci volte più difficile della sicurezza integrata nel piano.

Abbiamo ora uno studio di caso documentato di cosa succede quando non lo è. Il CVE-2025-48757, divulgato a metà 2025, ha esposto oltre 170 app Lovable in produzione a causa di policy RLS mancanti. La chiave anonima di Supabase è integrata nel JavaScript lato client per design — senza RLS, chiunque apre gli strumenti di sviluppo del browser può interrogare l'intero database direttamente. Email, record di pagamento, chiavi API, dati personali — tutto accessibile senza autenticazione. Una valutazione Q1 2026 su oltre 200 app vibe-coded ha trovato che il 91,5% conteneva almeno una vulnerabilità riconducibile al codice generato da AI. "La S di vibe coding sta per security" è diventato il running joke in ogni forum di sviluppatori. L'incidente non è un argomento contro l'uso di Lovable — è un argomento per trattare la checklist di sicurezza come non negoziabile prima che un'app tocchi utenti reali.

L'OWASP Top 10 resta il riferimento di base. Prima degli strumenti AI, l'80% delle app consegnava qualche forma di vulnerabilità di controllo degli accessi basato sui ruoli. Questo numero non è migliorato con l'AI — è diventato più difficile da individuare perché il codice sembra corretto finché non lo si interroga in modo avversariale.

Tre cose tornavano costantemente:

Le policy RLS sono la vostra ultima linea di difesa. La Row Level Security di Supabase non è un nice-to-have — è il meccanismo che impedisce al vostro agente AI di restituire accidentalmente dati cliente a cui non dovrebbe avere accesso. Lovable configura policy RLS di base automaticamente, ma dovete rivederle e stringerle prima del go-live. È molto più facile cambiare le policy prima che esistano dati reali.

Non memorizzate mai segreti nel codice frontend. Questo è basilare ma coglie più progetti vibe-coded di qualsiasi altro problema. Chiavi API, segreti Stripe, qualsiasi cosa sensibile — appartiene alle funzioni server, non ai vostri componenti React dove qualsiasi ispettore del browser può leggerlo. I segreti nel codice frontend devono essere considerati compromessi.

L'injection di prompt è un vettore di attacco specifico dell'AI che la maggior parte delle persone trascura. Se costruite un chatbot o un'interfaccia AI — che sia in un'app Lovable o un deployment Fin — provate attivamente a romperlo. Trovate liste di prompt avversariali, incollateli dentro, e osservate cosa restituisce la vostra AI. La domanda non è solo se il vostro database è sicuro — è se la vostra AI può essere manipolata per estrarre dati o compiere azioni che non dovrebbe.

"Non è che il vibe coding sia intrinsecamente insicuro. È avere il riflesso di ricordarsi di verificare — e non solo di vibe codare e dimenticare la sicurezza."

Le revisioni di sicurezza assistite da AI sono ora abbastanza accessibili da non avere alcuna scusa per saltarle. Lovable ora avvia automaticamente una scansione di sicurezza di base ad ogni publish — coprendo policy RLS, configurazioni database e configurazioni errate note in circa 10-15 secondi. Una scansione approfondita è disponibile su richiesta, analizzando l'intera codebase in circa 3 minuti. Gli admin del workspace sui piani Business ed Enterprise possono bloccare la pubblicazione su scoperte critiche. Il Security Advisor di Supabase evidenzia i problemi a livello database direttamente nel dashboard. Nessuno di questi strumenti sostituisce il pentest per sistemi di produzione seri — ma hanno notevolmente alzato il pavimento dal CVE.

Il cambio di paradigma del selfware

Il framework di Victor in Performanze ha introdotto un concetto che merita una sosta: il selfware — software costruito attorno ai workflow, dati e operazioni propri di un'azienda, invece di essere adattato da un SaaS generico.

Il pitch per i clienti è semplice. Usate un menu in Salesforce. Pagate per il prodotto completo, bloccati nella loro roadmap, esclusi dalle funzionalità che riservano ai tier enterprise. Con l'ambiente di build AI attuale, esiste un'alternativa fattibile: possedere il vostro stack, possedere i vostri dati, possedere la roadmap.

L'obiezione si scrive da sola — non potete sostituire Salesforce. Victor è d'accordo. Non è la pretesa. La pretesa è che per un numero crescente di workflow il rapporto costo-beneficio è cambiato. Non comprate un concorrente di Salesforce. Comprate uno strumento che fa esattamente ciò che fa la vostra azienda, con i vostri dati in Supabase, scalabile al vostro ritmo.

Il suo esempio: una piattaforma HR con assessment AI configurabili, costruita come alternativa completa a un copilota enterprise generico, con contesto SharePoint e Outlook integrato. I dati del cliente rimangono in tabelle PostgreSQL che lui controlla. Le funzionalità si consegnano in poche settimane. Nessuna escalation di licenza.

La scelta infrastrutturale è centrale per questo modello. Tutto consolidato in Supabase — dati strutturati in PostgreSQL, embedding nel vector store, file in bucket di storage, auth pronta all'uso. La consolidazione non è una preferenza estetica. È ciò che fa funzionare le query text-to-SQL e il retrieval RAG in modo effettivamente coerente.

"L'AI è uno specchio di noi stessi. Se iniettate un buon contesto, otterrete buoni risultati. Se iniettate un cattivo contesto, tenderà a fare la media — o sotto."

La stessa logica si applica agli agenti AI nel servizio clienti. Il tasso di risoluzione di Fin non è determinato da come lo configurate il giorno uno — è determinato dalla qualità e struttura della knowledge base sottostante. L'architettura dei contenuti deve sempre venire prima della configurazione AI.

Cosa cambia quando si costruisce per utenti reali

Il divario di produzione è per lo più invisibile finché non lo è più. Alcune modalità di fallimento specifiche che sono tornate:

Degradazione della finestra di contesto. Nel corso delle conversazioni, la qualità delle istruzioni del modello diminuisce. Per questo il team di Victor non usa lo stesso modello per ogni compito — i compiti di pianificazione complessa ricevono Opus, le operazioni più semplici modelli più piccoli ed economici. Conoscere i limiti della vostra finestra di contesto è un pensiero infrastrutturale di base che la maggior parte dei vibe-coder salta completamente.

Deriva delle aspettative in scala. Un prototipo che performa bene per un utente si comporta diversamente con centinaia di richieste concorrenti che colpiscono un database mal indicizzato. L'advisor di performance di Supabase evidenzia questi problemi prima del lancio. La maggior parte delle persone non lo consulta.

Il problema della visibilità. Harry l'ha detto bene: "I clienti vedono un progresso visibile rapido all'inizio. Quando passiamo al lavoro di sicurezza backend, smettono di vedere risultati. Pensano che tu abbia rallentato." Essere espliciti su ciò che implica il lavoro non visibile — e perché è non negoziabile — fa parte della consegna.

Il principio sotto tutto questo

Il tempo di build si è compresso. I requisiti architetturali no. I team che stanno vincendo in questo momento sono quelli che trattano l'AI come un moltiplicatore di forza su un pensiero curato, non come un sostituto di esso.

Questo è lo stesso principio che plasma entrambi i lati di ciò che facciamo in dot2.solutions. Quando costruiamo app di produzione con Lovable, la fase di pianificazione — modello dati, tipi di utente, vincoli di integrazione, postura di sicurezza — viene prima del primo prompt. Quando distribuiamo Fin per team di servizio clienti, l'architettura delle conoscenze viene prima della configurazione AI. Un progetto Lovable senza un modello dati coerente si blocca allo stesso modo di un deployment Fin senza una knowledge base strutturata. È anche da notare che da maggio 2026, i nuovi progetti Lovable passano di default a TanStack Start con SSR — lo stesso stack di questo sito, e il fondamento giusto per tutto ciò che deve essere crawlable, veloce e pronto per la produzione fin dal primo giorno.

Content prima della configurazione. Architettura prima del codice. Gli strumenti sono cambiati radicalmente. Questa parte, no.

Lettura collegata: Lovable SEO Reality Check, Intercom Fin vs chatbot AI personalizzati, e lavorare con un consulente Intercom in Svizzera.