Pubblicato il 30 Dic 2025 - Aggiornato il 2 Giu 2026

Vibe Coding: programmare sapendo che l’AI può generare illusioni e rischi

AI

Fermati un istante prima di iniziare la lettura dell’articolo e rifletti: nel tuo lavoro con l’AI, cosa stai costruendo?

Stai costruendo competenza o stai costruendo un’immagine di competenza? E, soprattutto, per chi la stai costruendo?

Prima di proseguire, una precisazione.

Questo articolo non nasce da una posizione contraria all’AI. Mi piace programmare e mi divertivo a scrivere codice molto prima che arrivassero ChatGPT, Claude o Cursor. Continuo a farlo oggi.

Proprio per questo riesco a capire perfettamente il fascino del vibe coding. Vedere un’idea prendere forma in pochi minuti è entusiasmante. Ti dà la sensazione di poter costruire qualsiasi cosa. 🙂

Quello che mi interessa analizzare non è lo strumento, ma il modo in cui lo utilizziamo.

Se stai iniziando senza basi tecniche solide, ci sono aspetti che meritano più attenzione di altri. Non perché tutto debba essere perfetto o professionale fin dal primo giorno, ma perché alcuni errori rimangono invisibili finché qualcuno non te lo dice o qualcosa non si rompe.

Nelle prossime sezioni troverai alcune mie riflessioni su cosa stiamo realmente costruendo quando deleghiamo sempre più parti del processo di sviluppo a un modello linguistico.

Cos’è il vibe coding

Il Vibe Coding è l’atto di generare codice che produce l’effetto desiderato utilizzando strumenti di intelligenza artificiale (AI), come i Large Language Models (LLMs), spesso in assenza di una conoscenza approfondita delle basi tecniche.

Si parla di “codice che produce l’effetto desiderato” quando l’output (ad esempio, una pagina web visibile, una formula complessa o uno script automatizzato) soddisfa la richiesta superficiale, senza che sia necessario padroneggiare o comprendere la logica sottostante, l’architettura o le potenziali implicazioni di sicurezza.

In questa dinamica, l’AI non agisce da assistente per potenziare una competenza esistente, ma da sostituto della comprensione tecnica. 

L’obiettivo primario diventa ottenere un risultato immediato e condivisibile (il vibe) anziché investire nel processo di apprendimento e padronanza (coding). 

Questo permette a professionisti e professioniste come marketer, designer o founder di produrre rapidamente output digitali, trasformando lo sviluppo software in una vera e propria performance destinata al consumo sui social.

Per approfondire: Vibe Coding in Practice: Motivations, Challenges, and a Future Outlook – a Grey Literature Review

Dal risultato immediato all’illusione di competenza

Il vibe coding diventa rischioso nel momento in cui il saper far funzionare qualcosa diventa un sostituto illusorio del capire perché funziona.

L’AI ti restituisce codice che fa esattamente quello che hai chiesto, e quel risultato immediato crea una sensazione di controllo. Ma quella sensazione è ingannevole. 

Senza attraversare il processo di apprendimento tradizionale, dove sbagli, debuggi, capisci perché una soluzione è migliore di un’altra, non costruisci la capacità di valutare cosa stai creando.

Il problema non è solo la mancanza di esperienza tecnica pregressa. Quando generi una pagina web con tre righe di prompt, salti tutto il contesto che ti permetterebbe di capire perché certe scelte esistono, quali problemi risolvono, quali vulnerabilità introducono. 

L’AI ti dà un risultato, ma non ti dà la mappa del territorio che stai attraversando.

Da non sottovalutare poi una dinamica ancora più sottile, chi usa il vibe coding spesso sta costruendo due cose contemporaneamente: 

1. la prima è il progetto tecnico;
2. la seconda è un’identità professionale in uno scenario dove la competenza tecnica è diventata capitale sociale. 

Condividere codice, parlare di framework, mostrare progetti funzionanti sui social non è solo documentare un processo, è affermare appartenenza a un mondo percepito come innovativo e prestigioso. Il bisogno di essere visti come competenti può sovrapporsi, e a volte sostituire, il processo di diventare competenti.

Competenza tecnica e capitale sociale

C’è una tensione profonda tra il desiderio di appartenere a una community percepita come tecnologicamente avanzata e la consapevolezza, spesso inconscia, di non avere le basi per farlo. 

Il mondo dello sviluppo software è avvolto da un’aura di prestigio: innovativo, ben pagato. Condividere codice, parlare di framework, mostrare progetti è un modo per dire “io sono parte di questo mondo”. Ma quando quella partecipazione è costruita sulla generazione automatica senza comprensione, diventa una proiezione identitaria.

Il problema non è costruire un’immagine professionale in sé. Tutti costruiamo un’immagine online. Il problema è quando questa proiezione sostituisce completamente l’apprendimento, quando il bisogno di essere visti come competenti prevale sul bisogno di diventare competenti. 

⚠️ Ciò accade perché i social media amplificano costantemente il confronto. Vedi qualcuno che posta il suo nuovo progetto, qualcun altro che parla di tecnologie che non conosci, qualcuno che sembra avere successo facile con l’AI. La pressione a stare al passo è costante.

Nel vibe coding questo meccanismo si intensifica, non solo ti confronti con gli altri, ma ti confronti con una versione idealizzata di te stesso che l’AI ti ha permesso di proiettare.

Hai pubblicato una landing page, ma sai che non sapresti modificarla se qualcosa andasse storto; hai condiviso un’app, ma sai che non hai idea di come funzioni sotto la superficie.

Così emerge la questione centrale: quale spazio vuoi che la competenza tecnica occupi nella tua identità professionale, e quanto di quello spazio sei disposto a riempire con illusione? 

Non è una domanda facile, perché implica ammettere vulnerabilità in un ambiente che premia costantemente la sicurezza.

Best practice nel vibe coding

Uno degli errori più comuni nel vibe coding è pensare che basti descrivere il risultato desiderato.

In realtà, più il progetto cresce, più la qualità dell’output dipende dalla qualità dei vincoli che dai all’AI.

Se chiedi di creare una semplice landing page, lasciare libertà totale può anche funzionare. Se però l’obiettivo è pubblicare qualcosa online, raccogliere dati o integrare servizi esterni, il livello di precisione del prompt cambia completamente.

Ho visto persone generare una pagina vetrina con React, TypeScript, decine di dipendenze e una complessità che non aveva alcuna giustificazione reale. Per una pagina che mostra contenuti e raccoglie un contatto spesso bastano HTML, CSS e JavaScript.

In quel caso una richiesta come questa produce quasi sempre risultati migliori:

Realizza una landing page responsive usando solo HTML, CSS e JavaScript. Evita framework, build system e dipendenze non necessarie. Il codice deve essere semplice da leggere e modificare.

Al contrario, quando entri nel territorio di API, database, autenticazione e gestione dati, la semplicità apparente rischia di diventare un problema.

Una richiesta generica come “creami un sistema CRUD” lascia all’AI troppe decisioni da prendere. Meglio specificare stack, struttura e responsabilità.

Crea una API CRUD in Python usando FastAPI. Separa logica applicativa, validazione e accesso ai dati. Gestisci errori, validazione degli input e configurazione tramite variabili d'ambiente.

La stessa attenzione vale per aspetti che sembrano secondari.

Se non dici nulla sull’interfaccia, spesso l’AI riempie il progetto di emoji. Se vuoi un risultato più professionale devi esplicitarlo.

Utilizza Lucide React o Material Design Icons. Non usare emoji come elementi dell'interfaccia.

La sicurezza merita un discorso a parte.

Una delle cose che incontro più spesso nei progetti generati con l’AI è la presenza di chiavi API direttamente nel frontend. Funziona. Almeno finché qualcuno non apre gli strumenti del browser e copia le credenziali.

Ho visto applicazioni che esponevano senza alcuna protezione token OpenAI, chiavi di servizi terzi e configurazioni che non dovrebbero mai arrivare sul client.

L’AI non sta facendo qualcosa di sbagliato. Sta semplicemente eseguendo la richiesta nel modo più rapido possibile.

Per questo, quando il progetto inizia a gestire dati, autenticazione o servizi esterni, conviene introdurre vincoli espliciti.

Nessuna chiave API deve essere presente nel frontend. Tutte le chiamate a servizi esterni devono passare da un backend. Usa variabili d'ambiente lato server e indica eventuali criticità di sicurezza prima di generare il codice.

Il paradosso è che più esperienza hai, più i prompt diventano lunghi.

Non perché sai programmare meglio dell’AI, ma perché sai dove i problemi tendono a nascondersi.

Performance, manutenzione, accessibilità, gestione degli errori, sicurezza, dipendenze inutili: sono tutti aspetti che raramente emergono da una richiesta superficiale.

E forse è proprio qui che passa la differenza tra usare l’AI come acceleratore e usarla come sostituto della comprensione.

Il risultato finale può sembrare identico.

Quello che cambia è la probabilità che quel progetto continui a funzionare anche tra sei mesi.

Il doppio sguardo

C’è un altro lato della medaglia. Quando pubblichi contenuti di vibe coding, qualcuno li guarda. Qualcuno che magari sta considerando di imparare a programmare, o che sta valutando se affidarsi a te per un progetto. E quello che vede non è necessariamente quello che c’è.

La percezione funziona in modo bidirezionale. Chi guarda interpreta attraverso il proprio filtro di bisogni, aspettative, paure. Vede una landing page funzionante e pensa “questa persona sa fare siti web”. 

Non vede che quella pagina è stata generata senza comprensione, che non può essere mantenuta, che collasserebbe al primo tentativo di scalare o integrare con sistemi esistenti. 

Il gap tra apparenza e sostanza crea aspettative che non possono essere soddisfatte.

Questo diventa particolarmente problematico quando il vibe coding entra in contesti professionali con il no code e l’AI. 

Un mio cliente, ha sperimentato questo limite in modo concreto nel design: generava landing page con l’AI, ma ogni pagina usciva diversa dalle altre. 

Colori sbagliati, layout che non rispettavano il design system esistente, componenti che si comportavano in modo imprevedibile. Quando devi costruire un sito coerente, quella variabilità diventa un problema serio. E il tempo risparmiato lo impieghi per fixare i bug delle nuove pagina create sempre con lo stesso prompt.

L’AI genera soluzioni funzionali isolate, non capisce il contesto più ampio di un progetto con identità visiva definita, convenzioni di codice, requisiti di accessibilità.

La lezione qui è semplice: il vibe coding funziona finché le aspettative rimangono basse e il contesto rimane semplice. Nel momento in cui qualcuno si affida a quello che hai costruito, un cliente, un utente, un collega, la fragilità emerge.

Vibe coding quando funziona, quando crolla

Attenzione: non tutto nel vibe coding è illusione. 

Ci sono situazioni in cui questa modalità è potente e legittima. 

• Costruire prototipi per testare idee velocemente; 
• creare tool interni per automatizzare task ripetitivi;
• esplorare cosa è possibile fare con una tecnologia prima di investire tempo nell’apprendimento formale. 

In questi casi, la barriera d’ingresso bassissima è un vantaggio netto: ti permette di validare concetti, sperimentare, mantenere la motivazione alta attraverso un feedback immediato.

Il problema è riconoscere quando il contesto cambia. Quando quello che hai iniziato come esperimento diventa qualcosa che altre persone usano. 

Quando il prototipo veloce viene fatta diventare una feature in produzione, oppure quando il tool interno diventa mission-critical per il business. In queste fasi, il deficit di conoscenza tecnica non può più essere visto con leggerezza, qui c’è un chiaro rischio strutturale e operativo.

Senza basi tecniche, non riesci a fare debug. Quando qualcosa si rompe, e nel software le cose si rompono sempre, non sai dove guardare. Gli errori sono vaghi, le reazioni del sistema sono imprevedibili, i bug intermittenti. L’AI può provare a suggerire soluzioni, ma senza capacità di valutazione, non sai se la soluzione è corretta o sta solo mascherando un problema più profondo. Questa dipendenza totale dagli strumenti diventa paralizzante.

Poi ci sono questioni di sicurezza. Chi non ha basi spesso ignora completamente gestione delle chiavi API, validazione degli input, controllo degli accessi, privacy dei dati. L’AI genera codice che funziona, ma non ti avverte quando quel codice espone a vulnerabilità. 

Pubblicare un’app, attraverso piattaforme come Replit, senza capire determinati aspetti è come costruire una casa senza fondamenta, può stare in piedi per un po’, ma al primo stress collassa.

Il codice generato senza comprensione tende a essere fragile e poco scalabile e se il progetto cresce, le funzionalità si accumulano, a un certo punto tutto diventa un groviglio incomprensibile, non solo per te, ma anche per l’AI che ti ha aiutato a crearlo. A quel punto, l’unica soluzione è spesso ricominciare da zero con un approccio più strutturato.

Costruire consapevolezza e imparare oltre l’output AI

La vera domanda non è se il vibe coding sia buono o cattivo. 

La domanda è: cosa stai costruendo, e perché? 

Se stai sperimentando per curiosità, è perfetto. Se stai validando un’idea prima di investire, ottimo. Se stai creando contenuto per apparire competente senza esserlo, c’è un problema.

La consapevolezza dei propri limiti non è debolezza, anzi, e te lo dico per esperienza, è l’unica cosa che ti permette di crescere. 

Quando ammetti che non sai come funziona il codice che hai generato, puoi iniziare a imparare. 

Quando riconosci che la tua motivazione include bisogno di riconoscimento sociale, puoi separare quel bisogno dall’apprendimento vero.

Anche le conoscenze di base cambiano tutto. Capire cos’è una funzione, cos’è uno stato, come funziona un’API, come leggere un errore, queste basi riducono l’80% delle complicazioni. Non sto dicendo che serve diventare ingegneri software per usare l’AI in modo responsabile, ma serve capire abbastanza da riconoscere quando stai andando oltre i tuoi limiti.

Ti dirò che il vibe coding può essere un amplificatore mentre impari. Usalo per accelerare, e non per fingere. Usalo per esplorare, e non per nascondere lacune. E quando pubblichi risultati generati dall’AI, chiediti se stai condividendo un processo di apprendimento o se stai costruendo una facciata.

Perché alla fine, quando costruisci qualcosa che poi crolla, per te o per un cliente, le conseguenze sono concrete. Se il progetto non regge, devi trovare il tempo per ricostruirlo, perdendo ore (o giorni) che avresti potuto investire altrove. Se crolla per un cliente, perdi reputazione, posizionamento, e spesso la relazione stessa. 

Il danno economico è bidirezionale: per te, che devi recuperare, e per chi si è affidato a quello che hai costruito. 

Resta solo da capire quanto sei disposto o disposta a rischiare costruendo su fondamenta che non comprendi, e questa valutazione, a differenza del codice generato, non puoi delegarla a nessuna AI.

Mirko Ciesco

Data-Driven Growth Specialist

Aiuto aziende e startup a prendere decisioni migliori per crescere in modo misurabile. Sono specializzato in Web Analytics e performance digitale e lavoro all’intersezione tra dati, strategia e crescita.