L'incidente ha sempre la stessa forma. Una feature rilasciata tre settimane prima. Funzionava. I test erano verdi. Poi si rompe qualcosa di adiacente — una conversione di valuta, un controllo di permessi, un retry che ingoia silenziosamente gli errori — e quando qualcuno finalmente apre il file, nessuno nel team riconosce quel codice. Non perché sia codice scritto male. Perché non l'ha scritto nessuno. È stato generato, letto in diagonale, approvato e mergiato.
Questa è la parte della storia del vibe coding che non finisce nelle demo. Gestisco l'engineering su un portafoglio di prodotti enterprise e negli ultimi diciotto mesi ho visto lo stesso schema ripetersi in una dozzina di codebase: il guadagno di velocità è reale, è grande, e viene pagato dopo — con gli interessi — a meno che qualcuno non metta prima dei guardrail strutturali.
Voglio essere preciso sulla mia posizione, perché viene fraintesa in entrambe le direzioni. Non sono contro il vibe coding. In Lasting Dynamics i nostri team usano assistenti AI ogni singolo giorno e non tornerei indietro. Ogni ingegnere che assumiamo passa per LD Academy, dove programmare con agenti AI fa parte del percorso fin dal primo giorno. Ma c'è una differenza tra usare l'AI per scrivere codice e lasciare che l'AI decida la tua architettura, e la maggior parte dei team enterprise non ha ancora tracciato quella linea da nessuna parte.
Il Parere di Michele
La domanda non è se il tuo team debba fare vibe coding. Lo sta già facendo — con o senza una tua policy. L'unica domanda vera è se il codice prodotto così possa arrivare in produzione senza passare da un gate di cui è responsabile una persona. Se la risposta è sì, non hai una strategia AI. Hai una passività non contabilizzata.
Cosa Significa Davvero Vibe Coding in un Contesto Enterprise
Il vibe coding è la pratica di costruire software descrivendo l'intento in linguaggio naturale e accettando il codice prodotto da un modello AI, con revisione riga per riga limitata o assente. Il termine è nato per builder solitari che rilasciano prototipi a grande velocità, e in quel contesto è una cosa splendida. Il problema è che la pratica è migrata nelle codebase enterprise senza che la definizione migrasse con lei.
In ambito enterprise, il vibe coding si capisce meglio come uno spostamento del punto in cui si applica il giudizio ingegneristico. Non è sparito: si è spostato. Prima viveva nell'atto di scrivere. Ora deve vivere nell'atto di specificare, vincolare e verificare. I team che hanno fatto questa transizione in modo consapevole rilasciano più velocemente e con meno difetti. I team che non l'hanno fatta hanno semplicemente rimosso il giudizio dalla pipeline e l'hanno chiamata produttività.
Sotto la stessa etichetta finiscono tre comportamenti distinti, e trattarli allo stesso modo è il punto in cui inizia la maggior parte dei fallimenti di governance:
- Scrittura assistita — lo sviluppatore sa cosa vuole, usa l'AI per scriverlo più in fretta e legge ogni riga. Rischio basso. È semplicemente una tastiera migliore.
- Implementazione delegata — lo sviluppatore specifica il comportamento, l'AI produce un modulo intero, lo sviluppatore revisiona l'interfaccia e controlla a campione le parti interne. Rischio medio. Gestibile con i gate giusti.
- Generazione non supervisionata — un prompt produce codice funzionante, i test passano, si mergia. Nessuno ha un modello mentale di come funziona dentro. È qui che si accumula il costo reale, ed è l'unico dei tre casi che merita davvero allarme.
Quasi tutte le policy che ho revisionato o vietano tutti e tre o permettono tutti e tre. Sono entrambe risposte sbagliate, e sono entrambe sintomo dello stesso errore: trattare il vibe coding come una questione di tooling invece che come una questione di classificazione del rischio.
Il Numero Che Citano Tutti — e Quello Che Non Cita Nessuno
Il numero presente in ogni presentazione è l'esperimento controllato di GitHub su 95 sviluppatori: circa il 55% di velocità in più nel completamento dei task con un assistente AI. È un risultato reale e non ho nulla da obiettare. La mia obiezione è che misura una sola dimensione — il tempo per arrivare alla prima implementazione funzionante — e il software enterprise non viene giudicato su quella dimensione.
Ecco il quadro più completo, ricavato da ciò che osservo realmente quando un team adotta assistenti AI senza cambiare nient'altro nel proprio modo di lavorare:
| Dimensione | Direzione | Cosa succede realmente |
|---|---|---|
| Tempo al primo codice funzionante | Molto meglio | Il 55% regge. Su questo non c'è discussione. |
| Volume di codice prodotto | In forte aumento | Più codice, diff più grandi, più superficie per ogni pull request. |
| Qualità della code review | In calo | I reviewer affrontano diff 3–4 volte più grandi con lo stesso tempo. L'approvazione diventa una lettura in diagonale. |
| Coerenza architetturale | In calo | Ogni generazione risolve il problema localmente. I pattern divergono silenziosamente tra i moduli. |
| Difetti che sfuggono | In aumento | Bug che passano i test ma violano invarianti non dichiarate — la categoria costosa. |
| Tempo per capire il codice dopo | In forte aumento | Nessuno ha un modello mentale. Il debug riparte da zero ogni volta. |
Letta nel suo insieme, la tabella non lascia dubbi. Il vibe coding non elimina il lavoro ingegneristico: lo sposta più a valle, dalla scrittura alla revisione, al debug e alla manutenzione. Se la tua organizzazione non ha rafforzato in modo corrispondente la capacità di revisione, debug e manutenzione, non hai ottenuto un guadagno di produttività. Hai acceso un prestito.
La Metrica Che Lo Rivela
Smetti di misurare la velocity e inizia a misurare il tempo medio di comprensione: quando un ingegnere che non conosce quel codice apre un file in produzione, quanto passa prima che possa modificarlo in sicurezza? È l'unica metrica che intercetta il debito da vibe coding, perché è l'unica che peggiora al crescere del volume generato. Se peggiora mentre gli story point migliorano, hai la tua risposta.
I Quattro Modi in Cui il Vibe Coding Rompe una Codebase Enterprise
Non sono casi ipotetici. Ognuno dei quattro è qualcosa che sono stato chiamato a diagnosticare, e nessuno di loro si annuncia in anticipo — che è precisamente ciò che li rende costosi.
1. Deriva architetturale
Un modello AI ottimizza per il prompt che ha davanti, non per le diciassette convenzioni che la tua codebase ha accumulato. Chiedi un layer di caching e ottieni un buon layer di caching — che ignora l'astrazione già usata da altri tre moduli. Ripeti quaranta volte e non hai più un'architettura. Hai una collezione di decisioni localmente sensate che nessuno riesce a tenere in testa contemporaneamente. È un fallimento lento, silenzioso, e quando diventa visibile costa una riscrittura.
2. Buchi di sicurezza che sembrano codice pulito
Il codice generato è stilisticamente eccellente, ed è esattamente questo il problema: non sembra sospetto. I casi che vedo tornare più spesso sono controlli di autorizzazione che verificano l'autenticazione ma mai il permesso, validazione dell'input sulla forma ma non sull'intervallo, gestori di errore che espongono dettagli interni nelle risposte, e scelte di dipendenze basate sulla popolarità nei dati di training invece che sullo stato di manutenzione. Un reviewer che cerca odori sospetti non ne trova, perché non ce ne sono. È per questo che la sicurezza by design smette di essere opzionale nel momento in cui adotti l'AI su larga scala.
3. Test che validano l'implementazione, non il requisito
È il fallimento di cui si parla meno e, per mia esperienza, il più pericoloso. Quando lo stesso modello scrive sia il codice sia i test, i test descrivono cosa fa il codice — non cosa serve al business. La copertura sembra ottima. La suite è verde. Ed è strutturalmente incapace di intercettare la classe di bug che conta di più, perché il malinteso è presente in modo identico in entrambi gli artefatti. Test verdi scritti dall'autore del bug non dimostrano nulla.
4. Il vuoto di conoscenza
Storicamente, scrivere un modulo era anche il modo in cui un ingegnere arrivava a capirlo: la fatica era l'apprendimento. Togli la fatica e ti resta l'artefatto ma perdi la comprensione. Sei mesi dopo, la persona che l'ha rilasciato non riesce a spiegarlo, e la capacità reale dell'organizzazione è molto più bassa di quanto la cronologia dei commit suggerisca. Questo è il fallimento che si aggrava più in fretta di tutti, perché degrada proprio la capacità che ti serve per risolvere gli altri tre.
L'Architettura di Guardrail: Sei Livelli Che Funzionano Davvero
Questo è ciò che implemento quando un team vuole mantenere la velocità dell'AI senza accettarne il costo a valle. È deliberatamente noioso, non è costoso, e l'ordine conta — ogni livello presuppone che quello sopra sia già in piedi.
- Codifica le tue convenzioni in un formato leggibile dalla macchina. Decisioni architetturali, regole di naming, librerie approvate e pattern vietati vanno in un file che l'AI legge a ogni richiesta. Dal punto di vista di un modello, una convenzione non documentata è una convenzione che non esiste. Questo singolo passo elimina la maggior parte della deriva architetturale con una giornata di lavoro.
- Separa l'autore del codice dall'autore dei test. Se l'AI genera l'implementazione, i criteri di accettazione li scrive prima una persona — oppure un modello diverso scrive i test partendo dal requisito, mai dal codice. Rompi la correlazione e i test riacquistano la capacità di fallire in modo utile.
- Metti i gate sul blast radius, non sul volume. La dimensione della diff è un indicatore di rischio terribile. Ciò che il codice può raggiungere — denaro, dati personali, autenticazione, contratti esterni, migrazioni — è un buon indicatore. Il prossimo capitolo lo affronta come si deve, perché fa più lavoro degli altri cinque livelli messi insieme.
- Rendi la revisione del codice via AI obbligatoria e avversariale. Passa un secondo modello su ogni diff con l'istruzione esplicita di trovare falle di sicurezza, edge case mancanti e violazioni delle convenzioni — non di riassumere. Costa poco, è veloce, e intercetta una quota significativa di ciò che sfugge a una persona che sta scorrendo. Integra la revisione umana; non la sostituisce mai.
- Fissa una soglia minima di comprensione umana, e imponila nel rituale. La regola che usiamo: un ingegnere non può approvare una diff che non saprebbe difendere in una design review. Non uno slogan — una domanda che viene fatta davvero. È l'unico controllo che affronta direttamente il vuoto di conoscenza.
- Strumenta le invarianti, perché i test non lo faranno. Verifica le regole di business in produzione: i saldi tornano, i totali non sono negativi, ogni azione privilegiata ha un record di audit. Il codice generato dall'AI sbaglia sulle assunzioni non dichiarate, e le assertion a runtime sono l'unico livello che intercetta le assunzioni che nessuno ha pensato di scrivere.
Parti dai Livelli 1 e 3
Se questo trimestre non implementi nient'altro, fai il file di convenzioni leggibile dalla macchina e la classificazione per blast radius. Insieme sono circa due giornate di lavoro e affrontano i due fallimenti — deriva architetturale e accesso non revisionato ai percorsi critici — che causano gli incidenti per cui verrai chiamato davvero.
Il Blast Radius È l'Unica Regola Che Conta Davvero
Quasi tutte le policy sull'AI coding che leggo sono scritte come permessi generalizzati: l'AI è permessa, o non lo è, o è permessa “con revisione”. Tutte e tre sono inutili, perché trattano una pagina di marketing e un ledger di pagamenti come lo stesso oggetto. L'approccio che funziona è classificare la codebase in base a cosa il codice può danneggiare, e impostare il gate per ciascun livello.
| Livello | Cosa contiene | Policy sul vibe coding |
|---|---|---|
| Verde | Tool interni, prototipi, viste admin, script, test su percorsi non critici, documentazione | Nessun vincolo. Rilascia. Non aggiungere processo qui — è dove si guadagna la velocità. |
| Giallo | Feature di prodotto, UI, API non critiche, integrazioni senza dati finanziari o personali | Generazione permessa, revisione umana obbligatoria con la soglia di comprensione applicata. |
| Rosso | Autenticazione e permessi, pagamenti e ledger, dati personali o sanitari, migrazioni, contratti esterni, audit logging | L'AI può proporre una bozza. Una persona con nome e cognome è responsabile, riscrive e firma riga per riga. Nessuna eccezione e nessuna pressione temporale su questo gate. |
In pratica, la classificazione onesta di una tipica codebase enterprise si assesta intorno al 70% verde, 25% giallo, 5% rosso. Ed è tutta qui l'intuizione: puoi fare vibe coding sulla grandissima maggioranza del tuo sistema senza alcuna cerimonia, proprio perché hai reso quel 5% davvero non negoziabile. Le policy generalizzate falliscono perché o strangolano il 70% o espongono il 5%. La classificazione per livelli è ciò che ti permette di smettere di scegliere.
“I team che ottengono più valore dall'AI non sono quelli con le regole più permissive né quelli con le più rigide. Sono quelli che sanno esattamente quale 5% della loro codebase deve restare in mano a una persona.”
— Michele Cimmino · CEO & Fondatore, Lasting Dynamics
Come Funziona su un Team Reale
Qualche dettaglio operativo, perché ai framework è facile annuire ed è difficile farli girare davvero. Nei nostri team in Lasting Dynamics la classificazione vive nel repository stesso: regole basate sui path in CI, così una pull request che tocca una directory di livello rosso richiede automaticamente l'owner designato e non può essere mergiata da nessun altro. La policy non è un documento che le persone dovrebbero ricordare. È una pipeline che si rifiuta.
Il file di convenzioni è trattato come codice di produzione: revisionato, versionato e aggiornato nel momento in cui una decisione architetturale cambia. Quando la deriva emerge in revisione, la correzione non è quasi mai una ramanzina all'ingegnere — è una riga mancante in quel file. Questo cambio di inquadratura conta più di quanto sembri, perché trasforma un problema di disciplina in un problema di documentazione, e i problemi di documentazione sono risolvibili.
La soglia di comprensione, invece, si impone socialmente, non tecnicamente. In design review peschiamo a caso un file mergiato di recente e chiediamo a chi l'ha approvato di spiegarlo. Nessuno viene punito se non ci riesce — ma l'incentivo si corregge quasi subito, e dopo due settimane le approvazioni date in diagonale sono finite. È il controllo che costa meno della lista e quello che fa di più per la capacità di lungo periodo. È lo stesso argomento che porto sul possedere i propri sistemi invece di affittarli: il valore sta nella comprensione che accumuli, non solo nell'artefatto che ti ritrovi in mano.
Se ti interessa il quadro più ampio di come l'AI stia riscrivendo l'economia della delivery e non solo la code review, ne ho scritto una versione rivolta ai founder nella mia guida senza hype all'AI nello sviluppo software. Questo articolo è la controparte enterprise sulla governance: stessa tecnologia, domanda diversa.
Il Rollout in 30 Giorni
Non ti serve un programma di trasformazione. Ti servono quattro settimane e qualcuno con l'autorità di dire no.
- Settimana 1 — Classifica la codebase. Metti i tuoi ingegneri senior in una stanza e classifica ogni directory di primo livello come verde, giallo o rosso. Litigate sui confini: la discussione è la parte di valore. Committate il risultato nel repository.
- Settimana 2 — Scrivi il file di convenzioni. Decisioni architetturali, dipendenze approvate, pattern vietati, naming, gestione degli errori. Collegalo al tooling AI che usa il team, così viene caricato automaticamente invece di essere ricordato.
- Settimana 3 — Collega i gate. Regole CI basate sui path per l'ownership del livello rosso, uno step di revisione AI avversariale su ogni pull request e assertion a runtime sulle tre invarianti di business più importanti.
- Settimana 4 — Installa il rituale e la baseline. Avvia la spiegazione a campione in design review e misura adesso il tempo medio di comprensione, così tra un trimestre avrai un numero con cui confrontarti.
La Parte Che Nessuno Vuole Sentire
Il vibe coding non è una fase e non verrà vietato internamente. I tuoi ingegneri lo stanno usando in questo momento, il guadagno di produttività è reale, e qualsiasi policy costruita sulla proibizione verrà semplicemente aggirata — silenziosamente, da persone in buona fede, sotto pressione di scadenza. Non è un problema di disciplina. È ciò che accade quando una policy rende le persone più lente nel loro lavoro reale.
Ma le aziende che tra tre anni saranno ancora in grado di modificare il proprio software non sono quelle che hanno generato più codice. Sono quelle che sono rimaste in grado di capirlo. La comprensione è la risorsa scarsa adesso — non la velocità di battitura, non il volume di commit, non gli story point. Tutto in questo playbook serve in ultima analisi a proteggerla.
La buona notizia è che niente di tutto questo è costoso o lento. Sei livelli, quattro settimane e una conversazione scomoda su quale 5% del tuo sistema deve restare in mano a una persona. Le organizzazioni che fanno quella conversazione ora rilasceranno alla stessa velocità anche tra due anni. Quelle che la rimandano passeranno quei due anni a spiegare incidenti dentro codice che non ha scritto nessuno.
Il Parere di Michele
Se porti via una cosa sola: l'obiettivo non è rallentare l'AI. È rendere la velocità sostenibile. I guardrail non sono la tassa che paghi per usare l'AI — sono la ragione per cui puoi continuare a usarla in modo aggressivo senza una review trimestrale degli incidenti. Classifica la codebase, proteggi il 5% e lascia che il team voli sul resto.