"Agenti di coding AI" è una ricerca fatta da chi conosce già l'autocomplete e vuole qualcosa in più: uno strumento che legge un repository, pianifica una modifica, e lavora su più file senza bisogno di essere guidato passo passo. Ogni classifica che risponde a questa query ordina gli stessi strumenti sullo stesso asse, quanto scrivono bene il codice dentro una sessione. È una misura reale, ed è quella che riceve quasi tutta l'attenzione. Si ferma proprio nel punto in cui inizia il rischio vero per una software house: quando la sessione si chiude.
Cosa intendono i team per agenti di coding AI
Il termine oggi copre un lavoro preciso, non genericamente "AI che aiuta a scrivere codice". Un agente legge più del file aperto, pianifica una modifica sull'intero repository, modifica più file in sequenza, esegue comandi e test, e riporta il risultato quando considera il task 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 si chiamano agenti perché entrambi possono ricevere la descrizione di un task e lavorarci senza supervisione continua, a differenza di uno strumento di completamento che finisce solo la riga che si sta già scrivendo.
Questa distinzione conta per quello che segue: un agente, per definizione, fa più lavoro non supervisionato di quanto ne facesse uno strumento di completamento, il che significa che tra la richiesta e il risultato succede di più che nessuno ha osservato in tempo reale.
Cosa misurano le classifiche di oggi
Quasi ogni confronto sul mercato, su faros.ai, vellum.ai, zapier.com, augmentcode.com, misura la capacità: punteggi su benchmark, quanti file un agente tocca correttamente, quanto spesso il primo tentativo compila, quanto è veloce a finire un task. L'adozione spiega perché questo sia l'asse ovvio da misurare. Gli strumenti di coding sono la categoria più grande di spesa AI dipartimentale, vicina ai 4 miliardi di dollari nel 2025, con un'adozione sopra il 65% nei team di ingegneria del quartile piu' alto, secondo Menlo Ventures' 2025 State of Generative AI in the Enterprise. A questa scala, ordinare gli agenti sull'output grezzo ha senso come primo filtro.
Misura anche qualcosa di meno solido di quanto sembri. Uno studio controllato randomizzato di METR pubblicato a metà 2025 ha fatto completare a 16 sviluppatori open source esperti 246 task reali su codebase che conoscevano bene, con e senza strumenti AI. Prima di iniziare, prevedevano che l'AI avrebbe ridotto il tempo di completamento di circa il 24%. Il risultato misurato è andato nella direzione opposta: i task con l'AI consentita hanno richiesto circa il 19% in più. Gli sviluppatori, alla fine, restavano convinti di essere stati più veloci. Se chi ha fatto il lavoro e si è osservato mentre lo faceva può giudicare male il risultato, una classifica che misura la capacità dall'esterno sta misurando qualcosa che non corrisponde in modo affidabile a quello che è successo davvero.
Cosa non misurano
Nessuna delle classifiche chiede cosa resta quando il task viene segnato come finito. Non è una lacuna nel metodo, è fuori da quello che la categoria è costruita per produrre. Lo Stack Overflow Developer Survey 2025 mostra la forma del problema su scala: il 69% di chi usa agenti di coding dichiara una produttività individuale più alta, ma solo il 17% dichiara una collaborazione di team migliorata. Un output individuale più veloce e un team che si fida di quello che ha in mano non sono lo stesso risultato, e chiudere il primo divario non chiude il secondo.
Il DORA report 2025 aggiunge l'altra metà: l'adozione dell'AI è correlata a più throughput, ma anche a più instabilità nella consegna, non meno. Un team che spedisce più in fretta con un agente non sta automaticamente spedendo qualcosa di cui può rendere conto in seguito. Le classifiche sulla capacità rispondono a "quanto è bravo questo agente sul task". Non rispondono a "cosa ha in mano il team, dopo, per mostrare a un cliente o a un revisore perché una certa modifica è successa in un certo modo".
Una definizione di prova residua
La prova residua è quello che un team può ancora produrre dopo che l'agente, e la persona che lo ha lanciato, non ci sono più a spiegare la modifica: l'intento dietro il task, il contesto che l'agente era autorizzato a toccare, cosa ha effettivamente eseguito, e un oggetto che lega questi tre elementi, abbastanza portabile da sopravvivere a un cambio di strumento e abbastanza specifico da poter essere controllato, non solo preso sulla fiducia. Al momento, nessun agente della categoria produce questo come output. Claude Code e Cursor registrano entrambi il proprio ragionamento, nel proprio formato, in un posto che non si esporta se il team cambia strumento il trimestre successivo. Il log spiega la sessione a se stesso. Non la spiega a un revisore che non c'era.
Come confrontare gli agenti sulle prove, non solo sulla capacità
La capacità conta ancora, e il risultato di METR è un motivo per pesarla con attenzione, non per ignorarla: un punteggio su benchmark o la posizione in una classifica possono divergere da quello che un team vive davvero, in entrambe le direzioni. Il criterio che i confronti di oggi saltano è una domanda diversa da "quale agente è il migliore", ed è quella che decide se una software house può rispondere di una consegna mesi dopo: per una data modifica, qualcuno può indicare cosa è stato richiesto, cosa l'agente era autorizzato a toccare, cosa ha fatto, e una prova che questi tre elementi coincidano, indipendentemente da quale agente ha scritto il codice quella settimana.
Quel criterio non sostituisce come scegliere un assistente per il lavoro che si ha davanti oggi, né le differenze di flusso di lavoro che un confronto Claude Code contro Cursor deve ancora risolvere. Sta sopra entrambe le scelte. Detent Bench misura gli agenti proprio su questa linea, dalla richiesta al production-ready, non solo sulla capacità.