Il vibe coding riduce la distanza tra un’idea espressa in linguaggio naturale e un’applicazione funzionante. È un modo rapido per esplorare un flusso, validare un’interfaccia o automatizzare un’attività circoscritta. Quando il risultato deve gestire utenti, denaro o dati reali, però, il prompt è soltanto l’inizio: il controllo passa da requisiti verificabili, ambienti separati, review, osservabilità e capacità di recupero.
Un prototipo veloce non è ancora un prodotto
Collins ha scelto “vibe coding” come parola dell’anno 2025 e lo descrive come lo sviluppo che trasforma il linguaggio naturale in codice tramite l’AI. Il termine coglie bene la fluidità dell’esplorazione: si formula un intento, si osserva il risultato e si itera senza dover scrivere ogni riga a mano.
Popolarità e adozione non sono sinonimi di maturità operativa. Nel Developer Survey 2025 di Stack Overflow, tra 33.662 rispondenti l’84% dichiarava di usare o voler usare strumenti AI nello sviluppo. In una domanda separata sul vibe coding, tra 26.564 rispondenti il 72% dichiarava di non farlo nel proprio lavoro professionale. È un sondaggio volontario e non rappresenta ogni team; mostra comunque perché conviene distinguere l’esperimento assistito dalla responsabilità di mantenere un sistema reale.
Trasformare il prompt in requisiti verificabili
“Costruisci un portale clienti” non specifica chi può vedere un ordine, cosa accade a una richiesta duplicata, quali dati sono obbligatori o come si gestisce un pagamento interrotto. Prima di delegare il codice, descrivi utenti, flussi principali, permessi, vincoli sui dati, casi di errore e criteri di accettazione osservabili.
Anche i requisiti non funzionali vanno resi espliciti: tempi di risposta attesi, accessibilità, volumi, conservazione dei dati, integrazioni, compatibilità e disponibilità. Un inventario di dipendenze, migrazioni e servizi esterni rende visibile ciò che un’interfaccia convincente tende a nascondere e permette di stimare manutenzione e rischio.
Dare all’agente un ambiente, non le chiavi del sistema
Sviluppo, collaudo e produzione devono avere credenziali, dati e risorse distinti. Un coding agent dovrebbe operare in un ambiente isolato, con dati sintetici o minimizzati e senza segreti di produzione. I permessi vanno limitati ai file, ai comandi e ai servizi necessari per il compito corrente.
Le azioni ad alto impatto — modificare una pipeline, applicare una migrazione, ruotare un segreto, inviare messaggi o distribuire in produzione — richiedono un passaggio di approvazione separato. Il controllo non dipende dalla promessa scritta nel prompt, ma da barriere tecniche che impediscono all’agente di oltrepassare il perimetro anche quando interpreta male l’obiettivo.
Costruire verifiche indipendenti dal codice generato
I test devono derivare dal comportamento atteso, non soltanto dall’implementazione prodotta dall’agente. Servono casi negativi, controlli sulle autorizzazioni, prove di integrazione e scenari concorrenti, oltre al percorso felice. OWASP avverte che un agente può rendere verde la CI indebolendo asserzioni, eliminando test o simulando proprio la dipendenza che dovrebbe verificare: le modifiche ai test meritano quindi una review dedicata.
La revisione umana resta necessaria sulle decisioni di dominio e sui punti a maggiore impatto: autenticazione, autorizzazioni, denaro, dati personali, migrazioni, dipendenze e configurazione di build. Il report DORA 2025 descrive l’AI come un amplificatore delle forze e delle debolezze organizzative; test fragili e responsabilità confuse diventano più veloci, non più sicuri.
Rilasciare in modo osservabile e reversibile
Codice, configurazione e schema del database devono essere versionati insieme. Prima del deploy occorrono un backup verificato, una procedura di restore, migrazioni compatibili con la versione precedente e un rollback provato. Feature flag, rollout graduale o un gruppo pilota riducono l’ampiezza dell’errore, ma non sostituiscono la capacità di recuperare i dati.
Dopo il rilascio, log strutturati, metriche, error tracking e segnali di business devono mostrare se il comportamento reale coincide con quello atteso. Una definizione di “pronto” comprende un proprietario, una documentazione essenziale, soglie di allarme e una procedura d’incidente. Solo quando questo ciclo è ripetibile ha senso aumentare autonomia e velocità.