← Blog

Agentic engineering: un mestiere, non una scelta di strumento

Marco Masut

Agentic engineering indica la pratica di costruire software delegando l'esecuzione a un agente di coding, mentre una persona tiene per sé l'obiettivo, i vincoli e la decisione finale su cosa va in produzione. Non è una preferenza per uno strumento rispetto a un altro. È quello che il mestiere di scrivere software sta diventando, un task delegato alla volta, ed è la versione pratica di un cambiamento più ampio che sta già ridisegnando la produzione software.

Cercando il termine oggi, la prima pagina mette a fianco IBM due blog personali, quelli di Simon Willison e Addy Osmani, entrambi scritti attorno alla propria pratica quotidiana. Quel mix è il segnale: su questa domanda una risposta specifica e vissuta batte un dominio autorevole. Questa vuole essere una di quelle risposte.

Come cambia concretamente il lavoro, oggi?

Chi fa agentic engineering passa meno tempo a digitare sintassi e più tempo su quattro cose: tre prima che l'agente parta, una dopo. Prima: delimitare il task abbastanza stretto perché "fatto" abbia un significato verificabile, scrivere criteri di accettazione su cui giudicare l'agente invece che a sensazione, e decidere quanto contesto e quali strumenti l'agente può toccare. Dopo: leggere il diff che restituisce prima che venga unito a tutto il resto. Nessuna di queste quattro cose esisteva come competenza nominata cinque anni fa; insieme erano una parte piccola del lavoro, gestita quasi da sola mentre si scriveva il codice a mano. Tutte e quattro decidono oggi se una sessione produce qualcosa che un team può rilasciare o qualcosa che sembra finito e non lo è. L'agente scrive ancora la maggior parte dei caratteri. Non decide cosa vuol dire "corretto" per questa modifica specifica, in questo codebase specifico, per questo cliente specifico. Quella decisione, e la responsabilità che porta con sé, non si è spostata da nessuna parte.

Quali competenze sono diventate centrali?

  • Delimitare un task abbastanza stretto perché un agente possa davvero portarlo a termine, invece di girarci attorno
  • Scrivere i criteri di accettazione prima che la sessione parta, non dedurli dal risultato a posteriori
  • Leggere un diff per l'intento e gli effetti collaterali, non solo per la sintassi
  • Decidere quando fermare un agente che tecnicamente sta ancora producendo, ma nella direzione sbagliata
  • Sapere quali parti di un codebase un agente non deve mai toccare senza supervisione

L'autocomplete premiava la velocità di battitura. L'agentic engineering premia il giudizio esercitato prima e dopo la sessione dell'agente, non durante. Lo Stack Overflow Developer Survey 2025 registra che il 69% di chi usa agenti di coding dichiara una produttività individuale più alta, ma solo il 17% dichiara una collaborazione di team migliorata. La velocità sulla tastiera non è mai stata la competenza scarsa; decidere cosa vale la pena costruire, e verificare che sia stato costruito bene, lo è sempre stata. L'agentic engineering ha solo portato questo fatto alla luce.

Come si legge un diff che non hai scritto?

Contro i criteri di accettazione scritti prima che la sessione partisse, non contro quanto il codice sembra plausibile. Un diff prodotto da un agente compila, spesso passa i test che gli sono stati assegnati, e può comunque fare la cosa sbagliata per un motivo sottile: risolvere un problema leggermente diverso da quello richiesto, allargare in silenzio un permesso, o prendere una scorciatoia che funziona oggi e si rompe su un caso che nessuno aveva specificato. Il trial randomizzato controllato di METR del 2025 ha trovato che sviluppatori esperti che usano strumenti AI erano il 19% più lenti su task reali, pur avendo previsto in anticipo di essere il 24% più veloci, e credendo a posteriori di essere stati il 20% più veloci. L'autovalutazione dentro la sessione non è affidabile. Il diff, letto a freddo contro un criterio scritto, è ciò che l'agentic engineering chiede a un team di usare al suo posto.

Come si capisce quando fermare l'agente?

Una sessione che sta ancora producendo output non è la stessa cosa di una sessione che è ancora sulla strada giusta. Il segnale da guardare è se l'agente sta convergendo sui criteri di accettazione o se sta scivolando su un lavoro adiacente, plausibile, ma mai richiesto. Fermarsi presto costa qualche minuto per ripartire; lasciare che una sessione andata fuori rotta arrivi a "fatto" costa un diff che va letto con la stessa attenzione di uno perfettamente in linea, perché dall'esterno sembra identico. Molti team lo imparano nel modo costoso, una volta sola, e dopo cominciano a controllare i segnali qui sotto prima di lasciare andare avanti una sessione lunga senza supervisione.

| Segnale | Si continua | Ci si ferma e si ridelimita | | --- | --- | --- | | Dimensione del diff | Coerente col task | Cresce su file non correlati | | Modifiche ai test | I nuovi test rispecchiano i criteri | Test esistenti indeboliti o saltati | | Spiegazione dell'agente | Coerente con quanto richiesto | Risolve un problema diverso, adiacente | | La tua sicurezza | Sapresti spiegare il diff a un cliente | Dovresti chiedere all'agente cosa ha fatto |

Cosa deve restare tuo?

Lo scope, i criteri di accettazione, la decisione di fermarsi e quella di rilasciare: nessuna di queste è il lavoro dell'agente, e nessuna compare automaticamente come prova quando la sessione si chiude. Un team che tiene l'agentic engineering solo come competenza nella testa delle persone, passata informalmente da un ingegnere senior al successivo, ha lo stesso vuoto che la delega tra subagent e un file di istruzioni come AGENTS.md già mostrano a livello di strumento: quello che una persona ha deciso e autorizzato durante una sessione non è lo stesso registro di quello che la sessione ha effettivamente fatto.

Detent, l'impianto di delivery end-to-end (detent-ai.com), esiste per tenere quel secondo registro, così il giudizio descritto qui lascia qualcosa a cui un team può appoggiarsi anche quando l'ingegnere che ha lanciato la sessione è già passato al task successivo — lo stesso criterio che Detent Bench misura lungo la linea, dalla richiesta al pronto per la produzione.