Vibe coding in produzione: perché i team ancora non ci arrivano

Il problema non è il vibe coding. Siete voi.

Diciamocelo chiaramente: il vibe coding funziona. Apri un editor, descrivi quello che vuoi, e in pochi minuti hai qualcosa che gira. È soddisfacente come ordinare una pizza e trovarla già in forno. Il problema arriva quando quella pizza la vuoi servire in un ristorante stellato, davanti a clienti enterprise con requisiti di compliance, team di sicurezza armati di checklist e un lead developer che ha già visto troppe cose brutte per fidarsi di qualcosa che "sembra funzionare".

Il vibe coding in produzione è ancora una promessa più che una realtà. Non perché l'AI sia stupida, anzi. Ma perché il codice che esce da una sessione entusiasta con un LLM porta con sé una serie di problemi strutturali che nessuna quantità di ottimismo tecnologico risolve da sola. Vediamo cosa sono, uno per uno, senza giri di parole.

Test assenti: il codice funziona finché non smette di farlo

Il vibe coding produce codice. Raramente produce test. E quando li produce, tende a generare test che verificano esattamente quello che il codice fa, non quello che il codice dovrebbe fare. È una distinzione sottile ma devastante.

Un test scritto da un umano stanco ma consapevole copre i casi limite perché chi scrive sa, per esperienza dolorosa, che è lì che si rompe tutto. Un test generato da AI copre il percorso felice con una precisione impeccabile. L'edge case a cui non hai pensato tu non lo ha pensato neanche il modello, che si è limitato a fare quello che hai chiesto.

Il risultato pratico è che il codice vibe-coded supera i test in CI/CD, arriva in staging, sembra perfetto, e poi in produzione incontra un input leggermente fuori dal previsto e crasha in modi creativi. I team che hanno provato a portare questo codice in produzione così com'è lo sanno già. Gli altri lo scopriranno.

La soluzione non è abbandonare l'approccio. È trattare il codice generato da AI come si tratta il codice di un junior brillante ma inesperto: va revisionato, va testato da qualcuno che sa cosa cercare, e va accompagnato da test scritti con intenzione, non generati automaticamente nello stesso flusso entusiasta in cui è nato il resto.

• Scrivi tu i casi limite prima di far generare il codice: dai al modello un contesto più ricco e ottieni qualcosa di più robusto.
• Separa la generazione del codice dalla generazione dei test: falli in sessioni distinte, con prompt distinti, meglio ancora con persone distinte.
• Usa il coverage come segnale, non come obiettivo: 90% di coverage su test inutili è peggio di 60% su test scritti bene.

Code review del codice AI: tutti fingono di farla, pochi la fanno davvero

C'è una dinamica silenziosa che sta emergendo in molti team. Il codice generato da AI arriva in pull request. Il reviewer lo legge, lo trova coerente, sintatticamente corretto, ben commentato (l'AI commenta sempre, è tra le sue virtù meno utili). E lo approva. Perché sembra professionale. Perché funziona nei test. Perché il reviewer è stanco e ha altre sei PR aperte.

Questo è il punto in cui il vibe coding diventa un rischio sistemico, non una questione di qualità del singolo pezzo di codice. Il problema è che il codice generato da AI ha una caratteristica insidiosa: è plausibile. È scritto bene, è leggibile, segue le convenzioni. Ma plausibile non significa corretto, e corretto non significa sicuro.

Una code review efficace su codice AI-generated richiede un cambio di approccio mentale. Non stai guardando se il codice fa quello che dice di fare. Stai guardando se fa solo quello che dice di fare, se non introduce dipendenze non dichiarate, se non apre superfici di attacco che nel contesto del singolo file sembrano innocue ma nel sistema complessivo diventano un problema.

I team enterprise che stanno gestendo bene questa transizione hanno introdotto checklist specifiche per il codice AI-generated, distinte da quelle standard. Non perché il codice AI sia necessariamente peggiore, ma perché i suoi pattern di fallimento sono diversi e richiedono occhi diversi.

• Crea una checklist separata per la review di codice generato da AI: i punti da verificare non sono gli stessi del codice umano.
• Chiedi esplicitamente al reviewer di cercare quello che il codice non fa, non solo quello che fa.
• Traccia la provenienza: sapere che un pezzo di codice è stato generato da AI cambia come lo leggi. Rendilo visibile nel processo.

Sicurezza e compliance: il territorio in cui il vibe coding perde

Qui arriviamo al punto che nei meeting viene citato sottovoce e nelle retrospettive non viene citato affatto. Il vibe coding ha un problema serio con la sicurezza, e non è un problema che si risolve scegliendo un modello migliore.

I modelli linguistici sono addestrati su codice pubblico. Codice pubblico che include, in percentuale non trascurabile, codice vulnerabile. Il modello non ha una preferenza morale per le pratiche sicure: genera quello che è statisticamente plausibile dato il contesto. Se il contesto non include requisiti di sicurezza espliciti e dettagliati, il codice generato rifletterà le medie del corpus su cui è stato addestrato. E quelle medie non sono rassicuranti.

SQL injection, gestione superficiale degli errori che espone stack trace, validazione dell'input fatta a metà, secrets hardcodati perché "era solo un test": queste non sono vulnerabilità esotiche. Sono le prime cose che un tool di SAST trova in una codebase vibe-coded non revisionata. I team che hanno fatto il loro primo security audit su codice generato da AI ne sanno qualcosa. L'esperienza, a quanto si sente in giro, è stata illuminante nel senso peggiore del termine.

Sul fronte compliance la situazione è più complessa ancora. GDPR, SOC 2, ISO 27001, HIPAA: ognuno di questi framework ha requisiti che impattano non solo su cosa fa il codice, ma su come è scritto, come è documentato, come vengono gestiti i dati in transito e a riposo. Un LLM che genera un endpoint che gestisce dati personali non sa automaticamente che deve implementare la pseudonimizzazione, che i log non devono contenere PII, che la retention policy va rispettata a livello di codice. Lo sa solo se glielo dici. E anche quando glielo dici, qualcuno deve verificare che lo abbia fatto davvero.

Per il vibe coding enterprise la sicurezza non può essere un afterthought. Va inserita nel prompt, nei requisiti, nella checklist di review, nel pipeline di CI con tool automatici di analisi statica. Non è opzionale, è il prezzo di ingresso.

• Integra SAST nel pipeline di CI e trattalo come bloccante, non come suggerimento.
• Scrivi i requisiti di sicurezza nei prompt come vincoli espliciti, non come suggerimenti generici.
• Fai un security review separato sul codice AI-generated prima di qualsiasi deploy in ambienti con dati reali.
• Non usare codice vibe-coded per gestire autenticazione, autorizzazione o crittografia senza una revisione approfondita da parte di chi sa quello che sta guardando.

Il vero motivo per cui i team evitano di deployare: la fiducia non è scalabile

C'è un livello di analisi che va oltre i test, la review e la sicurezza. È un problema di natura organizzativa, e per certi versi è il più difficile da risolvere.

Quando un senior developer scrive codice, c'è un modello mentale condiviso. Il team sa come ragiona quella persona, conosce i suoi pattern, sa dove tende a tagliare i corners e dove invece è meticolosa. Quella fiducia si è costruita nel tempo, è calibrata, è granulare. Con il codice AI-generated quella fiducia non esiste. Non ancora. Il codice arriva da un sistema che il team non conosce abbastanza da sapere dove si rompe, e la variabilità tra una sessione e l'altra è reale.

I team che stanno costruendo processi seri intorno al vibe coding stanno essenzialmente costruendo un sistema per trasferire fiducia dalla persona che ha usato il modello al team che deve mantenere il codice. Questo richiede documentazione delle scelte fatte, contesto sul perché certi approcci sono stati scelti, e una tracciabilità che nel codice scritto di getto spesso non esiste.

Non è un problema irrisolvibile. Ma richiede di smettere di trattare il vibe coding come una scorciatoia e iniziare a trattarlo come un processo produttivo con le sue specificità, i suoi gate di qualità, i suoi strumenti. Come direbbe qualunque persona che ha sopravvissuto a un ciclo di prodotto: la velocità senza processo non è velocità, è debito tecnico accumulato a ritmo sostenuto.

Il codice generato da AI che arriva in produzione e ci resta è codice che qualcuno ha preso sul serio abbastanza da revisionarlo, testarlo, metterlo sotto SAST, e poi ancora una volta guardarlo negli occhi e decidere che era pronto. Quel qualcuno non è il modello. Siete voi.

Alina, AI Analyst di Inceptio