Vibe coding oggi: cosa è cambiato con gli agenti AI e cosa resta da controllare

Il termine «vibe coding» l'ha coniato Andrej Karpathy a febbraio 2025: descrivi quello che vuoi, l'AI scrive il codice, tu accetti le modifiche senza leggerle e vai avanti finché funziona. Allora era quasi una provocazione. Oggi è il modo in cui nasce una buona parte delle app che mi arrivano da leggere.

In meno di due anni gli strumenti sono cambiati molto, e con loro i problemi. Qui racconto cosa vedo oggi: cosa fa davvero l'AI, dove funziona, dove si rompe ancora e il metodo che uso per non perdere il controllo del codice.

Cosa è cambiato: dai suggerimenti agli agenti

All'inizio il ciclo era semplice: scrivi una richiesta, copi il codice, incolli l'errore, riprovi. Oggi lavoro soprattutto con agenti come Claude Code, Cursor o Codex, che fanno molto di più:

• leggono il repository, non un singolo file: capiscono come sono collegate le parti prima di modificarle;
• eseguono comandi: installano pacchetti, lanciano i test, leggono gli errori e correggono da soli;
• seguono regole di progetto scritte in file dedicati (CLAUDE.md, AGENTS.md, le regole di Cursor): stack, convenzioni, cosa non toccare;
• si collegano ad altri strumenti tramite MCP (Model Context Protocol): database, documentazione, browser, sistemi di ticket.

Accanto agli agenti ci sono gli app builder come Lovable e Bolt: dalla descrizione generano frontend, autenticazione e database (spesso su Supabase) in pochi minuti. v0 fa lo stesso soprattutto per l'interfaccia. È il modo più veloce per avere qualcosa da mostrare. È anche il modo più veloce per avere in produzione codice che nessuno ha letto.

Dove il vibe coding funziona

Lo uso ogni giorno, e ci sono casi in cui il guadagno di tempo è netto:

• prototipi e MVP per mettere un'idea davanti a utenti veri prima di investire;
• strumenti interni con pochi utenti e dati non critici;
• lavoro ripetitivo su codice esistente: migrazioni, refactoring guidati, aggiornamento di dipendenze;
• test: scrivere i casi di prova e farli girare è uno dei compiti in cui gli agenti rendono di più;
• leggere codice sconosciuto: chiedere all'agente come funziona un modulo prima di modificarlo.

Dove il codice scritto dall'AI si rompe ancora

L'AI scrive codice che funziona nel caso previsto. I problemi stanno quasi sempre in quello che nessuno le ha chiesto. Sono gli stessi che trovo nei check-up:

• autorizzazioni: tabelle senza RLS policy su Supabase, controlli fatti solo nel browser, ruoli che l'utente può cambiare da solo;
• segreti: chiavi di OpenAI o la chiave segreta di Supabase (service_role o le nuove chiavi secret) nel frontend o nella storia del repository;
• pagamenti: webhook che non verificano la firma, piani a pagamento sbloccabili dal browser;
• costi: chiamate ad API e database senza limiti, che crescono con gli utenti o con un abuso;
• manutenibilità: file enormi, logica duplicata, nessun test. L'agente corregge un bug e ne apre un altro, perché non c'è niente che lo segnali;
• dipendenze: pacchetti obsoleti o, a volte, pacchetti che non esistono e che il modello ha inventato. Qualcuno li registra apposta per farli installare (si chiama slopsquatting).

Più l'agente è autonomo, più conta dove lo lasci lavorare. Un agente con accesso al database di produzione o a chiavi con permessi ampi può fare danni veri, anche senza volerlo.

Il metodo che uso

Il rischio sta nel saltare le fondamenta. Con gli agenti lavoro così:

1. Prima la specifica, poi il codice. Cosa deve fare la funzione, quali dati tocca, chi può vederli e modificarli. Dieci righe scritte prima evitano ore di correzioni dopo.
2. Passi piccoli. Un task alla volta, su un ramo suo, e niente arriva al ramo principale senza test verdi e revisione.
3. I test prima della funzione. Scrivo prima il piano dei test, poi il codice, e li faccio girare a ogni passo. Sono la rete che ferma l'agente quando rompe qualcosa.
4. Regole di progetto scritte. Stack, convenzioni, cartelle da non toccare, comandi per i test: tutto in un file che l'agente legge a ogni sessione. Le decisioni non ovvie finiscono in un documento di decisione.
5. La sicurezza non la decide l'AI. Autorizzazioni sul server e nel database (RLS policy, ruoli), segreti solo in variabili d'ambiente lato server, controlli automatici sulle dipendenze e sul Security Advisor di Supabase.
6. L'agente non tocca la produzione. Lavora in locale o in un ambiente di prova con dati di prova; i comandi sulla produzione li lancio io.
7. Due revisioni prima del lancio. Una automatica, con agenti separati che cercano problemi di sicurezza, dati e correttezza; poi la mia, con attenzione a dati, permessi e pagamenti.

Prima di andare in produzione

Se la tua app è nata così, queste sono le domande da farti prima di aprirla a utenti veri:

• Ogni tabella ha le sue RLS policy, anche quelle aggiunte per ultime?
• C'è una chiave segreta nel codice che arriva al browser o nel repository?
• Chi decide se un utente ha pagato: il server o il browser?
• Le chiamate ad API a pagamento hanno un limite?
• Esistono test che girano a ogni modifica?
• Hai un backup e hai mai provato a ripristinarlo?

Se a una di queste rispondi «non lo so», l'app non è da buttare: serve qualcuno che la rilegga con occhi diversi da quelli dell'AI che l'ha scritta.

Con il Check-up Codice AI leggo il codice della tua app e ti dico cosa è rotto, cosa è pericoloso e cosa sistemare prima. Prezzo fisso, NDA prima dell'accesso, accesso in sola lettura. La pagina del Check-up Codice AI