Che cos'è il vibe coding?

Il vibe coding è un flusso di lavoro in cui si costruisce software dando prompt a un’IA e accettando il codice generato in gran parte senza revisione. Andrej Karpathy ha coniato il termine nel febbraio 2025 – “fully give in to the vibes, embrace exponentials, and forget that the code even exists” – descrivendo l’accettare ogni modifica senza leggere i diff, su “progetti usa e getta del fine settimana”. In un anno il termine è scivolato a sinonimo di qualsiasi programmazione con l’IA; questa voce ne conserva il senso preciso, perché è lì che vive il giudizio ingegneristico: il tratto distintivo non è usare l’IA – è non rileggere ciò che l’IA ha scritto.

Punti chiave

Il ciclo, e la linea di demarcazione

Il flusso di lavoro è un ciclo stretto: descrivere → l’IA genera → eseguire → reincollare errori o nuovi desideri → ripetere, trattando la codebase come un problema dell’IA. Simon Willison ha tracciato la linea che mantiene utile il termine: se ogni modifica è stata riletta, testata e si è in grado di spiegarla a qualcun altro, “non è vibe coding – è sviluppo software”. La distinzione non è gatekeeping; è un’etichetta di rischio. Lo stesso ciclo con revisione è ingegneria assistita dall’IA, e la modalità in cui ci si trova dovrebbe essere una decisione, non un incidente. In pratica:

// JavaScript — Cloud Code (cloud/main.js)
// The guardrail under a vibe-coded frontend: rules the AI can't skip
Parse.Cloud.beforeSave('Note', (req) => {
  // Whatever the generated client sends, ownership is enforced HERE
  if (!req.user) throw 'Sign in required';
  const acl = new Parse.ACL(req.user); // private by default
  req.object.setACL(acl);
});
// Client keys are publishable; the Master Key stays server-side.
// The vibe-coded UI can be rewritten nightly — these rules survive.

// Flutter / Dart — Back4app Flutter SDK
// The vibe-coded client can be sloppy — the backend isn't
final note = ParseObject('Note')..set('text', draft);
await note.save();
// Whatever the generated UI does, the platform enforced:
//   session auth → beforeSave validation → owner-only ACL → rate limits
// The AI wrote this screen in minutes; it could NOT disable the rules.

// iOS / Swift — Back4app Swift SDK
// The vibe-coded client can be sloppy — the backend isn't
var note = Note()
note.text = draft
_ = try await note.save()
// Whatever the generated UI does, the platform enforced:
//   session auth → beforeSave validation → owner-only ACL → rate limits
// The AI wrote this screen in minutes; it could NOT disable the rules.

// Android / Kotlin — Back4app Android SDK
// The vibe-coded client can be sloppy — the backend isn't
val note = ParseObject("Note")
note.put("text", draft)
note.save()
// Whatever the generated UI does, the platform enforced:
//   session auth → beforeSave validation → owner-only ACL → rate limits
// The AI wrote this screen in minutes; it could NOT disable the rules.

Vibe coding vs. ingegneria assistita dall’IA vs. sviluppo tradizionale

Lo spettro, e la regola di promozione

L’inquadramento che risolve la maggior parte delle discussioni sul vibe coding: è uno stadio, non un’identità. I prototipi meritano le vibes – è il senso stesso dei prototipi. La regola che insegna la casistica degli incidenti: il codice passa da uno stadio all’altro solo tramite revisione e test. Dettaglio notevole: Karpathy stesso è andato oltre entro l’anno, distinguendo il vibe coding casuale dall‘“agentic engineering” per il lavoro serio – l’autore del termine che dà ragione ai suoi critici sull’ambito.

Che cosa si rompe davvero: la casistica degli incidenti

La sezione onesta che le spiegazioni dei vendor addolciscono. Le scansioni di settore rilevano falle di classe OWASP in circa il 45 % del codice generato dall’IA, e strumenti indipendenti di revisione hanno misurato nel codice IA circa 1,7× più problemi gravi rispetto a basi di confronto scritte da persone (la trattazione accademica arriva a conclusioni simili). Gli incidenti documentati condividono un’unica anatomia: nel 2025 una scansione di app costruite su un popolare builder prompt-to-app ha trovato 170 app su 1.645 che lasciavano trapelare dati degli utenti – lo stack generato veniva spedito con la sicurezza a livello di riga del database disattivata (registrata come CVE); il livello di autenticazione di una piattaforma prompt-to-app lasciava entrare qualunque utente in qualunque app privata tramite un ID indovinabile; e un’app consumer virale è stata violata quando il suo database di backend mobile non protetto ha permesso a qualunque utente autenticato di estrarre ID e messaggi privati degli altri. Nessuno di questi era un attacco esotico. Tutti riguardavano le basi del backend – regole di accesso, autenticazione, credenziali – generate in modo permissivo e accettate senza revisione.

È nel backend che morde

Rileggendo l’elenco degli incidenti lo schema si nomina da solo: il pericolo non è che l’IA scriva una UI goffa – un pulsante rotto si risolve con un refresh. Il pericolo si concentra dove vivono i dati: autenticazione, regole di accesso, chiavi API incollate nel codice client, rate limit assenti. Il codice non riletto è più pericoloso esattamente dove la revisione conta di più – ed è questa la risposta architetturale: rendere la parte in vibe coding la parte a bassa posta. Un frontend generato sopra un backend gestito inverte il rischio: la piattaforma fornisce autenticazione irrobustita, ACL con rifiuto predefinito applicate lato server, chiavi client pubblicabili con i veri segreti custoditi altrove e funzioni lato server per la logica che non deve vivere nel codice client generato. L’IA può riscrivere la UI ogni notte; non può disattivare regole che non controlla.

La checklist dei guardrail

1. Rivedere tutto ciò che tocca autenticazione, dati o denaro – la barriera di promozione, non negoziabile.
2. Fare un checkpoint nel controllo di versione prima di ogni “accept all” – un annullamento economico per suggerimenti costosi.
3. Tenere i segreti fuori dai prompt e dal codice client – entrambi vanno considerati pubblici.
4. Regole di accesso con rifiuto predefinito – l’app generata riceve i permessi scelti da chi sviluppa, non quelli permissivi che ha suggerito.
5. Validazione lato server per ogni invariante – hook che il client non può saltare.
6. Test prima della fiducia – l’unico riscontro onesto del ciclo oltre a “sembra funzionare”.
7. Ambiti piccoli, un compito per prompt – diff a misura di revisione restano rivedibili.
8. Mettere un tetto alla spesa – chiavi API con quote; i cicli degli agenti hanno già bruciato budget reali.
9. Isolare gli esperimenti – app separata, chiavi separate, dati usa e getta.
10. Sapere in quale modalità ci si trova – vibe coding o ingegneria, scelta di proposito.

Casi d’uso tipici

• Prototipi e MVP – il caso d’uso fondativo: testare l’idea questo fine settimana, non questo trimestre.
• Strumenti personali e interni – pubblico ridotto, utenti noti, raggio d’impatto basso.
• Hackathon e demo – la velocità è l’intero criterio di valutazione.
• Imparare costruendo – il ciclo come tutor, con la riserva che il codice non letto insegna meno.
• Iterazione della UI su un backend stabile – l’architettura a rischio invertito: le vibes sopra, i contratti sotto.

Conviene farlo in vibe coding? Matrice decisionale

Limiti e trade-off

• Fare debugging di codice non letto è archeologia. Quando il ciclo si blocca, qualcuno deve finalmente leggere tutto in una volta – la revisione saltata, con gli interessi.
• Il debito di comprensione si accumula. Ogni modifica accettata senza leggerla allarga il divario fra ciò che l’app fa e ciò che qualcuno sa spiegare; quel divario è il rischio.
• I valori predefiniti dell’IA sono permissivi. Le configurazioni generate privilegiano “funziona” rispetto a “è sicuro” – regole di accesso aperte, chiavi incorporate – e l’utente che più avrebbe bisogno di accorgersene è il meno attrezzato per farlo.
• Il termine sta cambiando significato. “Vibe coding” indica sempre più qualunque programmazione con l’IA, il che ripulisce pratiche da prototipo fino a portarle nelle discussioni di produzione; la precisione sulla modalità in cui ci si trova è la difesa.
• L’atrofia delle competenze è reale ma inquadrata male. La competenza che conta si sposta dallo scrivere codice allo specificarlo, rivederlo e giudicarlo – l’atrofia avviene solo se si salta anche la revisione.

Il vibe coding su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. L’abbinamento è l’architettura a rischio invertito resa pratica: il frontend generato viene collegato a un backend in cui le parti portanti sono già ingegnerizzate – registrazione, sessioni e login social dalla piattaforma; ACL e permessi di classe applicati lato server a ogni richiesta, con rifiuto predefinito; chiavi client pubblicabili con la master key custodita lato server; e la guardia beforeSave delle schede di codice come pattern per ogni invariante che non può essere affidato al client scritto dall’IA. La superficie in vibe coding resta ciò che Karpathy intendeva – veloce, divertente, usa e getta – mentre le parti che finiscono nei rapporti sugli incidenti vengono da una piattaforma: riviste una volta, applicate sempre.