Vibe coding vs sviluppo assistito da AI: non è la stessa cosa

Il problema non è l'AI. Sei tu.

C'è una scena in quasi ogni film di fantascienza in cui qualcuno preme un bottone senza sapere cosa fa, perché "sembra giusto". Di solito finisce male. Il vibe coding funziona esattamente così, solo che al posto dell'astronave esplode il tuo progetto in produzione, preferibilmente un venerdì sera.

Il termine "vibe coding" è stato coniato da Andrej Karpathy all'inizio del 2025 per descrivere un approccio allo sviluppo in cui ci si affida quasi completamente all'output del modello linguistico, accettando il codice generato con poche o nessuna verifica, lasciando che sia l'AI a guidare le scelte architetturali e ignorando sistematicamente warning e anomalie perché "tanto funziona". Karpathy lo descriveva come un modo di sperimentare, quasi un gioco. Il problema è che nel giro di settimane il termine è stato adottato da un'intera categoria di persone che lo praticano su progetti reali, con utenti reali, e dati reali.

Questa è la differenza tra vibe coding e sviluppo assistito da intelligenza artificiale: una è una modalità operativa, l'altra è una filosofia professionale. Confonderle costa caro.

Cosa succede davvero quando fai vibe coding

Il vibe coder apre il suo strumento preferito, scrive un prompt, ottiene del codice, lo incolla, vede che "gira" e va avanti. Il ciclo si ripete. L'architettura emerge per accrezione, non per progettazione. Le dipendenze si moltiplicano perché ogni prompt risolve un problema locale senza visione globale. I test non esistono o esistono solo perché li ha generati l'AI stessa, il che è un po' come chiedere allo stesso studente di correggere il proprio compito.

Il risultato tipico è un codebase che funziona finché non devi toccarlo. Aggiungere una feature diventa un'operazione di archeologia. Il debug è un'esperienza esistenziale. E quando qualcosa va storto in produzione, nessuno sa esattamente perché il sistema fa quello che fa, perché nessuno ha mai letto il codice con l'intenzione di capirlo davvero.

Non è un problema di intelligenza artificiale. È un problema di delega totale del ragionamento a uno strumento che, per quanto straordinario, non ha contesto sul tuo dominio, sui tuoi utenti, sui tuoi vincoli di sicurezza, sui tuoi requisiti di performance. Il modello non sa che quella funzione verrà chiamata diecimila volte al minuto. Tu sì. O dovresti.

Come funziona lo sviluppo AI-assisted fatto bene

Lo sviluppo assistito da intelligenza artificiale professionale parte da un presupposto diverso: l'AI è uno strumento potente, non un collega senior con responsabilità sul progetto. La differenza cambia tutto il workflow.

Prima di scrivere un singolo prompt, chi lavora bene ha già in testa, o su carta, la struttura di quello che sta costruendo. Sa quali moduli esistono, come comunicano, dove stanno i confini del sistema. L'AI entra a riempire pezzi ben definiti, non a inventare l'architettura dal niente. Questo è il punto che il vibe coding salta completamente, e non è un dettaglio.

Il prompt engineering per sviluppatori professionali non significa scrivere prompt più lunghi o più "magici". Significa fornire contesto preciso: il linguaggio, il framework, i vincoli, lo stile del codebase esistente, i casi limite da gestire. Un prompt scritto bene ottiene output che richiede revisione minima. Un prompt vago ottiene output che sembra plausibile ma nasconde assunzioni sbagliate nel mezzo.

Poi c'è la review. Sempre. Il codice generato dall'AI viene letto, compreso, e integrato consapevolmente. Non per sfiducia paranoica nello strumento, ma perché chi fa la review impara, mantiene la ownership del codice e intercetta i problemi prima che diventino incidenti. Un senior developer che usa AI in modo professionale è più veloce di prima, non meno attento di prima.

I test non sono opzionali e non vengono scritti dall'AI su richiesta generica. Vengono progettati da chi conosce il comportamento atteso del sistema. L'AI può aiutare a scriverli, certo, ma la logica dei casi di test viene da una comprensione umana del dominio.

Il workflow concreto che fa la differenza

Per chi vuole qualcosa di applicabile subito, ecco come si struttura un workflow di sviluppo con AI che non si trasforma in debito tecnico entro tre mesi.

• Definisci l'architettura prima di aprire il modello. Anche uno schizzo su carta va bene. Sai cosa stai costruendo, quali sono le responsabilità di ogni componente, dove passano i dati. L'AI lavora dentro queste scatole, non le inventa.
• Scrivi prompt contestualizzati, non richieste generiche. "Scrivi una funzione che fa X in Python usando FastAPI, seguendo questo pattern che già usiamo nel progetto, gestendo questi tre casi limite" è un prompt. "Scrivi del codice per gestire le autenticazioni" è un desiderio.
• Leggi tutto il codice che integri. Non è negoziabile. Non devi necessariamente riscriverlo, ma devi capire cosa fa e perché. Se non lo capisci, è un segnale che il prompt era troppo vago o che il problema era troppo grande per essere affrontato in una singola generazione.
• Usa l'AI per i test, ma decidi tu i casi. Elenca i comportamenti attesi, i casi limite, gli scenari di errore. Poi chiedi all'AI di scrivere i test per quella lista. Non chiedere "scrivi i test per questa funzione" e accettare quello che arriva.
• Fai review dell'output come faresti con un junior bravo ma inesperto sul tuo dominio. Capisce la sintassi meglio di chiunque. Non capisce il tuo contesto di business. Trattalo di conseguenza.
• Mantieni un documento di decisioni architetturali. Ogni volta che fai una scelta non ovvia, scrivila. Questo ti salva quando tra sei mesi torni su quel codice e non ricordi perché hai fatto quella cosa strana ma necessaria.

La distinzione non è tra chi usa l'AI e chi non la usa. Quella battaglia è già finita. La distinzione è tra chi integra l'AI nel proprio processo di pensiero e chi sostituisce il proprio processo di pensiero con l'AI. Il secondo gruppo produce software che funziona nella demo e implode in produzione.

Perché questa distinzione conta di più adesso che sei mesi fa

Gli strumenti sono diventati abbastanza bravi da rendere il vibe coding accessibile a persone senza nessuna esperienza di sviluppo. Questo è straordinario e preoccupante allo stesso tempo, non perché l'accesso sia un problema, ma perché abbassa la soglia di percezione del rischio.

Quando il codice generato compila e sembra funzionare, la tentazione di fermarsi lì è fortissima. Il problema è che "funziona sulla mia macchina in condizioni ideali" e "è pronto per gestire traffico reale con dati reali e utenti che fanno cose impreviste" sono due affermazioni molto distanti. Il vibe coding collassa questa distanza fingendo che non esista.

Lo sviluppo AI-assisted professionale, al contrario, usa la velocità guadagnata per fare meglio le cose che prima si saltavano per mancanza di tempo: più test, più documentazione, più riflessione sull'architettura, più iterazioni di design. L'AI accelera l'esecuzione; il professionista usa quel tempo per alzare la qualità complessiva, non per tagliare ulteriori angoli.

Come avrebbe detto qualcuno di molto più famoso di me: con grandi strumenti arrivano grandi responsabilità. E la responsabilità, nel software, non è mai delegabile a un modello linguistico, per quanto impressionante.

Alina, AI Analyst di Inceptio