Vibe Coding vs Ingegneria del Software: Perché la Distinzione Conta

Qualche giorno fa una founder mi ha mostrato un'applicazione web funzionante, costruita in un weekend usando strumenti di coding AI. Nessuna laurea in informatica, nessun bootcamp: solo un'idea chiara e un buon prompt. Devo ammetterlo, era impressionante. Sistema di login, dashboard, persistenza dei dati. Tutto funzionante in meno di 72 ore.

Poi mi ha chiesto di aiutarla a lanciarla per utenti reali.

Lì le cose si sono fatte interessanti.

Il Prototipo Funzionava Perché Lei Era l'Unica Utente

Il problema? Il prototype funzionava perché c'era solo lei a usarlo. Nel momento in cui abbiamo provato ad aggiungere una seconda persona, sono saltati fuori bug di concorrenza. Il database non aveva schema migrations, quindi un rollback avrebbe significato perdere dati. Non c'erano test, il che rendeva qualsiasi refactoring simile a disinnescare una bomba bendati. E il deployment era un processo completamente manuale, senza alcuna documentazione.

Il suo progetto del weekend era un'ottima proof of concept. Non era software pronto per la produzione.

Questo è il punto che la conversazione sul "vibe coding" continua a perdere. Gli strumenti sono reali, la velocità è reale, e la democratizzazione della creazione software è genuinamente eccitante. Ma c'è una differenza tra generare codice e ingegnerizzare software. E quella differenza conta più di quanto la maggior parte delle persone realizzi, finché non si ritrovano a gestire un incidente alle 3 di notte.

La Metrica che Conta Davvero

Ecco la domanda che mi faccio quando vedo codice generato da AI: può essere mergiato in sicurezza in un codebase condiviso?

Non "funziona?" Non "il demo ha funzionato?" Ma proprio mergiato in sicurezza. Quel "sicurezza" porta con sé un peso enorme. Significa che il codice può essere revisionato da qualcuno che non l'ha scritto. Significa che i test verificano il comportamento, non solo che il codice non crashi. Significa che il rollback è possibile senza perdita di dati. Significa che la modifica è abbastanza circoscritta da poterla capire e spiegare.

Quando un vibe coder misura il successo, di solito sta misurando il tempo per arrivare alla prima versione funzionante. È una metrica utile per discovery e prototyping. Ma quando il software entra in un ambiente condiviso, quella metrica smette di essere utile. Ora stai misurando il tempo per un merge sicuro, e quello include il costo della review, la qualità dei test, il rischio di deployment, il overhead di coordinamento e il carico di manutenzione futura.

Un software engineer pensa a quell'intero ciclo di vita fin dall'inizio. Un vibe coder spesso scopre queste preoccupazioni dopo, quando costano di più da affrontare.

Generazione vs Proprietà del Codice

C'è un passaggio sottile ma critico che avviene quando l'AI genera il tuo codice. L'output non è ancora il tuo lavoro. È un punto di partenza che deve essere trasformato in qualcosa che possiedi veramente.

Proprietà significa diverse cose. Puoi spiegare ogni decisione significativa nella modifica. Capisci perché ogni file esiste e cosa fa. Hai circoscritto la modifica a esattamente ciò che serviva, senza boilerplate extra o cleanup non correlati. Hai scritto o verificato test che controllano il comportamento, non solo le metriche di coverage. Hai considerato il percorso di rollback.

Questo è il lavoro che l'AI non può fare per te. L'AI genera. Tu decidi. E "decidi" implica che hai pensato alle alternative, valutato i tradeoffs, e capito le conseguenze.

Quando guardo codice generato da AI che non è stato correttamente appropriato, vedo spesso gli stessi problemi. Modifiche troppo grandi perché il modello ha generato più del necessario. Pacchetti aggiunti senza giustificazione chiara. Test che sembrano scritti per soddisfare uno strumento di coverage piuttosto che per catturare bug reali. Boilerplate che esiste perché il modello defaulta a scaffolding piuttosto che a semplicità.

Nessuno di questi è colpa dell'AI. Sono il risultato di un autore che ha trattato l'output generato come progresso invece che come materia prima.

Il Problema della Review che Nessuno Affronta

C'è qualcosa che mi tiene sveglio la notte: il codice generato da AI cambia l'equazione della review.

Quando un engineer umano scrive codice, di solito c'è una traccia di decisioni. Potresti non essere d'accordo con le loro scelte, ma almeno ci sono decisioni. Puoi chiedere perché hanno usato quell'astrazione, perché la validazione sta lì, perché hanno scelto quella libreria. Le risposte potrebbero essere "non ci ho pensato" o "sembrava ragionevole al momento," ma almeno c'è una persona da chiedere.

Con codice generato da AI, alcune di quelle "decisioni" non sono decisioni affatto. Sono completions. Il modello ha scelto un pattern perché era statisticamente probabile, non perché fosse la scelta giusta per il tuo problema. E se l'autore non ha convertito quella completion in lavoro di cui è proprietario, la review diventa un problema molto più difficile.

Non puoi chiedere al modello perché ha scelto quell'approccio. Non puoi chiedere all'autore perché ha fatto quella decisione se in realtà non lo sa. Quindi la review o tira fuori problemi attraverso dolorosa trial and error, oppure non avviene affatto.

Questo è il motivo per cui credo che la competenza più importante nell'era dello sviluppo assistito da AI non sia il prompting. È la capacità di prendere output generato e trasformarlo in codice che capisci abbastanza profondamente da possedere, spiegare e mantenere.

Cosa Significa Questo per il Tuo Team

Se stai costruendo un prototype per testare un'idea, il vibe coding è un approccio legittimo. La velocità di apprendimento conta quando stai ancora validando assumptions. Usa gli strumenti, muoviti veloce, e costruisci qualcosa da mostrare.

Ma se quel prototype diventerà un prodotto reale, a un certo punto il codice generato deve passare attraverso il filtro di qualcuno che pensa da engineer. Non per fare gatekeeping. Non per rallentare le cose. Ma per assicurarsi che ciò che viene spedito sia codice che può essere capito, mantenuto e fidato da un team.

Spesso vediamo questo pattern. Startup che si muovono velocemente con strumenti AI per validare le loro idee, poi sbattono contro un muro quando hanno bisogno di scalare. Le brave portano dentro help ingegneristica a quel punto. Le altre continuano ad aggiungere feature su un codebase che nessuno capisce veramente.

L'obiettivo non è evitare lo sviluppo assistito da AI. L'obiettivo è essere onesti su dove il lavoro inizia e dove finisce. L'AI può generare codice. Tu devi ingegnerizzare software.

Il Punto della Questione

Il vibe coding è un fantastico punto di partenza. È un modo per testare idee rapidamente, imparare cosa è possibile, e passare da concept a qualcosa di tangibile senza mesi di sviluppo tradizionale.

Ma l'ingegneria del software riguarda l'intero ciclo di vita. Riguarda codice che il tuo team può revisionare, mantenere e di cui fidarsi quando le cose vanno male alle 2 di notte. Riguarda modifiche abbastanza circoscritte da capire e rollbackare se necessario. Riguarda prendersi responsabilità delle decisioni, anche quando quelle decisioni sono state informate da suggerimenti AI.

I migliori developer che conosco stanno usando strumenti AI extensivamente. Lo stanno solo facendo con gli occhi aperti. Sanno che il codice generato è materia prima, non prodotto finito. E sanno che a un certo punto, qualcuno deve fare il lavoro ingegneristico che fa la differenza tra un demo figo e software che puoi realmente spedire.

Quindi sì, continua pure a vibe codare. Costruisci veloce, sperimenta liberamente, usa ogni strumento a disposizione. Solo sappi quando è il momento di passare da vibe a engineering. Il tuo futuro sé, e il tuo futuro team, te ne saranno grati.