L’Ingegneria Agentica non è vibe coding con un nome migliore. È il modello operativo che trasforma il codice generato dall’AI in un sistema verificabile: contesto limitato, piani espliciti, modifiche piccole, gate di sicurezza e prove prima del merge.
La distinzione conta. Il termine “vibe coding”, introdotto da Andrej Karpathy nel febbraio 2025, resta utile come etichetta di rischio. Descrive uno stile in cui si può quasi dimenticare il codice. Va bene per esperimenti. Non è un modello di produzione per software che tocca clienti, denaro, sicurezza o dati reali.
L’episodio di David Ondrej del 17 maggio 2026, Stop Vibe Coding, Start Agentic Engineering – Micky, rende la differenza più chiara. L’ospite descrive un workflow in cui l’AI scrive gran parte del codice, ma l’umano disegna l’harness: contesto source-of-truth, PR piccole, review loop, regole sui package e handoff. La lezione utile non è il claim del 95% di codice scritto dall’AI. La lezione utile è la disciplina intorno all’agente.
Perché lo slogan non basta
Il vibe coding ottimizza la prima demo funzionante. L’Ingegneria Agentica ottimizza il secondo mese di manutenzione.
Un prompt può creare login, dashboard o flussi CRUD. La parte difficile arriva quando il codice deve reggere cambi di schema, input strani, permessi, deploy, test, feature flag, rollback e un altro engineer che lo modifica più avanti.
Il vecchio confronto tra velocità umana e velocità del modello è finito. I modelli generano codice più in fretta. La nuova domanda è se il team può dirigere quella velocità dentro un sistema che rende visibili le modifiche sbagliate prima che diventino costose.
L’Ingegneria Agentica tiene l’umano nel ruolo che conta: intento, scope, architettura, policy e criteri di accettazione. L’agente è un implementatore rapido, non il proprietario del problema. È la stessa logica di 5 Skill Claude per sviluppare con metodo: il valore non è il prompt, è il loop ripetibile.
Definizione pratica: l’Ingegneria Agentica è delivery software in cui agenti AI implementano parti importanti del lavoro dentro vincoli, prove e review loop progettati da umani.
Il modello operativo dell’Ingegneria Agentica
Il modello ha sei componenti.
Primo, il task viene scomposto prima che l’agente scriva codice. Un buon brief non dice “costruisci la feature”. Descrive modifica, file coinvolti, interfacce, ipotesi sui dati e fuori scope. Se il task non entra in una PR piccola, è troppo grande per un singolo run agentico.
Secondo, la codebase resta la source of truth. La documentazione aiuta, ma il contratto reale è codice che compila, test che passano, route esistenti e schemi usati in produzione. Nell’episodio di Ondrej si insiste sul dare all’agente il codice reale dei package e dei repository. È l’istinto giusto: gli agenti migliorano quando leggono il sistema reale invece di indovinare da documenti vecchi.
Terzo, l’harness decide quali tool l’agente può usare. Un modello senza tool predice testo. Un coding agent dentro un harness può leggere file, cercare simboli, eseguire test, aprire browser, chiamare API e produrre diff. Questa potenza richiede confini.
Quarto, il piano diventa un oggetto di accountability. Il piano mostra se l’agente ha capito la dimensione della modifica. Se implica una PR da 9.000 righe, il piano è sbagliato. Va diviso prima dell’implementazione.
Quinto, la review è un loop, non una cerimonia. Test, check statici, secondo agente e human review devono rafforzarsi. Il nostro articolo su Reviewmaxxing per le PR degli agenti spiega il punto: non vince il volume di token, vince la qualità della review.
Sesto, l’handoff è progettato. Quando un agente o una sessione si ferma, il prossimo operatore deve avere stato sintetico, errori noti, file modificati, comandi eseguiti e decisioni aperte. È per questo che i runtime degli agenti iniziano a sembrare sistemi operativi, come abbiamo scritto in Hermes v0.14: i runtime agentici diventano OS.
I budget di contesto battono i prompt giganti
Il context engineering è la competenza silenziosa dietro l’Ingegneria Agentica.
Una finestra di contesto grande non significa che ogni task debba riempirla. Più il prompt cresce, più l’agente deve separare segnale e rumore. La mossa pratica è dare codice, contratto, errore e test di accettazione esatti per lo step successivo.
I team di produzione devono essere più severi delle demo. Un buon working set è piccolo: una slice di feature, un service layer, un’interfaccia, una migration, un test fallito, un target di review. I task grandi diventano una sequenza di run piccoli con handoff pulito.
Il post OpenAI dell’8 maggio 2026 su running Codex safely mostra lo stesso punto dalla sicurezza. Sandbox, approval, accesso di rete gestito, identità, regole e telemetria esistono perché un coding agent agisce dentro un ambiente di sviluppo.
L’aggiornamento Codex del 14 maggio 2026 aggiunge un secondo segnale. OpenAI descrive live state, approval, diff, output terminale, risultati dei test, Remote SSH, hooks, access token con scope e secure relay in Work with Codex from anywhere. Non sono feature da vibe. Sono feature da control plane.
L’Ingegneria Agentica comincia quando i team trattano contesto, tool e approval come architettura.
I review loop sono il vero moltiplicatore
La storia della produttività non è “l’AI scrive il 95% del codice”. È: il team può rivedere più cambi utili ogni settimana con meno rischio.
Un workflow agentico debole aumenta il carico di review. Riempie il branch di codice plausibile, nasconde errori in diff grandi e costringe gli umani a ricostruire l’intento. Un buon workflow riduce il carico perché rende visibili intento e prove fin dall’inizio.
Ogni task agentico dovrebbe produrre quattro artefatti: piano, diff, prova di validazione e rischi residui. Se manca uno, il task non è finito.
La prova può essere test, typecheck, lint, route check, screenshot browser, output di security scan o una breve nota di accettazione manuale. La forma varia. La regola resta: niente prova, niente merge.
Per questo contano i workflow deterministici. In Archon Workflow Marketplace: coding IA deterministico su scala, l’idea utile non è un altro prompt. È la forma: plan, implement, validate, review, approve e solo dopo PR.
Le regole di sicurezza devono stare nel workflow
L’episodio di Ondrej include una regola concreta: non lasciare che gli agenti installino package più giovani di 14 giorni. Non è una legge universale, ma è un buon pattern di policy.
L’idea di fondo è solida. Gli agenti AI prendono rapidamente una dipendenza che sembra risolvere il problema. Questo crea rischio supply chain quando il package è nuovo, oscuro, typo-squatted o poco mantenuto. Un umano può fermarsi. Un agente ottimizza per completare, se l’harness non lo blocca.
L’Ingegneria Agentica trasforma quella pausa in policy. Regole sull’età dei package, allowlist, domini negati, modalità read-only, secret scanning, dependency review e approval gate devono vivere nel workflow. Non devono dipendere dalla memoria di qualcuno.
È la stessa lezione di Security harness, non sensazioni: Vercel deepsec. La security review funziona quando è ripetibile: scan, investigation, revalidation, contesto di ownership e percorso di fix.
Uno starter set basta: nessun nuovo package senza approval, review umana per package giovani, approval per comandi su secrets, auth, billing, dati di produzione o deploy, rete in allowlist dove possibile, write esterni loggati e reversibili, report finale con file, check e rischi.
Una checklist pratica per i team
I team non hanno bisogno di una piattaforma enorme per iniziare. Hanno bisogno di un piccolo loop ripetibile.
Si parte dal task brief: outcome utente, superfici coinvolte, vincoli, non-obiettivi e test di accettazione. Cinque minuti di brief spesso evitano un’ora di cleanup.
Poi si definisce il context pack: file rilevanti, contratti source, riferimenti API, shape dei dati e output fallito. Vecchie conversazioni e documenti non pertinenti restano fuori. L’obiettivo non è massimo contesto, ma contesto sufficiente.
Si chiede un piano prima del codice. Si controllano scope creep, migration nascoste, refactor troppo ampi e test mancanti. Se il piano è troppo grande, si divide.
Dopo l’implementazione servono prove. L’agente esegue i check minimi significativi e riporta il risultato. Se non può farli girare, spiega il motivo e indica la prova alternativa.
Poi la review diventa loop: secondo agente, strumenti statici e review umana. Chiedete rischi, non complimenti. Un reviewer utile dice cosa potrebbe rompersi.
Infine si cattura l’handoff: obiettivo, file modificati, decisioni, comandi, check passati, check saltati e rischi aperti. Senza handoff, il team perde il compounding del lavoro agentico.
FAQ
Che cos’è l’Ingegneria Agentica?
L’Ingegneria Agentica è delivery software in cui agenti AI implementano parti significative del lavoro dentro vincoli, review loop e prove progettati da umani. Combina disciplina del contesto, planning, permessi dei tool, validazione e handoff.
L’obiettivo non è togliere gli engineer. È permettere agli engineer di dirigere più implementazione in modo sicuro.
In cosa differisce dal vibe coding?
Il vibe coding ottimizza output rapido da prompt. L’Ingegneria Agentica ottimizza delivery affidabile: scope piccolo, contesto dal codice, prove di test, policy di sicurezza, review e handoff mantenibile.
Lo stesso modello può fare entrambe le cose. La differenza è il sistema intorno al modello.
I team dovrebbero far scrivere agli agenti la maggior parte del codice?
Possono farlo quando scope, test, review e rollback sono forti. La percentuale conta meno del control loop.
Un piccolo cambio agentico provato è più sicuro di un grande cambio non revisionato.
Qual è un buon primo workflow?
Iniziate con un loop limitato: brief, context pack, piano, implementazione, validazione, seconda review, human approval e handoff. Usatelo su feature interne a basso rischio.
Misurate dimensione PR, finding di review, test pass rate e rollback prima di scalare.
Quali controlli di sicurezza servono?
Minimo: approval dei package, secret scanning, limiti di rete, path protetti, approval dei comandi, audit log e report finale dei file modificati. Aggiungete regole più rigide per auth, billing, dati di produzione e post esterni.
Il punto è codificare prudenza nel workflow.
Conclusione: tenere la velocità, aggiungere il sistema
L’Ingegneria Agentica non rifiuta il vibe coding perché sia inutile. Rifiuta l’idea che un workflow da demo possa diventare production workflow senza modifiche.
I team migliori tengono la velocità e aggiungono il sistema: scope chiaro, piccoli context pack, piani basati sul codice, regole di sicurezza, review loop, prove di validazione e handoff pulito. Così il coding con AI diventa capacità di engineering.
Se il vostro team sta passando da demo AI a delivery software affidabile, Context Studios può aiutare a progettare quel loop operativo: agenti, policy, review gate e workflow di produzione che consegnano più in fretta senza fingere che il rischio sparisca.