Dobbiamo smettere di chiamare tutto Vibe Coding

Sono tornato a programmare dopo una lunga pausa, e Lovable è stato il luogo dove ho ripreso. Le app sembravano ottime, funzionavano a prima vista e si assemblavano in poche ore. All’inizio, era notevole. Ma non è più stato sufficiente nel momento in cui ho voluto capire cosa stesse facendo il codice – e perché. È stato allora che il mio approccio ha iniziato a cambiare.

La differenza non riguarda lo strumento, né quanto codice l’IA scriva per te. Riguarda il contratto che accetti con il tuo output: se puoi spiegare cosa hai appena rilasciato nel mondo, o meno.

Il “vibe coding”, nel suo senso originale, significa accettare software generato dall’IA senza esaminarlo o comprenderlo adeguatamente. Lo sviluppo assistito dall’IA è diverso. Il modello può comunque scrivere la maggior parte del codice, ma la persona che costruisce il sistema rimane responsabile di comprendere il suo comportamento, testare le sue ipotesi e decidere se è pronto per essere distribuito.

Per un esperimento usa e getta che non lascia mai la tua macchina, la distinzione può avere poche conseguenze. Una volta che il software è distribuito, utilizzato da altri o collegato a dati reali, la differenza è enorme.

Come il “Vibe Coding” ha Perso il Suo Significato

Il termine “vibe coding” è stato coniato nel febbraio 2025 da Andrej Karpathy, cofondatore di OpenAI. Il suo esempio era deliberatamente informale: un “progetto weekend usa e getta” costruito cliccando automaticamente su “Accept All”, ignorando le differenze e lasciando che il codice crescesse oltre la sua comprensione.

Settimane dopo, lo sviluppatore e creatore di strumenti Simon Willison notò che il termine veniva usato in modo molto diverso: come sinonimo di qualsiasi programmazione assistita dall’IA, il che, a suo avviso, diluisce il termine e dà un’impressione falsa di ciò che lo sviluppo responsabile assistito dall’IA può realizzare.

Ciò che è significativo è che Karpathy alla fine è stato d’accordo. Un anno dopo, ha introdotto un termine diverso per un lavoro più disciplinato con agenti di codifica. Ha descritto “agentic engineering” come un flusso di lavoro in cui gli sviluppatori dirigono e supervisionano gli agenti invece di accettare semplicemente ciò che producono. La distinzione è importante: lo sviluppo professionale assistito dall’IA richiede pianificazione, scrupolosità e responsabilità in modi che il casual “vibe coding” non prevede.

La Soglia è la Responsabilità

La regola di Willison è semplice, e funziona come test per chiunque: non impegnare codice che non puoi spiegare a qualcun altro. Questo non significa leggere ogni singola riga: con gli agenti che generano centinaia di righe in una volta, anche gli sviluppatori esperti non lo fanno più. Significa comprendere la logica di base e poter giustificare perché il codice fa esattamente quello che fa. Se riesci, non importa se è stato scritto da un modello o da te: non è vibe coding, è usare uno strumento per costruire software.

La ricerca pubblicata nel dicembre 2025 conferma quella distinzione. Basandosi su osservazioni sul campo e su un’indagine qualitativa di sviluppatori professionisti, i ricercatori hanno scoperto che i praticanti esperti mantenevano il controllo sulla progettazione e implementazione del software invece di affidare l’intero processo all’IA. Trattavano gli agenti come collaboratori, pianificavano il loro lavoro con cura e rimanevano coinvolti nella supervisione.

Quindi, l’esperienza da sola non lo spiega. Si tratta di essere disposti a prendersi la responsabilità di ciò che l’IA ha generato. È una decisione che ogni sviluppatore deve prendere ripetutamente in ogni progetto.

Cosa Succede Quando il Controllo Manca

Le conseguenze del rilasciare software senza comprendere o verificare la sua sicurezza non sono astratte. Tea, un’app pensata per aiutare le donne a stare al sicuro durante gli appuntamenti, ha esposto decine di migliaia di foto ID e più di un milione di messaggi privati in due incidenti di sicurezza. I fallimenti includevano un bucket di archiviazione non sicuro e un database separato accessibile senza autenticazione.

Lo stesso problema di fondo – software che sembrava funzionare mentre la sua logica di autorizzazione era pericolosamente errata – è comparso in un’applicazione costruita sulla piattaforma Lovable: una ricerca di sicurezza ha scoperto che la logica di autorizzazione era invertita, bloccando gli utenti autenticati mentre permetteva liberamente l’accesso agli aggressori non autenticati, colpendo più di 18.000 utenti, inclusi studenti.

Questi non sono casi isolati che accadono solo a progetti “cattivi”. Secondo il rapporto DORA 2025 di Google, il 90% degli sviluppatori usa ora l’IA al lavoro, mentre circa un terzo riferisce poca o nessuna fiducia in ciò che genera.

L’uso dell’IA è ora diffuso, anche se la fiducia rimane limitata. E questo rende la revisione accurata particolarmente importante quando il codice generato gestisce autenticazione, autorizzazioni o dati sensibili.

Il Controllo è Costruito a Strati, Non Tutto in Una Volta

Nel mio caso, non ho iniziato con un audit di sicurezza formale. Ho semplicemente rifiutato di procedere ogni volta che non potevo spiegare perché qualcosa si comportava in quel modo – un istinto naturale che porto al lavoro come analista. Mi importa meno della sintassi rispetto al fatto che il risultato corrisponda a ciò di cui avevamo originariamente bisogno. Quando non lo fa, continuo a scavare.

Il mio flusso di lavoro è diventato più strutturato man mano che i progetti diventavano più seri. Invece di affidarmi solo ai prompt, ho iniziato a preparare specifiche prima di generare qualsiasi cosa. Ho documentato i requisiti di business, lo stack tecnologico e le integrazioni. Poi sono arrivati i test unitari e i test Playwright per i principali percorsi utente.

I controlli di sicurezza sono stati aggiunti in modo simile. Ho revisionato le librerie selezionate dall’IA e ho introdotto la scansione malware per i file caricati. Ogni controllo nasceva dalla domanda su cosa potesse andare storto successivamente, piuttosto che seguire una lista di controllo preparata in anticipo.

Questa abitudine ha individuato un problema in un progetto. L’IA ha introdotto una libreria incompatibile con la versione del framework che stavo usando. L’applicazione non era fallita completamente, quindi l’incompatibilità avrebbe potuto passare inosservata. Trovarla più tardi avrebbe reso la causa molto più difficile da identificare.

Rispetto ai casi di Tea e Lovable, questo era un problema ordinario. L’ho trovato presto, l’ho corretto e sono andato avanti. È così che la revisione appare in pratica. Nella maggior parte dei casi, impedisce che piccoli problemi si trasformino in problemi più grandi.

Non diffido del codice solo perché prodotto dall’IA. Non mi fido nemmeno solo perché l’applicazione funziona. Test e revisione sono il modo in cui verifico se si comporta come previsto.

Dal Vibe Coding all’Agentic Engineering

Il passaggio di Karpathy da “vibe coding” a “agentic engineering” non è solo un cambiamento di vocabolario. “Agentic engineering” ci offre un nome più utile per la direzione che lo sviluppo professionale sta prendendo. Gli sviluppatori possono scrivere meno righe personalmente, ma ciò non riduce la loro responsabilità. Sposta il loro lavoro verso la specifica di ciò che il sistema dovrebbe fare, la direzione degli agenti, il test del loro output e la decisione su cosa sia sicuro da rilasciare.

Il pericolo non è che l’IA generi codice rapidamente. È che la generazione può superare la comprensione. Quando ciò accade, la produttività apparente nasconde rischi che nessuno ha esaminato adeguatamente.

Una Regola da Mantenere

Smetti di usare “vibe coding” come etichetta per ogni forma di sviluppo assistito dall’IA – diluisce il termine e cancella una distinzione di controllo che è importante. Stabilisci una regola semplice: non rilasciare ciò che non puoi spiegare. E costruisci il controllo nel progetto man mano che cresce, strato dopo strato, aggiungendo verifiche in linea con i rischi che emergono.

L’IA può scrivere la maggior parte del codice. Non può assumersi la responsabilità di rilasciarlo. Questo resta a noi.