Da Vibe Coding a Vibe Engineering: un viaggio nel cambiamento di mentalità e processi
Abbiamo iniziato per gioco, ma presto ci siamo scontrati con la realtà: il vibe coding da solo non basta. In questo articolo raccontiamo come siamo arrivati al concetto di Vibe Engineering.
Il potere del “flow” incontra l’ingegneria
Tutto è iniziato per gioco.
Dopo aver visto spopolare il trend del vibe coding, ho deciso di sperimentare. Mi affascinava l’idea di scrivere codice senza scrivere codice. Solo io, un prompt, e un’intelligenza artificiale pronta a generare tutto il necessario per costruire un progetto.
Nel giro di cinque ore ho creato un prototipo di videogioco funzionante. Un esperimento che ho raccontato in questo articolo, dove mostro passo passo come ci sono riuscito.
Ma la vera domanda che mi interessava era un’altra:
Questa nuova modalità di sviluppo è solo un gioco o può davvero entrare nei flussi di lavoro reali, nei prodotti veri, nei team veri?
Spoiler: può farlo.
Ma non da sola.
Il vibe coding è una rivoluzione, soprattutto per la fase da 0 a 1. Ti permette di prototipare, validare idee, sbloccare creatività e velocità che non avevamo mai visto. Ma dopo un po’, mi sono accorto che mancava qualcosa.
Mancava la struttura. L’ingegneria. La consapevolezza di cosa stavo dicendo all’AI di fare — e perché.
È stato durante un viaggio in treno con Gianluca, mentre riflettevamo su tutto questo e sul futuro dello sviluppo, che abbiamo messo insieme i pezzi.
È lì che nasce il concetto di Vibe Engineering.
Un’evoluzione del vibe coding che unisce il flusso creativo potenziato dall’AI con i principi dell’ingegneria del software: architettura, product development, domain driven design, team topology. Tutto ciò che serve per costruire prodotti che non solo funzionano, ma crescono, si mantengono e scalano nel tempo.
In questo articolo vogliamo raccontarti questo passaggio.
Il viaggio che parte dal prompt e arriva alla strategia.
Dall’intuizione alla sostenibilità.
Dal coding al engineering.
Cos’è il Vibe Coding (e perché funziona così bene all’inizio)
Il vibe coding è un modo completamente nuovo di approcciare lo sviluppo: non pianifichi, non progetti, non ti fermi troppo a pensare. Ti siedi davanti al tuo editor, apri l’AI e inizi a “chiacchierare”. Il codice prende forma rispondendo al tuo flusso creativo, come se stessi improvvisando musica.
L’ho scoperto per caso, quasi per gioco. Volevo capire se fosse solo un trend passeggero o se ci fosse del potenziale reale. Così, in una giornata libera, mi sono messo a sviluppare un piccolo videogioco — tutto con AI — in appena 5 ore. È stata un’esperienza quasi mistica: nessun file creato a mano, zero tempo sprecato su dettagli inutili, solo flow.
👉 link al mio articolo sul processo
Ed è proprio qui che il vibe coding brilla: nella fase iniziale, quando parti da zero, hai solo un’idea e vuoi darle forma il più velocemente possibile.
🎯 I benefici del Vibe Coding
✅ Prototipazione istantanea: Con il vibe coding puoi passare da idea a interfaccia funzionante in pochissimo tempo. È perfetto per validare un concetto, creare un MVP o simulare un’interazione.
✅ Creatività potenziata: L’AI diventa un partner creativo. Ti suggerisce soluzioni a cui non avresti pensato, ti mostra nuove strade. È come fare pair programming con un collega iperattivo che non dorme mai.
✅ Onboarding facilitato: Per chi è alle prime armi, è una manna. Ti permette di vedere esempi concreti, provare subito a costruire cose reali, e accelerare l’apprendimento con feedback immediato.
⚠️ Ma arriviamo ai limiti…
❌ Mancanza di struttura: Il codice prende forma in modo organico, ma raramente in modo strutturato. Senza una direzione architetturale chiara, ogni nuova feature può diventare una complicazione.
❌ Difficoltà a scalare (o collaborare): Scrivere codice in vibe mode funziona bene da soli. Ma appena un altro sviluppatore entra nel progetto, le cose si complicano: file disorganizzati, logiche duplicate, mancanza di convenzioni.
❌ Mancanza di controllo sull’output: L’AI è veloce, ma spesso è anche imprevedibile. Ogni volta che chiedi qualcosa, potresti ottenere dieci versioni diverse. Alcune funzionano, altre no, alcune sembrano magiche… finché non scopri che sotto il cofano c’è una logica fragile.
Non avere un controllo pieno su come viene generato il codice significa anche non poter garantire la coerenza del progetto nel tempo.
❌ Difficoltà nel dare regole: Impostare delle linee guida tecniche — design pattern, naming convention, struttura dei file — diventa complicato. Anche quando provi a spiegare “come fare le cose”, l’AI può interpretare a modo suo. È come lavorare con un junior developer super veloce, ma un po’ testardo.
❌ Problemi di sicurezza: Uno dei rischi più sottovalutati è la sicurezza del codice generato. L’AI può facilmente introdurre vulnerabilità se non le anticipi tu. Senza una solida base di conoscenze tecniche e un processo di revisione, potresti ritrovarti con codice potenzialmente pericoloso in produzione.
❌ Best practice? Forse.: Il codice generato segue le best practice? A volte sì, spesso no. Dipende da cosa chiedi, come lo chiedi, e quanto l’AI “capisce” il contesto. Questo rende complicato mantenere un codice pulito e scalabile nel lungo periodo, soprattutto in team.
❌ Debito tecnico invisibile: Il vibe coding ti porta a generare tanto, velocemente. Ma spesso il debito tecnico si accumula senza che tu te ne accorga. Ogni shortcut preso, ogni pezzo di codice non allineato con l’architettura generale, ogni workaround: tutto si somma. E lo paghi dopo.
La svolta: quando il vibe coding non basta più
Il momento della verità è arrivato quando ho provato a portare il vibe coding "sul serio". Non su un side project, non su un prototipo da weekend. Ma sulla codebase di Learnn: due applicazioni principali, un SDK condiviso, più di dieci micro-servizi. Un sistema reale, vivo, con tanti vincoli, dipendenze e persone che ci lavorano ogni giorno.
Volevo capire se lo stesso flusso creativo che mi aveva permesso di creare un videogioco in 5 ore potesse scalare anche in un contesto complesso.
Spoiler: no, non basta.
Ogni richiesta all’AI generava una soluzione diversa. Ogni microservizio sembrava scritto da un autore diverso. L’SDK diventava un campo minato. Le naming convention saltavano, l’il design del codice si disgregava, aumentando l’accoppiamento. E il debito tecnico cresceva in modo rapido.
È lì che ho capito:
Il vibe coding non basta più quando il software smette di essere un esperimento e diventa un prodotto.
Lavorare con l’AI in modo efficace richiede nuove pratiche ingegneristiche. Serve una visione architetturale, la capacità di gestire ambiguità, processi di code review e test automatizzati. Soprattutto: serve collegare il codice agli obiettivi di business.
È lì che nasce il concetto di Vibe Engineering: la fusione tra creatività guidata dall’AI e solidità ingegneristica.
Cos’è il Vibe Engineering: definizione e principi
Se il vibe coding è il punto di partenza — l’energia creativa, la spinta iniziale — allora il vibe engineering è l’evoluzione necessaria per costruire qualcosa che resista nel tempo.
Vibe Engineering è un approccio che unisce la potenza dell’AI alla disciplina dell’ingegneria del software.
Non rinuncia alla velocità o alla spontaneità, ma le incanala in un sistema di pratiche, principi e strumenti che permettono di scalare, collaborare e mantenere alta la qualità.
È il momento in cui smetti di usare l’AI per "scrivere codice", e inizi a usarla per costruire sistemi.
I principi del Vibe Engineering
1. 🧱 Architettura modulare guidata dal dominio
Organizzare il codice per contesti funzionali, non per tecnologia.
Ogni modulo ha una responsabilità chiara, ed è facile da isolare, testare e sostituire.
L’AI lavora meglio quando capisce dove inizia e dove finisce una cosa.
2. 🎯 Mentalità orientata al prodotto
Non stai più solo “facendo funzionare qualcosa”, ma costruendo valore.
Il codice ha uno scopo preciso, legato a obiettivi di business e metriche reali.
L’AI non è solo uno strumento tecnico, ma un alleato strategico.
3. 🤖 Uso consapevole dell’AI: assistente, non autore
L’AI ti accompagna, ma non guida.
Scrive, esplora, propone, ma non decide da sola.
Il focus è su controllo e intenzionalità: ogni prompt nasce da una scelta precisa.
4. 📜 Set di rules per ogni use case
L’AI lavora meglio quando le regole sono scritte chiaramente.
Naming convention, componenti UI, pattern architetturali: tutto dovrebbe essere leggibile dall’AI, non solo dagli umani.
In Cursor abbiamo iniziato a creare una cartella /rules con prompt e linee guida per ogni area del codice.
Un po’ come documentare l’architettura… ma in linguaggio AI.
Ogni volta che “chiedi aiuto”, l’AI ha già tutto il contesto per rispondere bene.
5. 🧠 Prompting come nuova skill tecnica
Scrivere buoni prompt è come scrivere buone API.
Serve chiarezza, contesto e una visione sistemica.
Nel vibe engineering, prompting diventa parte integrante del tuo skillset tecnico — con template, versioni, testing e documentazione.
6. ✅ Validazione continua e test-driven thinking
Generare codice è facile. Assicurarsi che sia corretto è un altro mestiere.
Il vibe engineering incorpora test, controlli statici, linters e strategie di validazione sin dalla fase di prompt.
L’obiettivo non è scrivere meno test grazie all’AI, ma scriverli meglio e prima.
🔄 Da Vibe Coding a Vibe Engineering
Ecco cosa cambia, nel mindset e nei processi:
Come vogliamo cambiare i processi di team
Il vibe engineering non è solo un cambio di mentalità individuale, ma una vera evoluzione dei processi di team.
Usare l’AI non significa più “velocizzare lo sviluppo”, ma ridefinirne il modo stesso in cui costruiamo, collaboriamo e miglioriamo insieme. Il nostro obiettivo è creare un flusso di lavoro che sia:
scalabile
consapevole
guidato da contesto e regole
🛠️ Come si fa una feature in chiave Vibe Engineering
Una feature, oggi, non parte da “scriviamo codice”. Parte da un piano incrementale.
Ecco il flow che stiamo sperimentando:
Partire dalla descrizione del Product Backlog Item
Si utilizza un LLM per generare un piano di implementazione incrementale: piccoli step, ben definiti, con criteri di verifica.
Innestare il piano nel proprio editor (es. Cursor o Copilot)
Il piano viene condiviso con l’AI. Le viene chiesto di fare domande se qualcosa non è chiaro.
Questo allinea AI e developer sul contesto della feature.
Chiedere l’implementazione del primo step
Specificando: “Non aggiungere funzionalità extra”. Il focus è sulla precisione, non sulla velocità.
Testare e verificare l’output
Se funziona, si passa allo step successivo. Se no, si forniscono feedback e si genera una nuova versione.
Questo ciclo si ripete fino al completamento dell’intera feature.
🔁 È uno sviluppo guidato da test, feedback e micro-decisioni, non più da lunghi prompt monolitici o “magie da completamento automatico”.
🔄 Il nuovo workflow di team
Per far funzionare questo approccio su scala, servono fondamenta condivise. Ecco i pilastri del nuovo workflow:
✅ Definition of Done chiara e condivisa
Ogni feature deve rispettare un insieme preciso di requisiti:
Tracciamenti
Eventuali Feature flag
Responsabilità ben definite
Test automatizzati
Naming coerente
Documentazione minima
L’AI viene guidata a partire da questa checklist, esattamente come faresti con un nuovo dev nel team.
📁 Set di rules condiviso
Come avere un tsconfig.json, ma per l’AI.
Abbiamo iniziato a usare una cartella /rules, dove definiamo:
Pattern architetturali
Convenzioni sui nomi
Strategie di validazione
Prompt predefiniti per use case ricorrenti
Ogni membro del team — umano o AI — parte dallo stesso contesto.
Tu stai già facendo vibe engineering?
Forse ti è già capitato: hai usato l’AI per sviluppare una feature, ti sei trovato in flow, hai sentito di andare veloce come mai prima.
E poi… hai dovuto sistemare, allineare, spiegare al team, riscrivere da zero.
È normale.
Tutti stiamo vivendo questo momento di transizione.
Il vibe coding è una rivoluzione entusiasmante, ma per trasformarla in qualcosa di solido serve un cambio di prospettiva.
Serve un approccio ingegneristico.
Se ti sei ritrovato in uno o più punti di questo articolo, probabilmente lo stai già facendo, anche se non lo chiami ancora così.
👉 Connettiamoci
💻 Parlo di Tech e Prodotto anche su LinkedIn