"Vibe coding" è la ricerca più fatta in questo spazio, con largo margine. Gran parte di quello che si posiziona lo definisce, ancora: da dove viene l'espressione, che sensazione dà, se è una moda o il futuro del mestiere. Quella domanda ormai è chiusa. Quella che non lo è: cosa ha in mano una software house, mesi dopo, per una feature che è finita vibe-coded dentro il sistema di produzione di un cliente.
Cosa significa davvero vibe coding oggi
Andrej Karpathy ha nominato la pratica in un post di febbraio 2025, e la definizione che è rimasta è vicina a quella che ha descritto lui: descrivi cosa vuoi in linguaggio naturale, il modello scrive il codice, e continui a fare prompt invece di rileggere il diff riga per riga. La "vibe" è la parte che conta, si guida in base al risultato e alla sensazione, non ispezionando ogni modifica. È diverso dall'agentic coding come disciplina, che lascia anch'esso lavorare un modello su un intero repository senza supervisione, ma incornicia il lavoro in un loop esplicito, pianifica, modifica, esegue, verifica, a ogni passaggio. L'agentic coding, fatto bene, mantiene quel loop anche quando nessuno guarda ogni modifica. Il vibe coding, per definizione, tende a saltarlo o ad accorciarlo: tutto il fascino sta proprio nel non fermarsi a controllare.
Perché i team lo amano, e perché ai CTO viene l'ansia
Il fascino è reale e non sta sparendo. Uno sviluppatore può passare da un'idea a un prototipo funzionante nel tempo che prima serviva solo per impostare il progetto. Per chi costruisce da solo o per un prodotto in fase iniziale, quella velocità è quasi gratis: non c'è ancora un contratto con un cliente in ballo, e il costo di una svolta sbagliata è un pomeriggio, non un incidente in produzione. Lo Stack Overflow Developer Survey 2025 spiega perché l'abitudine si allarga oltre i prototipi: il 69% di chi usa strumenti AI per il coding dichiara una produttività individuale più alta. Una spinta così è difficile da contestare nel momento in cui la senti.
Ed è esattamente quello che mette ansia a un CTO o a chi guida la delivery quando la stessa abitudine arriva su un codebase da cui dipendono altre persone. Lo stesso sondaggio trova solo il 17% che dichiara una collaborazione di team migliorata dagli stessi strumenti, e il DORA report 2025 mette un numero sul lato fiducia di quel divario: il 30% degli intervistati dichiara poca o nessuna fiducia nel codice generato dall'AI, anche mentre l'adozione continua a salire. Il vibe coding non ha creato quel divario. Lo allarga, perché l'intero metodo è costruito per non fermarsi a costruire fiducia strada facendo.
Il divario tra spedire in fretta e spedire dimostrabile
Velocità e dimostrabilità non sono opposte, ma non nascono dalla stessa abitudine. Spedire in fretta vuol dire che la feature funziona, oggi, per il caso che hai provato. Spedire dimostrabile vuol dire che chi non era nella stanza, un revisore, una nuova assunzione, un auditor tra sei mesi, può ricostruire perché una certa modifica è stata fatta in un certo modo, senza dover chiedere a chi ha scritto il prompt e sperare che se lo ricordi.
Il vibe coding ottimizza a fondo per il primo e non fa nulla di default per il secondo. Non è un difetto esclusivo di questa pratica, è lo stesso divario che si presenta in tutta la categoria quando una sessione finisce. Quello che gli agenti di coding AI lasciano quando la sessione è finita è di solito un log di chat in un formato proprietario, legato a qualunque strumento abbia girato quel giorno. Il vibe coding ci arriva solo più in fretta e con meno checkpoint intermedi, perché i checkpoint sono esattamente quello che il workflow è costruito per saltare.
Il rischio non è ipotetico, e non riguarda davvero se il codice funziona. Uno studio controllato randomizzato di METR del 2025 ha trovato che sviluppatori esperti che usavano strumenti AI su task reali impiegavano circa il 19% in più, pur restando convinti di essere stati più veloci. Se chi ha scritto il codice, vedendolo succedere in tempo reale, può giudicare male il risultato, una feature vibe-coded che "sembra fatta" non è, da sola, la prova che lo sia.
Cosa dovrebbe tenere una software house da una sessione vibe-coded
Niente di tutto questo vuol dire vietare il vibe coding in un team di ingegneria serio. Vuol dire trattarlo come una prima bozza veloce, non come una consegna finita, e decidere in anticipo cosa deve sopravvivere alla sessione, indipendentemente da come è stato scritto. Come minimo, sono quattro cose: la richiesta originale, in qualunque forma sia arrivata, così l'intento non va ricostruito a memoria dopo. Il perimetro dentro cui il modello stava davvero lavorando, quali file, quali sistemi, quali dati poteva toccare. Cosa ha eseguito, passo per passo, non solo il diff finale. E un passaggio di revisione dove una persona rilegge davvero il risultato rispetto a questi tre punti, prima che arrivi nell'ambiente di un cliente, non dopo.
Quest'ultimo punto è proprio quello che il vibe coding è costruito per scavalcare, ed è quello che una software house non può permettersi di scavalcare. La velocità del ciclo prompt-e-accetta è una proprietà della fase di bozza. Non dice nulla su cosa succede quando lo stesso codice gira davanti a un cliente che paga e qualcosa si rompe alle due di notte.
Dal vibe coding alla consegna responsabile
Il vibe coding è un guadagno di produttività reale nel momento in cui si scrive codice, e far finta del contrario non aiuta nessuno a scegliere un workflow. Il problema non è la velocità, è che la velocità da sola non lascia a un team niente da mostrare dopo. Come una software house sceglie un assistente AI per il coding deve già pesare questo aspetto: uno strumento ottimo per una bozza veloce non è automaticamente lo stesso strumento, o lo stesso workflow, che vuoi sulla strada verso il sistema di produzione di un cliente.
La correzione non è una vibe più lenta. È una linea tra bozza e consegna che non sparisce solo perché la maggior parte del codice l'ha scritta un modello. Il livello che tiene quella linea è quello che trasforma una sessione veloce e non revisionata in una consegna che una software house può davvero difendere, con intento, perimetro autorizzato, esecuzione e prova legati insieme, indipendentemente da quanto vibe fosse la sessione che l'ha prodotta.