L’agentic engineering può essere considerato la frontiera più avanzata della programmazione assistita da intelligenza artificiale, un paradigma che supera il semplice vibe coding per introdurre agenti capaci di pianificare, eseguire e verificare autonomamente il codice.
Questa evoluzione, teorizzata da Andrej Karpathy, sta ridefinindo i processi di sviluppo software e richiede nuove competenze ingegneristiche.
Indice degli argomenti
L’evoluzione del lessico nella programmazione AI
Di fatto, nel giro di dodici mesi il lessico della programmazione assistita dall’intelligenza artificiale è cambiato due volte. Prima è arrivato il “vibe coding“, l’idea che, grazie a modelli linguistici sempre più efficaci, si possa costruire software conversando e accettando patch quasi senza leggere i diff.
Poi, all’inizio di febbraio 2026, Andrej Karpathy ha proposto un’etichetta più ambiziosa, “agentic engineering”, per descrivere un passaggio ulteriore. Non è soltanto una questione di marketing.
Dietro la formula c’è la tesi che l’unità di lavoro non sia più l’assistente che completa funzioni o spiega errori, ma un agente capace di pianificare, agire e verificare, in un loop che ricorda da vicino il modo in cui lavorano i team umani. Il punto interessante, per chi sviluppa o governa tecnologia in azienda, è che questa evoluzione non coincide solo con modelli più potenti.
Coincide con l’emergere di pratiche ingegneristiche nuove, orientate all’orchestrazione di strumenti, all’osservabilità dei passaggi intermedi, alla gestione del contesto e alla mitigazione del rischio. In altre parole, se il vibe coding ha reso virale l’idea che “il codice può sparire”, l’agentic engineering sta cercando di riportare disciplina, metodi e responsabilità in un processo dove l’esecutore primario è una macchina.
Dal “vibe coding” alla professionalizzazione dell’assistenza
Il “vibe coding” nasce come provocazione e come descrizione fedele di un comportamento reale. Nel post con cui Karpathy introduce il termine, la scena è quella di un programmatore che chiede cambiamenti minuti e procede per tentativi, delegando alla macchina gran parte del lavoro e accettando correzioni in modo quasi automatico. La definizione ha attecchito perché ha dato un nome a un’abitudine già diffusa, favorita da editor e ambienti di sviluppo che integrano modelli generativi e rendono l’interazione estremamente fluida.
Negli stessi mesi, la categoria di strumenti legata a questa modalità è diventata un fenomeno economico. L’editor Cursor ha annunciato nel novembre 2025 un round di finanziamento da 2,3 miliardi di dollari, dichiarando di aver superato 1 miliardo di dollari di ricavi annualizzati.
Nello stesso periodo Lovable, startup europea spesso citata come esempio di “builder economy” guidata da prompt, ha comunicato una Serie B da 330 milioni di dollari a una valutazione di 6,6 miliardi. Questi numeri non sono solo un segnale di entusiasmo. Sono un indicatore di quanto rapidamente l’AI stia spostando valore verso l’interfaccia di sviluppo, cioè verso chi controlla la conversazione e l’integrazione con i repository. Dentro questo quadro, il salto semantico verso “agentic engineering” nasce anche da una necessità di distinzione.
Il vibe coding, per sua natura, porta con sé l’idea dell’approssimazione, della sperimentazione rapida e della tolleranza verso codice che cresce oltre la piena comprensione di chi lo accetta. In contesti professionali, soprattutto quando entrano in gioco sicurezza, compliance e manutenzione, la stessa fluidità che accelera può diventare fragilità.
Che cosa significa “agentic engineering”
Nel modo in cui Karpathy lo descrive pubblicamente, “agentic engineering” punta a separare due ruoli. Da un lato c’è l’agente, che scrive, esegue, corregge e itera. Dall’altro c’è l’essere umano, che definisce obiettivi, vincoli e criteri di accettazione, e che costruisce la cornice entro cui l’agente opera.
Non si tratta dunque di “chiedere codice”, ma di progettare un sistema che produce codice in modo ripetibile. Questa cornice ha diverse componenti.
C’è la capacità di usare strumenti, come esecuzione di test, gestione di branch, analisi statica, ricerca nel codebase e talvolta interazione con un browser o con un ambiente grafico.
C’è la memoria, cioè la scelta di cosa mantenere in contesto e cosa archiviare in forme più strutturate.
C’è l’osservabilità, perché senza log e tracciamento dei passaggi intermedi diventa difficile attribuire responsabilità e capire perché una modifica sia stata prodotta.
Infine c’è la governance, perché un agente che può agire sul repository ha, di fatto, una superficie d’attacco simile a quella di un account con permessi elevati.
Strategie dei principali player tecnologici
Molti fornitori stanno traducendo questi principi in prodotti e linee guida. Anthropic, per esempio, ha pubblicato già nel 2024 un documento di ricerca su come costruire agenti efficaci, insistendo sull’importanza di tool ben documentati e di cicli di feedback semplici, più che su architetture esoteriche.
Nel 2025, la stessa azienda ha approfondito il tema dell’orchestrazione, sostenendo che una parte del controllo debba essere implementata in codice, con logica esplicita, invece di restare interamente nel linguaggio naturale. Anche OpenAI, sul fronte degli strumenti, ha consolidato nel tempo il paradigma del function calling, che rappresenta uno dei mattoni tecnici per passare da chatbot a agenti che eseguono azioni.
I benchmark come bussola e come trappola
Il passaggio da assistenza a “agenticità” ha un effetto immediato: serve misurare. La comunità ha adottato SWE-bench come benchmark di riferimento per valutare se un modello riesce a risolvere issue reali estratte da repository open source.
Il dataset, introdotto da Jimenez e colleghi, ha avuto il merito di spostare la valutazione da esercizi sintetici a task con contesto, dipendenze e test. Tuttavia, proprio il successo di SWE-bench mostra un limite tipico delle metriche. I risultati migliorano rapidamente, ma non sempre si traducono in affidabilità percepita dagli sviluppatori.
Negli ultimi due anni sono comparsi tentativi di rendere le valutazioni più realistiche, anche includendo domini visuali o linguaggi diversi da Python, come nel caso di SWE-bench Multimodal.
La direzione è chiara. Se l’agentic engineering vuole diventare prassi industriale, deve dimostrare robustezza fuori dai confini del benchmark più comodo. In parallelo, la scala delle valutazioni sta diventando infrastruttura. AI21, per esempio, ha raccontato come ha gestito centinaia di migliaia di esecuzioni su SWE-bench, descrivendo problemi pratici come isolamento degli ambienti, riproducibilità e gestione di run fallite. Anche questo è agentic engineering, non nel senso dell’output, ma nel senso dei sistemi che rendono l’output misurabile.
Dall’agente “demo” all’agente in produzione
Il caso più noto di narrazione “agente che lavora da solo” è Devin, presentato da Cognition nel marzo 2024 come un sistema in grado di prendere in carico issue, configurare ambienti, scrivere patch e validarle.
L’annuncio ha colpito perché mostrava un flusso end-to-end, inclusi browser, shell e editor, e perché agganciava la promessa a un benchmark pubblico. A fine 2024 la stessa società ha annunciato la disponibilità generale del prodotto, segnando il passaggio dalle dimostrazioni alla vendita. Da allora, la lezione più importante non è che l’autonomia sia “tutta o niente”.
È che la produttività cresce quando si costruisce una collaborazione ben definita tra umano e agente. In contesti reali, l’agente tende a eccellere nel lavoro iterativo, nella ricerca nel codice, nella scrittura di test e nella generazione di patch ripetitive. L’essere umano resta centrale nel definire priorità, interpretare requisiti ambigui, valutare trade-off architetturali e, soprattutto, assumersi la responsabilità del rischio.
Implicazioni organizzative e sicurezza
Quando un agente non si limita a suggerire ma esegue, il confine tra produttività e vulnerabilità si assottiglia. L’automazione può amplificare bug e introdurre dipendenze o pattern insicuri con una velocità superiore a quella dei processi di revisione tradizionali. Inoltre, un agente che usa strumenti può essere indotto a compiere azioni indesiderate, per esempio attraverso prompt injection in documentazione, issue o pagine web consultate durante il lavoro.
Non sorprende quindi che il dibattito su agenti e sicurezza stia salendo di livello. Alcune analisi recenti sul rischio legato a modelli più potenti insistono sul fatto che l’autonomia aumenta l’impatto potenziale di un abuso, perché riduce il numero di passaggi umani necessari per trasformare un’intenzione in un’azione. In parallelo, si vedono segnali di adozione in settori regolati, come la finanza, dove l’interesse per agenti capaci di automatizzare processi interni convive con la cautela legata a audit e controllo.
Per le organizzazioni, la conseguenza pratica è che “insegnare a usare un assistente” non basta. Serve definire policy su permessi, ambienti sandbox, gestione dei segreti, logging, test obbligatori e criteri di accettazione. In questo contesto, il termine “agentic engineering” è utile perché sposta l’attenzione dalla magia del modello alla qualità dell’ingegneria che lo circonda.
Conclusione
Il passaggio dal vibe coding all’agentic engineering non racconta soltanto un’evoluzione tecnologica. Racconta una maturazione culturale. Il vibe coding ha reso evidente che il linguaggio naturale è diventato un’interfaccia di programmazione e che la barriera d’ingresso allo sviluppo può crollare in molti casi d’uso. L’agentic engineering, invece, prova a definire come questa potenza possa essere incanalata in processi affidabili, misurabili e governabili.
Per chi sviluppa prodotti software, la domanda che conta non è se gli agenti scriveranno codice, perché lo stanno già facendo in misura crescente.
La domanda è chi progetterà l’ecosistema di strumenti, metriche e regole che rende quel codice utilizzabile nel tempo. È qui che si giocherà la differenza tra una stagione di prototipi fulminei e una trasformazione strutturale della produzione software.
