Dal vibe coding all'agentic engineering

Un anno fa, Andrej Karpathy ha detto a tutti di lasciarsi andare alle vibes. Milioni di persone l'hanno fatto. Sono arrivate a colpi di prompt a MVP, progetti del weekend e prototipi di startup in cui il 95% del codice usciva da un LLM.
Collins Dictionary ha eletto vibe coding parola dell'anno 2025. Y Combinator ha riferito che un quarto della sua batch Winter 2025 girava su codebase quasi interamente generate dall'AI.
Poi è arrivata la sbornia.
La sbornia che nessuno aveva messo in conto
A settembre 2025 Fast Company scriveva di ingegneri senior bloccati nell'inferno dello sviluppo con codice generato dall'AI. Un'analisi di CodeRabbit su 470 pull request open source di GitHub ha rilevato che "il codice co-scritto dall'AI conteneva circa 1.7 volte più problemi gravi del codice scritto da persone." Lovable, piattaforma svedese di vibe coding, ha messo online 170 app con falle di sicurezza che esponevano dati personali a chiunque andasse a guardare.
Lo schema si ripeteva ovunque: il team fa vibe coding di un prototipo, gli stakeholder si entusiasmano, gli ingegneri si trovano davanti alla scelta tra ricostruire con un'architettura seria o irrobustire un prototipo mai pensato per la produzione. Nessuna delle due è veloce. Nessuna delle due costa poco.
METR ha condotto uno studio randomizzato controllato con sviluppatori open source esperti. Il risultato è stato brutale: gli sviluppatori che usavano tool di coding AI erano il 19% più lenti, pur avendo previsto di essere il 24% più veloci e pur continuando a credere, dopo, di essere stati il 20% più veloci. Il divario tra performance percepita e performance reale è il dato più pericoloso di quello studio.
Il problema non è mai stato l'AI
È qui che quasi tutte le analisi sbagliano. Il problema non era che l'AI generasse codice cattivo. Il problema era che le persone saltavano l'ingegneria.
Nessuna architettura. Nessuna specifica. Nessun test. Nessuna review. Solo prompt e preghiere.
Come ha detto Addy Osmani di Google Cloud: "Non è stata l'AI a creare il problema. È stato saltare il design thinking."
L'ho visto in prima persona. Nel mio articolo di febbraio 2025 sul coding assistito dall'AI ho mappato l'evoluzione da no-code a low-code allo sviluppo assistito dall'AI. La tesi era solida. L'AI permette agli ingegneri di concentrarsi su architettura e problem solving invece che sul codice ripetitivo. Quello che avevo sottovalutato era quante persone avrebbero saltato del tutto la parte da ingegnere.
Il vibe coding trattava il software come una conversazione. Scrivi un prompt, ottieni un'app. Le vibes erano ottime. Il codice no.
Arriva l'agentic engineering
Il 5 febbraio 2026, esattamente un anno dopo aver coniato vibe coding, Karpathy ha pubblicato un aggiornamento. Il nuovo termine: agentic engineering.
In molti hanno quote-tweetato questo post come primo anniversario del vibe coding. Un po' di retrospettiva: ho un account Twitter da 17 anni ormai (omg) e ancora non riesco praticamente per niente a prevedere l'engagement dei miei tweet. Era un pensiero buttato lì sotto la doccia, sparato via e basta… Andrej Karpathy (@karpathy) 4 febbraio 2026
Il suo ragionamento: agentic perché gli sviluppatori non scrivono più direttamente la maggior parte del codice. Orchestrano agenti e fanno da supervisori. Engineering perché il processo resta arte e scienza insieme, richiede competenza ed è un mestiere che si può imparare.
Non è un rebrand. È un modello operativo profondamente diverso.
Nel vibe coding fai un prompt e speri. Nell'agentic engineering pianifichi, dirigi e revisioni. L'AI si occupa del lavoro ripetitivo. Tu sei responsabile dell'architettura, dei guardrail e dei risultati.
L'Agentic Coding Trends Report 2026 di Anthropic descrive il passaggio: i team non si appoggiano più a un singolo assistente di coding, ma a una flotta di agenti. Uno scrive codice, uno genera test, uno revisiona le modifiche, uno gestisce il deployment. Tutto sotto supervisione umana. TELUS ha creato oltre 13,000 soluzioni AI su misura rilasciando codice il 30% più in fretta. Zapier ha raggiunto l'89% di adozione dell'AI in tutta l'organizzazione, con 800+ agenti attivi internamente.
Gli ingegneri che vanno forte non sono quelli che scrivono prompt più in fretta. Sono quelli che hanno le idee più chiare su cosa stanno costruendo e perché.
Cosa è cambiato davvero
Il passaggio dal vibe coding all'agentic engineering ricalca uno schema che ho visto in ogni ondata tecnologica negli ultimi vent'anni passati a costruire software company.
Fase uno: euforia da democratizzazione. Tutti possono farlo. Le barriere sono cadute.
Fase due: la sbornia. Si scopre che togliere le barriere ha tolto anche i controlli di qualità.
Fase tre: professionalizzazione. Il tool resta. La disciplina torna.
La fase tre è adesso.
A gennaio 2026 Dario Amodei ha scritto che "i modelli AI sono diventati così bravi a programmare che alcuni dei migliori ingegneri che conosce affidano all'AI quasi tutto il loro lavoro di coding." Ma, ed è un ma decisivo, si tratta di ingegneri forti. Sanno cosa delegare, cosa verificare e quando l'agente sbaglia con la massima sicurezza.
Meta ha appena pubblicato una ricerca sui Just-in-Time Tests: test generati dall'AI al volo per ogni modifica al codice, perché le suite di test tradizionali non tengono il passo della velocità dello sviluppo agentico. La disciplina del testing non è sparita. Si è evoluta.
Cosa significa per product manager e founder
Se costruisci software nel 2026, come PM, founder o responsabile tecnico, ecco cosa conta davvero adesso.
Prima le specifiche, poi i prompt. I team che ottengono valore dall'agentic engineering scrivono documenti di design prima di toccare un agente di coding. Specifiche chiare, output AI migliore. Prompt vaghi, codice vago che si rompe quando cresce.
L'output dell'AI non è affidabile per default. Tratta ogni riga di codice generata dall'AI come tratteresti la pull request di un neoassunto. Rivedila, testala, mettila in discussione. Lo scanning di sicurezza automatico in ogni punto di integrazione non è opzionale.
Il vantaggio difendibile è il workflow, non il modello. L'intelligenza è una commodity. Il valore del tuo prodotto sta nel contesto, nella gestione dello stato e nei livelli di fiducia, non in quale LLM affitti. Se togli l'AI e ti resta una casella di testo, hai costruito un foglio di calcolo con qualche passaggio in più.
Il ruolo passa dallo scrivere all'orchestrare. I product manager che usano tool come Claude Code non programmano. Indagano codebase, sintetizzano ricerche e costruiscono skill riutilizzabili. Lo stesso vale per l'engineering: meno tastiera, più testa.
La parte in cui mi contraddico
Il vibe coding non è morto. E non deve morire.
Per tool personali, dashboard interne, prototipi che non vedranno mai la produzione, arrivare a un'app funzionante in un pomeriggio a colpi di prompt resta una cosa magnifica. Il software per un singolo caso d'uso è reale e ha valore.
L'errore è stato trattare una tecnica di prototipazione come una metodologia di produzione. Una mentalità da hackathon applicata al software enterprise. È lì che si è rotto tutto.
L'agentic engineering non uccide la vibe. La mette dentro un framework che consegna davvero.
Cosa viene adesso
La linea evolutiva è chiara: no-code, low-code, coding assistito dall'AI, vibe coding, agentic engineering. Ogni passo ha dato a più persone più potere di costruire. Ogni passo ha anche creato una nuova categoria di problemi che solo la disciplina poteva risolvere.
Le organizzazioni che nel 2026 stanno andando avanti non tolgono gli ingegneri dal ciclo. Fanno pesare la competenza ingegneristica dove conta di più: architettura, sicurezza, design di sistema. Gli agenti si occupano dell'implementazione.
La domanda per il tuo team non è se usare l'AI per lo sviluppo. Quel dibattito è chiuso.
La domanda è se stai facendo vibe o engineering.
Una delle due scala. L'altra genera fatture di consulenza per ripulire.
Serial Entrepreneur, Author
Marc is a serial entrepreneur. He started his first software company at 16, and has worked at the same intersection ever since: software product management meets go-to-market. He builds the bridge: Product × GTM × AI, as one system, not three departments. Three instead of thirty.