NAME
vibe-coding-agentic-engineering — Vibe coding, dopo la luna di miele
SYNOPSIS
cat vibe-coding-agentic-engineering.md
DESCRIPTION
Vibe coding è una di quelle espressioni che sembrano nate per farsi odiare e poi, lentamente, diventano utili.
All'inizio suona come: non penso, chiedo all'AI, accetto quello che esce, avanti così. Un modo allegro per produrre debito tecnico con un sottofondo musicale.
Però sarebbe troppo facile liquidarlo così. La verità è che il vibe coding ha intercettato una cosa reale: programmare con un modello cambia il rapporto tra idea e prototipo.
Prima avevi un pensiero e poi una lunga salita. Ora spesso hai un pensiero e dopo mezz'ora qualcosa si muove sullo schermo. È difficile non esserne sedotti.
La domanda interessante, nel 2026, non è se il vibe coding sia vero. Lo è. La domanda è: cosa succede dopo la luna di miele?
Il prototipo è diventato economico
Questa è la parte più importante.
Gli strumenti AI hanno abbassato il costo emotivo del cominciare. Prima, se volevi provare un'idea, dovevi già impegnarti: scegliere stack, creare progetto, ricordare boilerplate, scrivere layout, collegare API, litigare con dettagli noiosi.
Adesso puoi dire: fammi una prima versione.
E una prima versione arriva.
Non sempre bella. Non sempre corretta. Spesso fragile. Ma arriva. E quando arriva, cambia la conversazione. Non stai più discutendo nel vuoto. Stai toccando una cosa.
Questo è potentissimo per designer, founder, product manager, sviluppatori senior stanchi di riscrivere scaffolding, persone curiose che prima non avrebbero aperto un editor.
Il vibe coding è hype perché dà a più persone la sensazione fisica del software che nasce.
Il problema è che il software continua a vivere
La parte che il meme racconta meno è il giorno dopo.
Il prototipo deve essere letto. Corretto. Testato. Deployato. Messo in sicurezza. Capito da qualcun altro. Collegato a dati veri. Reso accessibile. Manutenuto quando una dipendenza cambia.
Qui il vibe coding puro sbatte contro il muro.
Un modello può generare tanto codice velocemente, ma il codice non è valore da solo. È una promessa di comportamento. E una promessa va verificata.
Il rischio del vibe coding non è scrivere codice brutto. Lo abbiamo sempre fatto anche senza AI. Il rischio è perdere il senso di proprietà: "l'ha fatto il modello" diventa una scusa per non capire abbastanza.
Ma il runtime non accetta scuse. Se il codice gira in produzione, è tuo.
Da vibe coding ad agentic engineering
La versione matura del vibe coding non è smettere di usare gli agenti. È usarli con un ciclo più serio.
Non: genera tutto e speriamo.
Ma:
- descrivi l'intenzione;
- lascia generare una bozza;
- chiedi all'agente di spiegare il piano;
- fai piccoli diff;
- lancia test;
- fai review;
- correggi;
- solo dopo unisci.
Questa cosa merita un nome diverso. Mi piace agentic engineering, anche se suona un po' solenne. Significa usare agenti non come slot machine, ma come collaboratori dentro un processo di engineering.
Il punto non è togliere energia al vibe coding. È darle binari.
Dove funziona benissimo
Il vibe coding funziona quando il costo dell'errore è basso e il valore dell'esplorazione è alto.
Esempi:
- prototipi di interfacce;
- tool personali;
- dashboard interne;
- giochi piccoli;
- script una tantum;
- esplorazioni di API;
- proof of concept;
- refactor meccanici con test buoni;
- contenuti tecnici da trasformare in demo.
In questi casi la velocità è il punto. Vuoi vedere se l'idea ha gambe. Vuoi scoprire cosa non avevi capito. Vuoi arrivare a una conversazione concreta.
Il vibe coding è perfetto per fare emergere forma.
Dove diventa pericoloso
Diventa pericoloso quando il sistema ha conseguenze e nessuno rallenta.
Pagamenti, dati personali, auth, permessi, infrastruttura, migrazioni database, codice legacy delicato, compliance, produzione. Qui la vibe non basta. Serve rigore.
Non significa che l'AI non possa aiutare. Anzi, può aiutare moltissimo. Ma deve lavorare dentro confini stretti: branch, sandbox, test, lint, review, feature flag, rollback.
La frase da tatuarsi sul monitor è semplice: più l'agente è veloce, più il processo deve essere leggibile.
Se non riesci a spiegare cosa è cambiato, non hai accelerato. Hai solo spostato il debito dal tempo alla comprensione.
Il ruolo nuovo dello sviluppatore
La parte più interessante è che il lavoro dello sviluppatore non sparisce. Cambia densità.
Meno tempo su boilerplate. Più tempo su intenzione, decomposizione, review, integrazione, test, confini.
Lo sviluppatore diventa una specie di editor tecnico. Non nel senso debole di "corregge bozze". Nel senso forte: decide cosa deve esistere, cosa va tagliato, cosa è coerente con il sistema, cosa merita fiducia.
Un buon editor non accetta tutto quello che riceve. Nemmeno lo riscrive tutto per orgoglio. Riconosce il materiale buono, lo porta a forma, protegge il lettore.
Con gli agenti, il lettore è anche il futuro maintainer. Spesso sei tu tra tre settimane.
Il pattern che vedo emergere
Il pattern più sano è questo:
- umano: intenzione, vincoli, gusto, responsabilità;
- agente: varianti, scaffolding, ricerca, modifiche locali, test ripetitivi;
- infrastruttura: sandbox, CI, trace, permessi, deploy;
- team: review, ownership, standard.
Quando manca uno di questi pezzi, qualcosa si deforma.
Solo umano: lento, spesso bloccato dal lavoro ripetitivo.
Solo agente: veloce, ma senza giudizio situato.
Solo infrastruttura: processo elegante per produrre cose inutili.
Solo team: riunioni molto ordinate intorno a un prototipo che non arriva mai.
Il bello accade quando i pezzi si parlano.
Una checklist piccola
Prima di lasciare che un prototipo vibe-coded cresca, mi farei queste domande:
- capisco la struttura del codice?
- ci sono test per il comportamento critico?
- so quali file l'agente ha toccato?
- ho rimosso codice generato ma non usato?
- ci sono segreti, token o dati finti finiti nel posto sbagliato?
- l'accessibilità minima è rispettata?
- il deploy ha rollback?
- qualcuno oltre a me può mantenerlo?
Se la risposta è no a troppe domande, non è un fallimento. È solo un prototipo che deve restare prototipo ancora un po'.
La mia lettura
Vibe coding è una parola rumorosa per una cosa tenera: la gioia di vedere un'idea prendere corpo prima che la paura la fermi.
Non voglio buttarla via. Sarebbe snob. Molte cose buone nascono così, mezze storte e vive.
Però il software che resta ha bisogno di altro. Ha bisogno di comprensione, test, ownership, infrastruttura, limiti. Ha bisogno che qualcuno dica: bello, ora rendiamolo vero.
Forse il futuro non è scegliere tra programmare "seriamente" e programmare "di vibe". Forse è imparare il cambio di marcia: esplorare con leggerezza, poi consolidare con rispetto.
La parte umana sta lì. Sapere quando correre e quando sedersi a leggere il diff.
Fonti
METADATA
- date: 2026-06-30
- reading: 6 min
- author: Filippo Spinella
- tags: AI, Coding, Agents, Developer Tools