"Agentic coding" è una ricerca fatta da chi ha già usato l'autocomplete e vuole sapere qual è il passo successivo. Le guide che rispondono alla query, dai fornitori cloud ai blog tecnici, fanno un lavoro decente nel definire il termine e segnalare i rischi di lasciare un modello lavorare senza supervisione. Quello che quasi nessuna si chiede è una domanda più stretta e più pratica: quando il loop finisce e la sessione si chiude, cosa resta davvero in mano a un team.
È una domanda che conta più di quanto sembri. L'agentic coding non è una singola funzione che si attiva. È un loop che uno strumento esegue per conto vostro, più volte per ogni task, per lo più senza che nessuno osservi ogni singolo passaggio.
Cosa significa agentic coding, oltre l'autocomplete
L'autocomplete finisce la riga che si sta già scrivendo. L'agentic coding è un lavoro diverso: a un modello viene affidato un obiettivo, non una battitura, e lui lavora verso quell'obiettivo su un intero repository, in più passaggi, decidendo da solo cosa leggere, cosa modificare e quando considerarsi finito. Claude Code fa girare questo loop da terminale, anche headless. La modalità agente di Cursor lo fa girare dentro l'editor, con ogni modifica visibile mentre accade. Entrambi contano come agentici perché entrambi fanno, in modo sostanziale, più lavoro non supervisionato di quanto ne facesse mai uno strumento di completamento.
Quel divario, più lavoro non supervisionato per ogni richiesta, è l'intera ragione per cui il termine è servito. Ed è anche il motivo per cui quello che succede dentro il loop conta più di quanto contasse quando un umano approvava ogni singola riga.
Il loop: pianifica, modifica, esegue, verifica
Tolto il marketing di ciascuno strumento, gli strumenti agentici convergono sullo stesso loop in quattro passaggi. L'agente pianifica una modifica in base all'obiettivo e al contesto che riesce a vedere. Modifica uno o più file per portare avanti quel piano. Esegue qualcosa, test, una build, un linter, per controllare se la modifica funziona davvero. Poi verifica il risultato rispetto all'obiettivo e si ferma, riporta il risultato, oppure ricomincia il giro con quello che ha imparato.
Quel loop è ciò che distingue un agente da un autocomplete più intelligente: non produce solo una modifica, la produce e la controlla prima di riconsegnarla. È un miglioramento reale rispetto a codice che nessuno, umano o modello, aveva mai eseguito prima che lo vedeste. Ma è anche facile sopravvalutarlo. Una suite di test che passa dentro una sessione dice che il codice ha fatto quello che i test controllano. Non dice se il piano fosse quello giusto, se l'agente sia rimasto dentro il perimetro che era davvero autorizzato a toccare, o se il ragionamento dietro la modifica sopravviva alla sessione che l'ha prodotta.
Cosa misurano le guide esistenti
Gran parte di quello che si posiziona per "agentic coding" oggi, dagli spiegoni dei fornitori cloud ai blog tecnici ai contenuti dei vendor, fa bene una di due cose: definisce il loop, oppure avverte sul rischio di dare a un modello così tanta autonomia, accesso non revisionato a un codebase, loop che vanno fuori controllo, azioni che nessuno ha approvato. Entrambe sono utili, ed entrambe si fermano allo stesso confine: trattano il loop in sé come l'unità da spiegare. Cosa produce l'agente come output, una volta che il loop è finito e tutti sono passati oltre, non è la domanda a cui rispondono.
Cosa lasciano fuori: cosa resta quando il loop si ferma
Un loop completato lascia dietro di sé due cose per default: il codice modificato, e un log della sessione, tenuto nel formato che lo strumento usa. Nessuna delle due è costruita per rispondere a una domanda che torna continuamente sui progetti reali, settimane o mesi dopo: perché questa modifica è stata fatta in questo modo, chi o cosa era autorizzato a farla, e come sappiamo che quello che è stato eseguito corrisponde a quello che era stato davvero richiesto. Cosa lasciano fuori gli agenti di coding AI quando la sessione finisce è lo stesso vuoto visto dal lato della scelta dello strumento. Qui è una proprietà della pratica in sé, indipendente da quale agente esegue il loop.
Uno studio controllato randomizzato di METR del 2025 è un controllo utile su quanto fidarsi della sola verifica dentro il loop: sviluppatori esperti che hanno usato strumenti AI su task reali hanno impiegato circa il 19% in più, pur restando convinti di essere stati più veloci. Se chi ha eseguito il loop e lo ha visto succedere può giudicare male il risultato, un test che passa dentro la sessione non è, da solo, il tipo di prova che regge davanti a chi non c'era.
Una definizione di prova residua per l'agentic coding
La prova residua, per un loop che pianifica, modifica, esegue e verifica, è quello che resta controllabile dopo che la sessione è finita: l'intento dietro il task, il perimetro dentro cui l'agente era davvero autorizzato a lavorare, cosa ha eseguito passo per passo, e un oggetto che lega questi tre elementi, abbastanza specifico da poter essere controllato e abbastanza portabile da sopravvivere a un cambio di strumento. La verifica dentro il loop, i passaggi di esecuzione e verifica, controlla che l'output funzioni. La prova residua controlla che l'intero loop, piano incluso, corrisponda a quello che era stato richiesto e autorizzato. Rispondono a domande diverse, e al momento quasi niente nella categoria produce la seconda da solo.
In cosa si distingue dal vibe coding
Vibe coding e agentic coding vengono usati in modo intercambiabile come se fossero la stessa cosa, e non lo sono. Il vibe coding descrive un atteggiamento: accettare quello che il modello produce, tenere il ritmo, occuparsi dei dettagli dopo, spesso senza far girare granché di un loop vero e proprio. L'agentic coding, fatto bene, include già passaggi di verifica, pianifica, modifica, esegue, verifica, che il vibe coding tende a saltare. Questo lo rende un passo avanti reale in termini di rigore.
Non chiude però il divario di cui parla questo pezzo. Un team può far girare l'intero loop, ogni passaggio verificato, e ritrovarsi comunque con nient'altro che un log specifico dello strumento da mostrare a un cliente o a un revisore sei mesi dopo. Verificare dentro la sessione e produrre una prova che sopravvive alla sessione sono due soglie diverse, e superare la prima non vuol dire aver superato la seconda.
Quella seconda soglia è quella su cui Detent Bench misura gli agenti, sulla linea dalla richiesta al production-ready, indipendentemente da quale agente o quale loop ha prodotto la modifica.