Perché il software generato dall'IA ha ancora bisogno di revisione ingegneristica

Andrej Karpathy ha coniato il termine vibe coding nel febbraio 2025 per descrivere una modalità di sviluppo software in cui si descrive ciò che si vuole, si accetta ciò che l'IA produce e non si legge il codice. La sua formulazione era generosa - una modalità hobby del fine settimana per progetti personali. Ciò che è seguito non lo era. Entro la metà del 2025, un'ondata di non-ingegneri aveva pubblicato app SaaS di produzione costruite interamente in Cursor, Replit Agent, v0 e bolt.new, senza mai capire cosa avevano costruito. Le app sembravano buone nelle demo. Alcune stanno andando in pezzi in produzione.

Cosa sia realmente il vibe coding

La descrizione originale di Karpathy è precisa: si è «nella zona», si dice all'IA cosa si vuole, lei produce codice, si preme per lo più accetta e non si capisce completamente cosa sta girando. Lo ha riconosciuto esplicitamente - «Non leggo il codice, ci vibo e basta.» Per uno strumento personale o un prototipo usa e getta, va bene. Il vibe coder non pretende di essere un ingegnere. Il problema è che l'ecosistema di strumenti - lo «ship your startup in a weekend» di Replit Agent, i deploy con un clic di v0, la generazione full-stack istantanea di bolt.new - ha confezionato questa modalità come un percorso legittimo verso il software di produzione.

Non lo è. E il debito tecnico risultante è qualitativamente diverso dal normale codice scadente.

Perché il vibe code è peggio del codice scritto male a mano

Quando uno sviluppatore junior scrive codice scadente, capisce cosa intendeva fare. Si può sedersi con lui, tracciare la logica e correggerlo. Quando un'IA genera codice scadente che l'operatore non ha mai letto, non c'è nessun modello mentale da recuperare. Lo sviluppatore non può spiegare perché l'autenticazione è strutturata nel modo in cui lo è, perché non ha mai letto l'autenticazione. Non può dirvi quale libreria di terze parti gestisce i pagamenti, perché ha accettato il file senza aprirlo. Il codice è una scatola nera che possiede ma su cui non può ragionare.

I pattern di guasto che vediamo costantemente nelle app di produzione generate dall'IA:

• Bypass di autenticazione incorporati nello scaffold; segreti JWT presenti in esempi di variabili d'ambiente committati in repository pubblici — questi sono rilievi comuni nelle revisioni del codice di progetti assistiti dall'IA senza supervisione ingegneristica. Il codice di autenticazione generato dall'IA copia frequentemente pattern dai dati di addestramento senza comprendere il modello di sicurezza. Sicurezza a livello di riga disabilitata «temporaneamente» durante lo sviluppo, lasciata in produzione. Controlli di ruolo che confrontano letterali stringa e si rompono nel momento in cui un campo viene rinominato.

• Nessuna gestione degli errori oltre il percorso felice. L'IA ha scritto il caso di successo. Cosa succede quando il fornitore di pagamenti restituisce un 402? Cosa succede quando la connessione al database cade a metà di una transazione? Nelle app vibe-coded, la risposta è solitamente un rifiuto di promise non gestito che appare come uno schermo bianco.

• Lock-in del fornitore sui pattern generati dall'IA. Quando l'IA ha scelto di strutturare il modello di dati in un certo modo, il vibe coder lo ha accettato. Ora l'intera app è costruita attorno a quella struttura. Migrare via da essa richiede di capire il codice che lo sviluppatore non ha mai letto.

• Nessun test. Non perché i test siano difficili, ma perché il vibe coder non li ha mai richiesti e l'IA non li ha offerti spontaneamente. Quando qualcosa si rompe in produzione, non c'è nessuna suite di test per rilevare le regressioni nella correzione.

Il divario demo-verso-produzione

Gli strumenti IA sono genuinamente bravi a generare codice che funziona su un percorso felice con input puliti, una rete cooperativa e un singolo utente concorrente. Questa è esattamente la condizione in cui gira una demo. La produzione è l'opposto: input malformati, connessioni interrotte, scritture concorrenti, casi limite che non sono mai stati specificati nel prompt.

Il pattern si svolge in modo prevedibile. Un'app vibe-coded viene lanciata, sembra rifinita, ottiene i primi utenti. Poi: un utente con un carattere non-ASCII nel nome rompe la query del database. Un utente mobile su una connessione lenta innesca una race condition nella gestione dello stato. Abbiamo visto scenari in cui gli endpoint API espongono dati tra account utente diversi perché i controlli di autorizzazione erano assenti o incompleti — conseguenza della consegna di codice mai verificato per l'applicazione lato server. Non sono guasti esotici. Sono la conseguenza basilare della consegna di codice che non si è mai letto.

L'IA rende migliori i bravi ingegneri - non rende inutili i cattivi ingegneri

Questa è l'affermazione che la narrativa del vibe coding inverte. Gli strumenti sono reali e i guadagni di produttività sono reali. In webvise, usiamo Claude Code, Cursor e l'orchestrazione multi-agent su ogni progetto che consegniamo. Gli ingegneri senior che utilizzano Claude Code riportano risparmi di tempo significativi su attività che altrimenti richiederebbero giorni. Gli stessi strumenti nelle mani di qualcuno senza fondamenti ingegneristici producono una demo che non sopravvive al suo primo utente reale.

La differenza non è nello strumento - è in ciò che l'ingegnere porta allo strumento. I fondamenti ingegneristici non riguardano la scrittura di codice a mano. Riguardano la comprensione dei confini di sistema, dei modi di guasto, dei modelli di sicurezza e dell'integrità dei dati. Un ingegnere che usa Claude Code legge il codice di autenticazione generato e riconosce quando è sbagliato. Uno sviluppatore inesperto accetta il suggerimento e lo consegna.

Il rischio specifico per il software aziendale

Le app hobby per i consumatori possono assorbire i modi di guasto del vibe coding. Se un tracker di finanze personali perde alcuni dati, è fastidioso. Se un SaaS B2B che gestisce record di clienti, flussi di pagamento o flussi di lavoro interni viene consegnato con i problemi di autenticazione e gestione degli errori descritti sopra, le conseguenze sono legali, contrattuali e reputazionali. La responsabilità ai sensi del GDPR si applica indipendentemente da come è stato generato il codice; il codice di gestione dei dati richiede revisione.

Diversi recenti prodotti SaaS assistiti dall'IA hanno seguito uno schema simile: impressionanti in una demo, hanno acquisito clienti precoci sulla promessa, poi hanno urtato un muro quando il primo prospect enterprise ha eseguito una revisione della sicurezza o il primo giorno di alto traffico ha esposto la gestione degli errori mancante. I fondatori non sono truffatori - genuinamente non sapevano cosa avevano costruito.

Cosa cercare in un partner di sviluppo potenziato dall'IA

Se state valutando un partner di sviluppo che afferma di usare strumenti IA, ponete queste domande:

• Eseguono test automatizzati sul codice generato dall'IA? Se la risposta è «ci fidiamo dell'output dell'IA», andate altrove. La copertura dei test è il modo per rilevare la gestione degli errori che l'IA ha omesso.

• Eseguono revisioni della sicurezza sul codice di autenticazione e autorizzazione generato? Gli strumenti IA copiano pattern di auth dai dati di addestramento. Quei pattern includono vulnerabilità reali da codebase reali.

• Possono spiegare l'architettura di ciò che hanno costruito? Se uno sviluppatore non riesce a guidarvi attraverso il modello di dati e a spiegare perché è strutturato nel modo in cui lo è, non lo ha progettato - lo ha accettato.

• Versionano i loro prompt insieme al codice? La disciplina ingegneristica applicata agli strumenti IA significa trattare il prompt come parte della codebase, non come un input usa e getta.

• Hanno un processo per gestire le allucinazioni dell'IA? Gli strumenti IA generano con sicurezza chiamate API errate, metodi deprecati e funzioni di libreria inesistenti. Un team esperto ha un ciclo di revisione per questo. Un vibe coder lo scopre a runtime.

Il quadro corretto: l'IA come moltiplicatore di forza, non come sostituto

La narrativa del vibe coding è seducente perché è parzialmente vera. Gli strumenti IA hanno genuinamente abbassato la soglia per la costruzione di software. Un non-ingegnere motivato può consegnare un prototipo funzionante in un fine settimana. Questo è prezioso per la validazione, gli MVP, il tooling interno a basso rischio. L'errore è trattare il pavimento come il soffitto - assumere che poiché si può far funzionare qualcosa, lo si può far funzionare in modo affidabile alla scala, in modo sicuro e manutenibile.

Gli ingegneri che hanno beneficiato di più degli strumenti di codifica IA sono quelli che li usano per eliminare le parti noiose dell'ingegneria - boilerplate, scaffolding, refactor ripetitivi - mentre applicano il loro giudizio alle parti che contano: architettura, sicurezza, gestione degli errori e prontezza alla produzione. L'IA accelera il lavoro. L'ingegnere si assicura che sia corretto.

In webvise, utilizziamo lo sviluppo potenziato dall'IA su ogni progetto - Claude Code, Cursor, pipeline multi-agent - ma con la disciplina ingegneristica che rende l'output pronto per la produzione. Se state costruendo software che deve sopravvivere a utenti reali, casi limite reali e requisiti di sicurezza reali, parliamo di come lavoriamo.