La scena: un’ingegnere senior in un team distribuito sta completando un microservice di autenticazione. OAuth flows, token rotation, rate limiting. Tempo impiegato: 45 minuti. Linee di codice scritte a mano: 11. Il resto è avvenuto attraverso una conversazione.

Non è un caso anomalo. È il 2026, e il vibe coding — quel termine coniato da Andrej Karpathy all’inizio del 2025 che sembrava uno scherzo — è diventato un mercato da 4,7 miliardi di dollari. Ma la domanda che ci facciamo noi developer pratici, quelli che ogni giorno aprono il terminale per lavorare su progetti reali (non demo da conferenza), è un’altra: siamo davvero più produttivi, o solo più veloci a generare codice che non funziona?

Da meme a mercato: la curva più rapida della storia dev

La progressione è stata brutale. GitHub Copilot nel 2021 era un autocomplete intelligente. ChatGPT nel 11/2022 dimostrò che si poteva “parlare” con una macchina per ottenere codice. GPT-4 nel 03/2023 fece il salto di qualità. Poi, nel 02/2025, Karpathy pubblicò quel tweet che tutto cambiò: “vibes” come paradigma di sviluppo.

In 18 mesi siamo passati da meme a realtà industriale. Collins Dictionary ha eletto “vibe coding” parola dell’anno nel 11/2025. Cursor ha raccolto 900 milioni di dollari in Series C a una valutazione di 9 miliardi. Lovable ha raggiunto 17 milioni di ARR in soli 4 mesi. E nel 02/2026 c’è stata la cosiddetta “SaaSpocalypse”: 285 miliardi di dollari dalle valutazioni SaaS perché, improvvisamente, chiunque poteva costruire un tool interno in un pomeriggio.

La curva di adozione parla chiaro: il 92% degli sviluppatori USA usa strumenti AI quotidianamente. Secondo stime di settore, circa il 40% del codice prodotto oggi ha un componente AI, e Gartner prevede che entro fine 2026 il 60% del nuovo codice sarà generato da AI. Nel batch YC W25, il 25% delle startup ha il 95%+ di codice generato da AI.

Quei numeri però raccontano l’adozione, non l’efficacia. E qui la narrazione si complica. Su DEV.to, la settimana di apertura di giugno 2026 è stata dominata da articoli che suonano come dei bilanci: “From Vibe Coding to Clear Thinking” (51 reazioni), “I Thought AI Would Make Me Code Faster. Then I Spent 6 Hours Debugging One Line” (52 reazioni), “Am I Becoming Too Slow for the AI World?” (66 reazioni). Il dibattito è maturato. Non più entusiasmo acritico, ma una domanda concreta: tutto questo ci sta davvero rendendo migliori?

La risposta, come spesso accade, dipende dal contesto.

Cosa funziona davvero (e cosa no)

Ci sono aree in cui gli AI coding agent sono diventati genuinamente utili, al punto da cambiare il flusso di lavoro quotidiano.

Prototipazione rapida. Qui il vibe coding brilla. Hai un’idea per un tool interno? Descrivi cosa vuoi, ottieni uno scheletro funzionante in minuti. Non è perfetto, ma è abbastanza buono per validare un’ipotesi. Su progetti personali e side project, questo ha compresso i tempi di settimane a giorni.

Boilerplate e codice ripetitivo. Configurare un progetto con Docker, CI/CD, testing framework, linting — tutto quello che fai ogni volta ma che nessuno vuole davvero scrivere. Gli agent lo fanno in modo affidabile. Cursor in modalità agent, Claude Code in sessione terminal, persino Copilot Workspace: tutti egregi per il setup iniziale.

Esplorazione di API e librerie sconosciute. “Come faccio a integrare questa API REST con autenticazione JWT in un progetto FastAPI?” — domande che prima richiedevano 30 minuti di documentazione ora hanno una risposta funzionante in 2 minuti. Non sempre corretta, ma un punto di partenza concreto.

Refactoring mirato. Rinominare una variabile in 47 file. Estrarre un pattern ripetuto in una funzione condivisa. Scrivere test per codice legacy. Questi sono compiti in cui gli agent eccellono perché sono ben definiti e hanno un output verificabile.

Poi c’è l’altro lato della medaglia. Quello di cui si parla meno nei thread entusiastici di Twitter.

Architetture complesse. Chiedi a un agent di progettare un sistema distribuito con microservizi, message queue, circuit breaker e consistenza eventuale. Ti darà qualcosa che sembra ragionevole. Ma manca la comprensione profonda dei trade-off, delle dipendenze nascoste, dei casi limite che emergono solo in produzione con carico reale.

Debugging del codice AI-generated. È il paradosso del vibe coding: più codice l’AI produce, più tempo passi a capire perché non funziona. E il problema non è che il codice sia sbagliato in modo ovvio — è che è quasi giusto. Quel “quasi” è quello che ti costa 6 ore di debugging. Come ha scritto un developer su DEV.to: “Ho pensato che l’AI mi avrebbe reso più veloce. Poi ho passato 6 ore a debuggare una singola riga.”

Progetti grandi e contesto. Gli agent hanno un contesto limitato. Quando lavori su un progetto con decine di migliaia di righe, dipendenze complesse e convenzioni interne, l’agent perde il filo. Genera codice che non rispetta i pattern esistente, introduce dipendenze non necessarie, o semplicemente non capisce l’architettura.

La trappola della dipendenza. Brad Traversy, che inizialmente era scettico, ha cambiato parere — ma con un’avvertenza cruciale: “L’AI gestisce la digitazione. Tu devi ancora gestire il pensiero.” Il rischio è che i developer junior generino codice più veloce che mai ma manchino del contesto di sistema per valutarlo. Come ha sintetizzato un commentatore: “Consegnare la digitazione va bene. Consegnare il pensiero è fatale.”

Il ruolo del developer si sta ridefinendo

Il 2026 non è l’anno in cui l’AI ha sostituito gli sviluppatori. È l’anno in cui il ruolo sta cambiando.

Il developer moderno è parte architetto, parte code reviewer, parte operatore di AI. Si spende meno tempo a scrivere codice da zero e più tempo a:

  • Progettare l’architettura e definire i confini
  • Supervisionare ciò che l’agent produce
  • Verificare che il codice generato abbia senso nel contesto del progetto
  • Debuggare i casi limite che l’AI non ha previsto

Le team più efficaci che abbiamo osservato sono quelle che trattano il codice AI-generated come un junior developer molto veloce ma poco esperto: utile, produttivo, ma che ha bisogno di review costante.

Lo confermano anche i dati: i team senior gestiscono carichi di lavoro che prima richiedevano più persone, non perché l’AI fa tutto — perché i senior hanno imparato a guidare gli agent invece di competere con loro.

La nostra posizione: vibe coding sì, ma con le mani sul volante

Dopo mesi di uso quotidiano di Cursor, Claude Code, Copilot e altri tool su progetti reali — dal prototipo veloce al tool interno per l’homelab — la nostra posizione è questa:

Il vibe coding è uno strumento potente, non una sostituzione. Funziona eccezionalmente per prototipazione, boilerplate e compiti ben definiti. Fallisce (o meglio, ti fa perdere tempo) su architetture complesse, progetti grandi e debugging profondo.

Le fondamenta contano più che mai. Non serve una laurea in informatica, ma serve aver costruito cose da zero, averle rotte, averle riparate e aver imparato come falliscono. Senza questa base, il vibe coding è una trappola: produci velocemente codice che non capisci e che non sai debuggare.

Il vero skill nel 2026 è il giudizio. Saper chiedere la cosa giusta, saper valutare se la risposta ha senso, sapere quando fidarsi e quando verificare. Il prompting è importante, ma il pensiero critico è indispensabile.

Karpathy stesso ha suggerito che l’evoluzione naturale del vibe coding sia ciò che chiama “agentic engineering” — dove l’intento umano guida l’esecuzione autonoma dell’AI. Ma la sostanza non cambia: l’AI può scrivere codice, ma la decisione su cosa scrivere e perché resta umana.