Cos’è il vibe coding - e perché non sostituisce l’ingegneria

Vibe coding è un modo di scrivere software in cui smettete di digitare gran parte del codice. Descrivete ciò che volete in linguaggio quotidiano, un modello di IA genera l’implementazione, la eseguite e guidate a sensazione: «così va bene», «questo è rotto», «fai funzionare il form sul mobile». Il ciclo è conversazione più esecuzione - non un diff rivisto con la lente dopo ogni riga. :)

La formula è esplosa nel 2025, quando Andrej Karpathy ha descritto il «lasciarsi completamente al vibe»: dimenticate che il codice esiste, rincollate gli errori in chat e accettate che il modello conduca. Nel 2026 il termine è ovunque - vacancy, brief dei clienti e thread su Twitter che promettono velocità ×10 o avvertono che il repo non lo capisce più nessuno.

1. Cos’è il vibe coding - e cosa non è

Vibe coding non è «accendere l’autocompletamento di Copilot». L’autocompletamento vi lascia nel file: leggete i token man mano che appaiono. Il vibe coding è più vicino alla regia: enunciate il risultato, l’agente scrive file, lancia comandi, e voi giudicate il risultato come un product owner giudica una demo.

• È: spec in linguaggio naturale, editor agentici (Cursor, Claude Code e simili), cicli run-fix-rerun, e accettare codice che non avete scritto riga per riga.
• Non è: un nuovo linguaggio, un sostituto di git, dei test o della code review, né una licenza per saltare l’architettura.
• E non è magia: il modello continua a allucinare API, a copiare pattern datati e a «sistemare» volentieri un bug cancellando il check che lo prendeva.

2. Come si presenta il ciclo sul serio

Una sessione tipica di vibe coding: poca digitazione, tanta guida. L’obiettivo resta nella vostra testa; il modello è un junior rapidissimo che ha letto tutto Internet e nessuno dei vostri incidenti in produzione.

• Descrivete il risultato: «Aggiungi un indice blog con paginazione e URL consapevoli del locale, tieni il layout attuale».
• L’agente modifica file, a volte diversi insieme. Date un’occhiata al diff - o no, se siete pienamente in modalità vibe.
• Lanciate l’app. Se fallisce, incollate l’errore o uno screenshot della UI rotta e dite «sistemalo». Ripetete finché il vibe non torna.
• Pubblicate quando «si sente finito». È lì che i dilettanti si fermano - e i professionisti iniziano a fare domande scomode.

3. Vibe coding vs prompt engineering vs codice classico

I tre si sovrappongono — per questo il rumore in rete. La distinzione utile: chi risponde della correttezza.

• Codice classico: progettate, digitate e fate debug. Il cammino più lento fino alla prima demo, la massima responsabilità su ogni riga.
• Prompt engineering: il codice resta vostro. Scrivete prompt strutturati, vincolate l’output e fate review prima del merge. Il modello è uno strumento affilato, non il conducente.
• Vibe coding: rispondete del risultato più che dell’implementazione. Il punto è la velocità fino a uno schermo che funziona. La comprensione può restare indietro — finché la produzione non ve lo ricorda.

4. Quando il vibe coding è lo strumento giusto

Usato di proposito, è uno dei migliori acceleratori del 2026. Il trucco: abbinare il metodo al raggio d'impatto.

• Prototipi e spike: provare un’idea UX, una forma di API o un’integrazione di terze parti prima di impegnare uno sprint.
• Tool interni e script una tantum: pannelli admin, convertitori CSV, generatori di report - utili, basso rischio pubblico.
• Boilerplate e collante: route Next.js, i18n già agganciato, schemi di form, scheletri di test — il lavoro che sapete già revisionare.
• Imparare una superficie nuova: «mostrami uno Stripe Checkout che funziona in questo stack» è più veloce di tre tab di docs - se poi leggete ciò che è atterrato.

5. Quando fallisce in silenzio

Il modo di fallimento del vibe coding non è uno schermo rosso di errore. È una demo verde che nasconde debito: logica duplicata, check di auth assenti, variabili env inventate e un README che descrive un’altra app.

• Non si fa debug di ciò che non si è mai letto. Quando arriva il primo bug vero, «chiedere di nuovo al modello» non è una strategia - è scommettere.
• Sicurezza e soldi esigono umani. Pagamenti, PII, auth e tutto ciò che vede il cliente non si fanno merge solo sul vibe.
• Il team eredita il disastro. Un prototipo del weekend che diventa prodotto: così le aziende passano l’anno dopo a sbrogliare spaghetti a forma di IA.
• I modelli ottimizzano per «sembra finito». Aggiungeranno una feature copiando un file due volte invece di estrarre un modulo condiviso - a meno che non lo esigiate.

6. Come fare vibe coding da ingegnere senior

Il pattern professionale del 2026 non è «mai usare agenti» né «mai leggere il codice». È vibe, then verify: il modello scrive la bozza. Il merge è vostro.

• Limitate il raggio d'impatto: una feature, un PR, un Definition of Done chiaro. Gli agenti vagano se il prompt è una lista dei desideri.
• Date i vincoli in partenza: stack, cartelle, «non aggiungere dipendenze», «riusa i componenti esistenti». Un vibe vago produce codice generico.
• Leggete il diff. Non serve averlo digitato. Serve saperlo spiegare alla persona successiva - compreso voi tra sei mesi.
• Esigete test e un’esecuzione: «aggiungi un test per lo stato vuoto, poi lancia la suite». Una demo verde nel browser non è un job CI verde.
• Segreti e credenziali di produzione non vanno in chat. Incollate errori, non file .env.

7. Cosa implica se assumete o comprate software

Per un titolare la domanda non è «il nostro sviluppatore usa l’IA?». Chi è serio lo fa. La domanda è se sa ancora spiegare il sistema quando il vibe svanisce.

Il vibe coding può tagliare il costo di un esperimento: una landing, un flusso di prenotazione, uno spike di Mini App Telegram. Non deve tagliare il costo di ownership. Serve ancora qualcuno che noti che il checkout ha saltato l’IVA, che la paginazione ha rotto gli URL ucraini o che il «quick fix» ha disattivato il rate limiting.

Conclusione: tenete il vibe, tenete l’asticella

Il vibe coding è reale. Così inizia ora molto software buono - e così si spedisce molto software cattivo. Il metodo è un moltiplicatore: moltiplica il gusto e la disciplina che avete già. Se sapete specificare, revieware e assumervi la responsabilità, gli agenti vi rendono più veloci. Se no, accelerano il disastro.

Usatelo per bozze, spike e glue. Poi mettete il cappello senior: leggete il diff, lanciate i test e fate merge solo di ciò che potreste mantenere alle 2 di notte. Non è ostinazione vecchia scuola. Così il vibe coding diventa ingegneria - e non una demo invecchiata in una notte. :)