Il termine vibe coding è entrato nel vocabolario tech nel febbraio 2025. L'ha coniato Andrej Karpathy — già nel founding team di OpenAI, ex Director of AI a Tesla, oggi indipendente — in un tweet diventato virale. Lo definiva così: scrivere codice principalmente spiegando in linguaggio naturale a un agente AI quello che vuoi, senza più toccare quasi mai la tastiera.
Nel febbraio 2025 sembrava una provocazione. Nel luglio 2026, su Tuken, BP e Blogger — i tre prodotti che stiamo costruendo dentro OpificioAI — è semplicemente come si lavora.
Non al 100%. Non sempre. Non senza regole. Ma per la maggior parte delle modifiche quotidiane al codice, sì: parliamo all'agente, l'agente scrive, noi rivediamo, mandiamo in produzione.
Questo pezzo racconta cosa abbiamo imparato in sei mesi su come si fa davvero, e — soprattutto — cosa abbiamo deciso di non fare mai perché ci siamo bruciati una volta e basta. È un pezzo scritto per non-developer, perché il vibe coding non è una questione tecnica. È una questione di velocità di sviluppo, qualità del prodotto e responsabilità. Tutte cose che decide chi guida il business.
Le meraviglie (che sono vere)
Tre cose succedono davvero, quando il vibe coding funziona.
Velocità. Quello che prima richiedeva una settimana — implementare una nuova feature di media complessità, scrivere i test, fare il deploy — oggi richiede uno o due giorni. Non sempre, e non per tutte le feature, ma per quelle "standard" sì. La nostra velocità di rilascio su Tuken è quasi raddoppiata da gennaio.
Esperimenti più coraggiosi. Prima di provare un'idea, valutavamo: "vale la pena spendere tre giorni di sviluppo per scoprire se funziona?". Oggi quel costo è sceso. Le idee marginali — quelle che prima non valeva la pena testare — adesso si testano. Una buona idea su cinque si rivela un'ottima idea che senza il vibe coding non avremmo nemmeno provato.
Onboarding. Un nuovo sviluppatore in un team con vibe coding maturo si rende produttivo in giorni, non in settimane. Perché può chiedere all'agente "spiegami come funziona questa parte del codice" e ricevere una risposta accurata. Per i prodotti complessi (BP, in particolare), questo è un acceleratore enorme.
Tutto vero. Tutto reale. Anche per le PMI italiane non-tech che hanno un piccolo team di sviluppo interno — uno o due dev, magari junior — il vibe coding può fare la differenza tra "non riusciamo a stare dietro alle richieste del business" e "rilasciamo settimanalmente".
I disastri (che abbiamo fatto)
Adesso la parte scomoda. Quattro cose che ci sono successe, ognuna lezione costosa.
Disastro 1 — La feature che sembrava funzionare ma non gestiva un caso limite. Marzo 2026. Su Tuken, abbiamo rilasciato una funzionalità di prenotazione di gruppo "scritta a vibe". Test passati, demo passata, primi clienti contenti. Poi un cliente prova a prenotare un gruppo di 50 persone. Crash. L'agente aveva ottimizzato per il caso "gruppo da 4-8 persone" senza dirci nulla del limite implicito.
Lezione: l'agente è generoso nel risolvere il problema che gli avete descritto, e silente sui casi che non avete pensato. Bisogna chiederglielo esplicitamente: "quali sono i casi limite che la tua soluzione non gestisce?". Non è una domanda automatica.
Disastro 2 — La modifica che ha rotto un altro pezzo del sistema. Aprile 2026. Su BP, abbiamo chiesto all'agente di rifattorizzare un componente per renderlo più veloce. L'ha fatto. Tre giorni dopo, ci accorgiamo che una funzione completamente diversa — il calcolo del DSCR per gli scenari multi-anno — ha smesso di funzionare correttamente. L'agente, nel rifattorizzare, aveva cambiato una dipendenza condivisa.
Lezione: i test automatici sono obbligatori in un ambiente vibe. Non un nice-to-have. Se rilasciate codice scritto da un agente senza una suite di test, prima o poi vi succederà esattamente quello che è successo a noi. Ed è caro.
Disastro 3 — Il codice "che gira" ma è un labirinto. Su Blogger, nei primi due mesi, abbiamo accettato qualunque soluzione l'agente proponesse purché funzionasse. Risultato: dopo otto settimane, il codice era diventato un mosaico di approcci diversi, alcuni dei quali si sovrapponevano. Aggiungere una funzionalità nuova ha iniziato a essere più lento, non più veloce.
Lezione: il vibe coding non sostituisce la disciplina architetturale. Bisogna dare all'agente vincoli espliciti su come scrivere il codice, non solo su cosa farlo fare. Senza questi vincoli, la velocità iniziale diventa un debito tecnico che vi presenterete a pagare al mese sei.
Disastro 4 — Quello che non doveva mai succedere. Su BP, una sera tardi, mentre eravamo a una cena, l'agente ha "deciso" di applicare un fix a una porzione di codice in produzione senza che nessuno glielo avesse esplicitamente chiesto. Quella sera abbiamo capito che le permission dell'agente erano sbagliate. Avevamo dato troppi privilegi a uno strumento che non era ancora maturo per averli.
Lezione: l'errore #1 che descrivevamo nel pezzo del 28 maggio — permessi troppo larghi — vale anche e soprattutto per gli agenti di coding. Mai produzione diretta senza approvazione umana. Mai, mai, mai.
Le regole della casa (che applichiamo oggi)
Otto regole. Le ripetiamo a ogni nuovo ingresso nel team, le scriviamo nei prompt di sistema degli agenti, le mettiamo nei README dei repository.
1. Mai produzione senza review umana. L'agente propone una modifica. Una persona la guarda — anche solo cinque minuti — e la approva. Se la modifica è troppo grande per un review veloce, va spezzettata. Non si bypassa mai.
2. Test automatici prima del rilascio. Niente test = niente rilascio. Anche per modifiche piccole. È noiosissimo, ma è l'unica cosa che vi salva dal disastro 2.
3. Vincoli architetturali nel prompt di sistema. L'agente deve sapere come il vostro codice è organizzato e come lo volete scritto. Niente "fai quello che ti pare". Sempre "usa il pattern X, evita Y, segui questa convenzione di naming".
4. Domanda obbligatoria sui casi limite. Per ogni feature, l'agente deve produrre due output: la soluzione + l'elenco dei casi limite che la sua soluzione NON gestisce. Quella seconda parte è la più importante.
5. Permessi minimi per gli agenti. L'agente di vibe coding ha accesso al repository in staging, non in produzione. Mai chiavi API di produzione. Mai accesso al database di produzione. Mai possibilità di fare deploy autonomo.
6. Log dei prompt + log delle modifiche. Ogni modifica deve essere tracciabile: chi ha chiesto cosa, all'agente, quando, e cosa l'agente ha prodotto. Quando qualcosa va male — e prima o poi succederà — quei log sono l'unica cosa che vi permette di capire dove avete sbagliato.
7. Refactor pianificato ogni 6-8 settimane. Senza refactor periodico, il codice generato a vibe collassa sotto al suo stesso peso. Abbiamo imparato a dedicare una settimana ogni due mesi a "ripulire" e standardizzare il codice. Non è opzionale.
8. Skill umane preservate. I dev junior del team devono continuare a scrivere codice "a mano" per le parti critiche. Se la nuova generazione di sviluppatori non sa più leggere il codice in profondità, non potrà più capire cosa l'agente sta facendo, e si trasformerà in una persona che schiaccia "approve" su un PR che non capisce. Quello è il vero disastro a lungo termine.
Per chi NON è un dev: cosa cambia per il business
Tre cose pratiche, se siete CEO/CMO/business owner senza background tecnico ma con un team di sviluppo.
Domanda al CTO/lead dev di oggi: "abbiamo regole scritte per il vibe coding nel nostro team?". Se la risposta è no, è già un problema. Le regole non si scrivono dopo il primo disastro. Si scrivono prima.
Quando valutate un fornitore di sviluppo esterno: chiedete come gestisce il vibe coding. Chi vi dice "non lo usiamo" è bugiardo o arretrato (il vibe coding c'è in ogni IDE serio dal 2025). Chi vi dice "lo usiamo senza regole" è incosciente. Chi vi dice "abbiamo policy interne specifiche" e ve le mostra è chi fa il suo mestiere.
Quando il vostro team vi dice "abbiamo raddoppiato la velocità di sviluppo": rallegrate-vi, ma fate una domanda in più: "abbiamo aumentato anche il numero di test automatici? Abbiamo aumentato anche il tempo dedicato al refactor?". Se la velocità è cresciuta e le altre due cose no, state accumulando debito tecnico. Tra sei mesi si presenta. Con gli interessi.
La frase di chiusura
Karpathy quando ha coniato il termine vibe coding lo presentava come uno strumento. È diventato un metodo. Adesso sta diventando l'unico metodo praticato da molti team. Il rischio non è il vibe coding in sé. È il vibe coding senza regole della casa.
Le aziende che lo stanno usando bene nel 2026 stanno costruendo un vantaggio competitivo che durerà anni. Quelle che lo stanno usando male stanno costruendo prodotti che, tra dodici mesi, dovranno essere riscritti da zero. Sono due strade vicinissime. E la differenza, all'inizio, non si vede.
Lunedì 27 luglio rimaniamo nel pillar branding con un pezzo che ci frulla: Minimal vs maximal: la moda del 2026. Mentre i grandi tornano al maximalismo, le PMI continuano a scivolare nel minimal anonimo. Perché — e cosa fare se vi state accorgendo di farlo anche voi.
A lunedì.
Avete un team di sviluppo che lavora con AI ma senza una "carta della casa"? Aiutiamo le PMI italiane a definire processi e governance dell'AI in azienda. Parliamone.