Di cosa parla la fonte

Achint Mehta, ricercatore indipendente, in un preprint su arXiv ha fatto costruire a un agente di coding la stessa applicazione per 90 volte: una lavagna per retrospettive in tempo reale, con front end React, back end Node.js, database SQLite e consegna in un container Docker, cioè un pacchetto autonomo che si avvia uguale su qualunque macchina. La specifica è identica per tutte le esecuzioni ed è stata scritta apposta per lo studio, così nessun modello può averla già incontrata in un benchmark pubblico. Ogni risultato è verificato su 14 criteri da tre punti: 3 se la funzione va al primo tentativo, 2 se va dopo un solo messaggio di correzione, 1 se resta rotta. Il massimo è 42.

Di esecuzione in esecuzione cambia un fattore alla volta: il modello; l’effort di ragionamento, cioè quanto l’agente «pensa» prima di agire (High o xHigh); la presenza di Playwright, uno strumento che pilota un browser, clicca, scrive e fa screenshot dell’applicazione mentre gira; un’istruzione di design che chiede un’interfaccia curata. Tre risultati contano qui. A parità di modello e di effort, Playwright non cambia il punteggio e la mediana del costo sale del 42% a High e del 68% a xHigh. Portare l’effort da High a xHigh, sullo stesso modello, fa passare le esecuzioni perfette al primo colpo da 5 su 18 a 16 su 18, con un costo in più fra il 9 e il 29%. E il guasto più frequente non sta nell’interfaccia: il container fallisce al primo tentativo in 40 esecuzioni su 90 (44%), e i due criteri d’ambiente — installare e avviare in locale, costruire il container — fanno da soli 55 dei 100 fallimenti al primo colpo.

Che ne penso

Il risultato sul tool di test è meno sorprendente di quanto sembri, e per questo è istruttivo. Playwright guarda l’applicazione dal lato dell’utente: apre la pagina, clicca, confronta ciò che vede. Il difetto dominante stava più in basso: un modulo nativo di SQLite che non compila nel container minimale, una modifica incompatibile di Express 5 che non accetta più la rotta jolly usata per servire il front end. Quando la build fallisce non c’è nessuna interfaccia da guardare. Uno strumento puntato sul livello sbagliato non trova meno difetti: non li vede. L’autore lo nota anche sui criteri che l’interfaccia mostra: nel confronto a coppie su Opus 4.6 i fallimenti al primo colpo sono stati 1 su 7 senza il tool e 3 su 7 con. Sono numeri piccoli e non li userei per dire che il tool peggiora le cose, ma non mostrano nemmeno il contrario.

Il conto è istruttivo. I token prodotti dal modello, cioè il codice che scrive, restano praticamente fermi: a High la mediana è 42 mila con il tool contro 46 mila senza. Crescono di due-tre volte i token riletti dalla cache, cioè il contesto della sessione che il modello rilegge a ogni passo e che il tool riempie di screenshot e scambi con il browser. L’agente non ha lavorato di più: ha riletto di più. Chi ha tenuto in piedi una suite end-to-end lo sa: il costo di un controllo non dipende dai difetti che trova, si paga a ogni esecuzione.

Va detto però cosa questo confronto non misura. Il prompt di sistema che Claude Code inietta senza mostrarlo all’utente (l’autore l’ha recuperato e letto) chiede già all’agente di provare le modifiche all’interfaccia in un browser prima di dichiarare il lavoro finito. La condizione «senza tool» non è quindi «senza istruzione di verifica visiva»: non sappiamo se le esecuzioni base l’abbiano seguita davvero, ma il confronto misura quanto aggiunge Playwright a un’istruzione che c’era già, non quanto valga guardare l’interfaccia. Sono due domande diverse, e il titolo dell’abstract invita a leggere la seconda.

Il dato sull’effort è quello che cambierebbe di più il modo di lavorare, ed è anche quello che il totale nasconde. A High la media è 41,0 su 42, a xHigh 41,8: meno di un punto. Letto per criterio, le esecuzioni perfette al primo colpo passano dal 28% all'89% e i messaggi di correzione necessari da 16 a 3 su 18 esecuzioni. La scheda di valutazione dà 2 punti su 3 a una funzione sbagliata e poi riparata, quindi il totale misura dove l’agente arriva alla fine, non cosa consegna la prima volta. È lo stesso meccanismo di cui parlavo a proposito dei punteggi dei benchmark, con una differenza: lì il numero cambiava con l’impalcatura, qui cambia con la regola di conteggio. L’autore propone di pubblicare accanto al totale la quota di riuscite al primo colpo e il numero di interventi correttivi, e ogni intervento corrisponde a una persona che deve intervenire.

La leva però ha un limite, e lo mostrano i dati stessi. Con l’istruzione di design aggiunta, xHigh non basta più: su Opus 4.7 le esecuzioni perfette al primo colpo sono 6 su 6 senza l’istruzione e 1 su 6 con la sua versione breve (4 su 6 con quella completa), e i fallimenti si dividono fra il container e il trascinamento delle card, la funzione più ricca di interazione. Anche una richiesta in più ha un prezzo in affidabilità, non solo in token, e dal totale non si vede.

Tutto questo poggia su una sola applicazione, su un autore che ha verificato ogni esecuzione conoscendone la configurazione, su celle di sei o sette esecuzioni e su condizioni scelte e non assegnate a caso. 85 esecuzioni su 90 usano modelli di un solo fornitore, e xHigh esiste solo su una famiglia. Con celle così piccole l’autore stesso avverte che si vedono solo differenze grandi: un effetto del tool sotto i due punti su 42 non sarebbe emerso. Le trascrizioni delle sessioni non sono state conservate, quindi i messaggi di correzione non si possono rileggere. E quel 44% di container che falliscono al primo colpo dipende anche da una convenzione di conteggio: l’autore verificava su un host Windows mentre gli agenti lavoravano nel proprio ambiente, e le differenze sono contate come fallimenti. Io la leggerei come ciò che vedrebbe chi riceve il pacchetto, ma è una scelta, ed è dichiarata. Dice anche che l’effetto è approssimato e che solo la direzione e l’ordine sono robusti.

Cosa mi porto a casa

Prima di aggiungere un controllo a una pipeline, o a un agente che ne scrive il codice, scrivi accanto il guasto che deve intercettare e guarda dove sono caduti gli ultimi fallimenti. Se stanno nella build, un test sull’interfaccia è una spesa senza difetti da trovare. L’autore dice che uno smoke test sul container, cioè un controllo minimo che verifica soltanto che il sistema si avvii, avrebbe potuto prenderli, ma non l’ha provato, quindi non sappiamo quanto.

E misura due cose che il totale non mostra: quante esecuzioni vanno a buon fine senza correzioni e quanti interventi correttivi servono. La prima dice quanto ci si può fidare del risultato senza guardarlo, la seconda quanto costa, in ore di una persona, quando non ci si può fidare.