Ingegneria assistita da AI, non vibe coding: la differenza che conta

Vibe coding, un termine diffusosi nel corso del 2025, significa descrivere a un'AI ciò che vuoi, accettare qualunque cosa produca e iterare a sensazione finché il risultato sembra giusto. È un modo legittimo di esplorare un'idea. È veloce, economico e sinceramente divertente. Ciò che non è, è ingegneria, perché nulla nel ciclo verifica che il software si comporti correttamente, resti sicuro o possa essere modificato in sicurezza il mese prossimo. L'output viene giudicato a occhio, e il processo non lascia traccia di cosa è cambiato, perché, o se qualcuno abbia controllato.

L'ingegneria assistita da AI mantiene la velocità e abbandona le congetture. L'AI scrive ancora il codice, ma ogni modifica atterra dentro una disciplina di delivery: viene versionata su un branch, controllata contro le policy, esercitata da test automatizzati, scansionata e sondata per problemi di sicurezza, e distribuita attraverso una pipeline controllata con un percorso di rollback. Un umano approva le modifiche che portano conseguenze, e un registro di controllo attesta che lo ha fatto. Il prompt è lo stesso. Tutto ciò che accade dopo il prompt è diverso.

La distinzione non è accademica. Determina se ciò che hai costruito può contenere dati dei clienti, superare una revisione di sicurezza, sopravvivere all'uscita del suo autore o essere passato a un secondo team. Se la risposta a una qualsiasi di queste domande deve essere sì, è la modalità di costruzione, non il modello che costruisce, a deciderlo.

Il termine è nato come un complimento. Un modo per dare un nome a quanto la generazione fosse diventata semplice, e si è trasformato in un'etichetta di avvertimento quando la prima ondata di app costruite con l'AI ha incontrato utenti reali. Nulla nell'avvertimento è anti-AI. I modelli non sono il problema; lo è il sistema mancante intorno a loro, e lo stesso modello calato in un ciclo di delivery governato produce software che un'azienda può difendere. Ecco perché l'argomento qui riguarda l'architettura di processo, non la scelta del modello, e perché vale qualunque sia il fornitore di AI che preferisci. Vale anche a ogni dimensione: una startup di due persone può fare vibe coding in modo responsabile sapendo da che lato della linea si trova; una banca non può permettersi di non saperlo.

La maggior parte dei team incontra questo problema al momento del passaggio di consegne. Qualcuno nel marketing, nelle operations o nel prodotto costruisce in vibe coding uno strumento che funziona abbastanza bene da far sì che le persone inizino a dipenderne. Poi serve l'SSO. Poi memorizza qualcosa di personale. Poi un direttore chiede chi revisiona le modifiche, e la risposta onesta è nessuno. A quel punto le scelte sono brutte: ricostruirlo come si deve, adottarlo così com'è ed ereditare un rischio sconosciuto, o uccidere uno strumento che le persone già usano.

Il costo si presenta su tre registri. Primo, il rilavoro: i prototipi che non possono essere promossi vengono ricostruiti da zero, il che significa che la via veloce era in realtà quella lenta. Secondo, l'esposizione di sicurezza: codice generato e mai revisionato va in produzione con i pattern di accesso e le dipendenze che il modello ha scelto per caso, e nessuno sa dire cosa contenga. Terzo, i colli di bottiglia della revisione: quando l'AI moltiplica il volume delle modifiche ma la capacità di revisione e test resta piatta, o il rilascio rallenta al vecchio ritmo o lo scrutinio cala in silenzio. Nessuno dei due è il risultato per cui qualcuno ha comprato uno strumento AI.

C'è anche un costo organizzativo che raramente finisce nelle slide: la fiducia. Il primo strumento vibe-coded che corrompe dati o fa trapelare un record rende più difficile approvare ogni futura proposta costruita con l'AI. I team che stabiliscono presto la disciplina conservano il permesso di muoversi veloci. I team che la saltano di solito ottengono un incidente, poi una moratoria.

Se guidi l'ingegneria, la versione più acuta del dolore è l'asimmetria della colpa. Il business celebra la velocità degli strumenti costruiti con l'AI fino al momento esatto in cui uno fallisce, e il fallimento ricade sull'ingegneria, anche quando l'ingegneria non ha mai visto lo strumento. Quella dinamica rende un percorso governato la mossa conveniente, non solo quella responsabile: l'unica risposta duratura alle build non sanzionate è un modo sanzionato di costruire che sia altrettanto veloce. I divieti non sopravvivono al contatto con uno strumento che risolve il problema del lunedì mattina di qualcuno; i default migliori sì.

Un rapido auto-test. Sai nominare le ultime tre modifiche all'app e chi le ha approvate? Se l'app si rompesse in questo momento, te lo direbbe qualcosa che non sia un utente? Un collega potrebbe annullare la modifica di ieri senza di te nella stanza? Qualcosa blocca automaticamente una pubblicazione quando un flusso di login si rompe? Se hai risposto no più di una volta, stai facendo vibe coding. Comunque si chiami il tuo strumento.

Niente di tutto questo è un argomento contro la prototipazione a sensazione. L'esplorazione è da dove vengono i buoni prodotti, e imporre la disciplina completa a uno spike usa e getta fa perdere tempo a tutti. Il pattern di fallimento non è la prototipazione; sono i prototipi che diventano silenziosamente produzione perché nessuno ha tracciato la linea. Decidi dove sta la linea prima che lo strumento la attraversi, e rendi l'attraversamento un atto deliberato con una checklist. Non un graduale accumulo di utenti. Se vuoi una versione strutturata di quell'auto-test, la scorecard di rischio del vibe coding lo percorre domanda per domanda.

Esegui lo stesso test anche a livello di portafoglio. La maggior parte delle organizzazioni non ha una sola app costruita con l'AI; ne ha dozzine, in vari stati di disciplina, e nessuna lista. Un inventario con proprietari nominati, anche un foglio di calcolo grezzo, converte un rischio sconosciuto in uno gestito, e di solito fa emergere due o tre strumenti diventati silenziosamente critici mentre nessuno guardava. Quelli sono i tuoi primi candidati per il percorso governato, ordinati per sensibilità dei dati e numero di utenti piuttosto che per chi urla più forte.

Automo è stato costruito perché il percorso veloce e quello disciplinato siano lo stesso percorso. Descrivi l'app in linguaggio semplice e Automo genera vere applicazioni React, TypeScript e Supabase di tua proprietà. Ma ogni modifica atterra dentro il ciclo di delivery invece che accanto. Guardrails mappa il codice in aree di business, rileva le modifiche rischiose, applica policy in linguaggio semplice, registra la revisione umana e lascia un registro di controllo dietro ogni merge. QA esegue replay browser deterministici, test auto-riparanti, smoke gate prima della pubblicazione e controlli di produzione dopo la pubblicazione. Security esegue scansione statica, controlli delle dipendenze e sonde di controllo degli accessi, e conferma le vulnerabilità sull'app live prima di segnalarle.

Il risultato è che su Automo un prototipo e un'app di produzione non sono due artefatti diversi. Sono lo stesso artefatto a livelli diversi di scrutinio, con lo scrutinio applicato dalla piattaforma invece che da chi se ne ricorda. Il codice è React, TypeScript e Tailwind standard, esportabile sul tuo repository in qualsiasi momento, così la disciplina non diventa mai una gabbia. Per i team che gestiscono programmi di produzione seri, questo è il pitch in una riga: ingegneria assistita da AI, non vibe coding. I programmi di sviluppo seri partono da 10.000 USD all'anno; una demo è il modo più veloce per vedere il ciclo girare da un capo all'altro.

Una nota di onestà: nessuna piattaforma rende la disciplina gratuita. Le policy vanno comunque scritte, le zone protette dichiarate, e qualcuno possiede ancora le decisioni di giudizio sulle modifiche segnalate. Ciò che una piattaforma cambia è il default. Su Automo il percorso indisciplinato è quello che richiede sforzo extra, che è l'opposto di come funziona la maggior parte degli strumenti. In pratica, è quell'inversione a decidere se gli standard di un team sopravvivono al contatto con una scadenza.