Agentic Engineering: Da Vibe Coding a Disciplina

Un anno fa Andrej Karpathy twittava "I 'Accept All' always, I don't read the diffs anymore". Oggi dice che il 99% del tempo lo passa a orchestrare agenti che scrivono codice al posto suo.

In mezzo ci sono dodici mesi che hanno ridefinito cosa significa fare software. Non gradualmente — a strappi, con un vocabolario che si è riscritto tre volte in un anno. Prima "vibe coding", poi "context engineering", ora "agentic engineering".

Ogni termine racconta un pezzo della storia. E la storia racconta dove stiamo andando.

La timeline: dodici mesi in tre atti

Partiamo dai fatti, in ordine.

2 febbraio 2025 — Karpathy pubblica il tweet che diventerà parola dell'anno: "vibe coding". Descrive un modo di programmare dove ti arrendi alle vibes, accetti tutto, non leggi le diff. "Not too bad for throwaway weekend projects", scrive. La community esplode. Il termine esce dal tech e finisce sul Collins Dictionary.

Metà 2025 — Tobi Lutke, CEO di Shopify, popolarizza un concetto diverso: "context engineering". Lo definisce come "the art of providing all the context for the task to be plausibly solvable by the LLM". Il focus si sposta: non basta chiedere, bisogna dare all'agente tutto ciò che gli serve per rispondere bene. Chi ha approfondito il tema sa che il context engineering è diventato rapidamente una disciplina a sé.

26 dicembre 2025 — Karpathy torna con un tono diverso: "I've never felt this much behind as a programmer. The profession is being dramatically refactored." Non più vibes. Qualcosa è cambiato.

Gennaio 2026 — Un'altra bomba: "Coding agents basically didn't work before December." Tradotto: tutto quello che abbiamo visto prima di dicembre 2025 era un antipasto. Gli agenti hanno fatto un salto qualitativo enorme in poche settimane.

4 febbraio 2026 — Esattamente due anni dopo il tweet originale, Karpathy conia il termine successivo: "agentic engineering". Lo spiega così: "'Agentic' because the new default is that you are not writing the code directly 99% of the time, you are orchestrating agents who do."

Da "Accept All" a "orchestrare agenti". Dodici mesi.

Cos'è davvero l'agentic engineering

Servono definizioni precise, perché i termini in questo settore si logorano in fretta.

Simon Willison, creatore di Datasette e voce tra le più lucide nel panorama AI, la mette così: "Building software using coding agents — tools like Claude Code and OpenAI Codex, where the defining feature is that they can both generate and execute code."

Non è autocompletamento. Non è suggerimenti inline. È un agente che genera codice, lo esegue, verifica il risultato, itera. Tu gli dai la direzione. Lui fa il lavoro.

Karpathy aggiunge una sfumatura importante con la scelta della parola "engineering": "'Engineering' to emphasise that there is an art & science and expertise to it." Non è premere un bottone. C'è mestiere, c'è scienza, c'è esperienza che conta.

Ma la metafora più potente è di Addy Osmani, lead del team Chrome di Google: "The most useful mental model is that you are building the factory that builds your software."

Non stai più costruendo il software. Stai costruendo la fabbrica che costruisce il software. È un livello di astrazione sopra. Ed è un cambio di paradigma reale.

Vibe coding vs agentic engineering: la distinzione che conta

Il vibe coding non è morto — ha trovato il suo posto. Ma è fondamentale capire dove finisce uno e dove inizia l'altro.

	Vibe Coding	Agentic Engineering
Approccio	Casuale, improvvisato	Strutturato, guidato da expertise
Testing	Assente o minimale	Differenziatore principale
Target	Prototipi, weekend project	Produzione, software critico
Mindset	Automazione esplorativa	Orchestrazione professionale
Chi ne beneficia	Chiunque con un'idea	Senior con fondamentali solidi

Osmani lo dice senza giri di parole: "The single biggest differentiator between agentic engineering and vibe coding is testing."

Il testing. Non il prompt migliore, non il modello più potente, non il contesto più ricco. Il testing. Se scrivi test prima di far generare codice, l'agente ha un criterio oggettivo per verificare il proprio output. Se non li scrivi, stai facendo vibe coding — anche se ti senti molto professionali.

Il ribaltamento 70/30

C'è un numero che racconta il cambiamento meglio di qualsiasi definizione.

Osmani riporta che nel workflow di agentic engineering il rapporto si è invertito: 70% del tempo sulla definizione del problema, 30% sull'esecuzione. Prima era il contrario. Passavi la maggior parte del tempo a scrivere codice, e una fetta minore a capire cosa scrivere.

Oggi il lavoro pesante è a monte. Definire i requisiti. Scrivere le specifiche. Preparare il contesto. Scegliere i vincoli architetturali. Scrivere i test. Poi lanci l'agente e lui esegue.

I numeri macro confermano che qualcosa si è sbloccato: nuovi siti web +40% anno su anno, app iOS +50%, push su GitHub negli USA +35%. Zapier riporta un'adozione AI del 97% tra i propri dipendenti. Non sono più early adopter — è mainstream.

Ma attenzione: più codice non significa necessariamente codice migliore. Il che ci porta al problema vero.

Il verification gap: il collo di bottiglia si è spostato

Osmani individua il nodo centrale con precisione chirurgica: "Generation capacity has outpaced verification abilities. Verification, not generation, represents the current constraint."

Leggi bene: la capacità di generare codice ha superato la capacità di verificarlo. Il bottleneck non è più scrivere — è capire se quello che è stato scritto è corretto.

È un ribaltamento storico. Per decenni il vincolo era la produzione: servivano più sviluppatori, più ore, più righe di codice. Oggi il codice si genera in secondi. Il vincolo è la review. La comprensione. La verifica.

Questo spiega perché il testing è il discriminante tra vibe coding e agentic engineering. Senza test automatizzati, come verifichi l'output di un agente che produce centinaia di righe al minuto? Non puoi leggere tutto. Ma puoi far girare una suite di test.

Chi padroneggia il tool use e sa costruire pipeline di verifica automatizzate ha un vantaggio competitivo enorme. Chi si limita a leggere l'output e fare "Accept All" è tornato al vibe coding — solo con più righe di codice da controllare.

Il paradosso del senior

Ecco un'altra osservazione di Osmani che merita attenzione: "Agentic engineering disproportionately benefits senior engineers with strong fundamentals. Junior developers risk 'dangerous skill atrophy'."

È controintuitivo. Ti aspetteresti che l'AI livellli il campo — i junior diventano più produttivi, il gap si riduce. Invece succede il contrario. I senior ne beneficiano di più perché sanno cosa chiedere, riconoscono quando l'output è sbagliato, e hanno il contesto per guidare l'agente nella direzione giusta.

I junior rischiano quella che Osmani chiama "dangerous skill atrophy". Se impari a programmare facendo approvare output dell'AI senza capirli, non stai imparando — stai accumulando debito cognitivo. Ne abbiamo parlato in dettaglio nell'articolo sul deskilling, e i dati sono preoccupanti.

Ma attenzione a non semplificare troppo. Come abbiamo visto nell'analisi senior vs junior nell'era AI, essere senior non garantisce nulla: lo studio METR mostra che sviluppatori esperti sono in media il 19% più lenti con l'AI, convinti di essere più veloci. E i junior "affamati" — quelli che studiano, smontano, capiscono — possono sorprendere tutti. La linea di divisione vera non è anzianità, è attitudine: chi impara il nuovo workflow e chi no.

Il paradosso resta, ma con una sfumatura: l'agentic engineering beneficia chi ha fondamentali solidi e la disponibilità a cambiare modo di lavorare. L'uno senza l'altro non basta.

Agentic engineering è management?

Questo è l'angolo che nessuno sta discutendo — e che secondo me è il più interessante.

Pensaci. Nel workflow che descrive Karpathy, il 99% del tempo lo passi a dare direzione e revisionare output. Non scrivi codice. Definisci obiettivi, stabilisci vincoli, fai review, deleghi l'esecuzione.

Sono le stesse identiche skill dell'engineering management.

Un engineering manager non scrive codice (o ne scrive pochissimo). Definisce cosa va costruito, come, con quali vincoli. Poi delega a un team di sviluppatori. Fa review delle PR. Dà feedback. Corregge la rotta.

Nell'agentic engineering fai esattamente la stessa cosa — solo che il "team" è fatto di agenti AI. Definisci l'obiettivo, prepari il contesto, lanci l'agente, fai review dell'output, dai feedback (nuovo prompt), iterhi.

La metafora della fabbrica di Osmani conferma questa lettura: non stai costruendo il prodotto, stai costruendo il sistema che costruisce il prodotto. È management. È meta-lavoro.

E questo ha implicazioni enormi. Significa che le soft skill dell'engineering management — comunicazione chiara, definizione precisa dei requisiti, capacità di fare review efficaci, gestione delle priorità — diventano competenze tecniche core. Non "nice to have". Core.

Il developer del futuro assomiglia più a un tech lead che a un coder. E questo richiede un ripensamento profondo di come formiamo le persone.

Lo scetticismo: le critiche serie

Non sarebbe un'analisi onesta senza le voci critiche. E su Hacker News — termometro affidabile del sentiment dev — lo scetticismo non manca.

La critica più sostanziale: "Gli agenti si bloccano quando i requisiti emergono durante l'implementazione." Chiunque abbia sviluppato software reale sa che i requisiti non sono mai completi all'inizio. Emergono mentre costruisci. E un agente AI, per quanto sofisticato, fatica a gestire l'ambiguità che un umano naviga per istinto.

Poi ci sono i costi. Un utente riporta: 9 agenti in parallelo a $1.000 al mese per un progetto da 300.000 righe di codice. Non è gratis. Non è nemmeno economico per molti team.

E c'è la questione degli strumenti: "Agent-mode in IDE tradizionali come Rider e VS è basically useless." L'agentic engineering funziona con tool dedicati — Claude Code, Cursor, Codex. Se il tuo workflow è un IDE tradizionale con un plugin AI appiccicato sopra, l'esperienza è mediocre.

Queste critiche non invalidano il trend. Ma ricordano che siamo ancora all'inizio. Gli agenti migliorano mese dopo mese — Karpathy stesso dice che prima di dicembre 2025 "non funzionavano" — ma non siamo al punto in cui funzionano per tutto, per tutti, sempre.

Gli otto livelli: dove siamo nella curva

Bassim Eledath ha proposto una tassonomia utile per capire a che punto siamo. Otto livelli di maturità nell'AI coding:

Tab Complete — autocompletamento base
Agent IDE — l'agente opera dentro l'IDE
Context Engineering — contesto strutturato per l'agente
Compounding Engineering — agenti che costruiscono su output precedenti
MCP and Skills — agenti con accesso a tool esterni
Harness Engineering — infrastruttura di testing e verifica automatizzata
Background Agents — agenti che lavorano in autonomia, senza supervisione continua
Autonomous Agent Teams — team di agenti che si coordinano tra loro

La maggior parte dei developer è tra il livello 2 e il 3. I più avanzati sono al 4-5. I livelli 7 e 8 sono ancora sperimentali.

Sapere dove sei nella scala ti aiuta a capire cosa ha senso imparare adesso e cosa può aspettare. Se sei al livello 2, il prossimo passo è il context engineering. Se sei al 4, è ora di investire in MCP e pipeline di testing automatizzate.

Cosa significa per chi sviluppa oggi

Non serve aspettare di capire tutto per agire. Alcune cose sono già chiare.

Il testing non è più opzionale. Era un best practice, ora è l'infrastruttura su cui si regge l'intero workflow. Se non sai scrivere test, impara. È la singola competenza con il ROI più alto nell'era degli agenti.

La definizione del problema è il lavoro. Il 70% del valore sta nel capire cosa costruire, come specificarlo, quali vincoli definire. Scrivere specifiche chiare non è burocrazia — è il codice sorgente dell'agentic engineering.

I fondamentali contano più di prima, non meno. L'agente moltiplica la tua competenza. Se sai cosa cercare, trovi i bug. Se non lo sai, li deployi. L'architettura software, i design pattern, la security — tutto questo diventa più importante quando il volume di codice prodotto esplode.

Sperimenta con gli agenti, non solo con i prompt. La differenza tra chiedere a ChatGPT di scrivere una funzione e orchestrare Claude Code su un task complesso è la stessa differenza tra mandare un'email e gestire un team. Sono skill diverse. Servono ore di pratica.

Il termine cambierà ancora, probabilmente. Tra sei mesi potremmo chiamarlo in un altro modo. Ma il trend sottostante — meno tempo a scrivere codice, più tempo a dirigere chi lo scrive — quello è irreversibile.

E la domanda non è se adattarsi. È quanto velocemente.

Fonti: