IBM e Kaggle collaborano alla classifica aggiornata in modo continuativo di ScarfBench per le migrazioni

IBM e Kaggle stanno collaborando alla creazione di una classifica pubblica, aggiornata in modo continuativo, per ScarfBench, il benchmark open source di IBM per valutare gli agenti di programmazione nelle migrazioni tra framework Java aziendali, secondo una nota tecnica di IBM Research pubblicata il 27 ottobre 2026.

ScarfBench, abbreviazione di Self-Contained Application Refactoring Benchmark, verifica se un agente è in grado di prendere un’applicazione Java aziendale sconosciuta, migrarla tra i framework Jakarta EE, Quarkus e Spring e lasciare un software ancora funzionante. Il benchmark controlla che le applicazioni generate vengano compilate e avviate e continuino a comportarsi come previsto, usando sia carichi di lavoro mirati sia applicazioni complete. IBM ha presentato ScarfBench all’inizio del 2026 come benchmark riproducibile per le migrazioni basate sull’IA; l’annuncio originale, datato 11 marzo 2026, descriveva sette componenti, tra cui applicazioni aziendali sui tre framework verificate da sviluppatori, carichi di lavoro mirati che isolano aspetti come il comportamento della persistenza e l’iniezione delle dipendenze, applicazioni complete che combinano più livelli architetturali, la convalida automatizzata della compilazione e dell’avvio e test comportamentali che verificano il comportamento in fase di esecuzione e l’equivalenza funzionale. Secondo quanto dichiarato nell’annuncio, ogni carico di lavoro è stato implementato manualmente e convalidato da sviluppatori esperti per verificarne l’equivalenza funzionale e l’uso idiomatico dei framework.

La collaborazione tra IBM e Kaggle

Nell’ambito della collaborazione, Kaggle ha fornito consulenza a IBM sulla progettazione del benchmark e della valutazione, ha riprodotto ed eseguito ScarfBench in modo indipendente sulla propria piattaforma, sostenendo i costi di calcolo, e si occuperà della manutenzione del benchmark nel lungo periodo. IBM ha descritto come complementari le competenze dei due team: IBM ha sviluppato ScarfBench concentrandosi sulla modernizzazione di Java in ambito aziendale, mentre Kaggle mette a disposizione un’infrastruttura di valutazione indipendente e la gestione continuativa della classifica.

Risultati su 204 attività di migrazione

ScarfBench valuta un sistema agentico, non un modello linguistico isolato: ogni risultato riflette l’abbinamento tra un modello e un’infrastruttura per agenti di programmazione, che determina il modo in cui il modello interagisce con il repository e l’ambiente di sviluppo. IBM ha avvertito che i punteggi vanno interpretati come risultati dell’abbinamento modello/infrastruttura, non come misurazioni del solo modello sottostante.

Sulle 204 attività di migrazione e nelle dieci configurazioni modello/infrastruttura valutate, Gemini 4 Argon con l’infrastruttura Antigravity si è classificato al primo posto nella metrica principale dei test smoke, con il 75,2%, secondo quanto riportato da IBM; seguono Claude Opus 5.5 con Claude Code al 70,5% e Claude Opus 5 con Claude Code al 69,8%. Il punteggio smoke, usato come metrica della classifica, assegna punteggi parziali e attribuisce un peso maggiore alle suite di test più ampie. Nella misura più rigorosa, che considera superati tutti i test, Claude Opus 5.5 con Claude Code ha ottenuto il tasso più alto, pari al 72,1%, appena davanti a Gemini 4 Argon con Antigravity, al 71,1%.

Secondo il post, l’ordine delle prime posizioni è rimasto invariato anche nell’analisi di sensibilità. Quattro delle 204 attività non hanno ricevuto alcun credito nei test comportamentali da nessuna configurazione; escludendole, i punteggi assoluti sono aumentati senza cambiare i leader: Gemini 4 Argon con Antigravity ha ottenuto il 79,4%, seguito da Claude Opus 5.5 con Claude Code al 74,5% e Claude Opus 5 con Claude Code al 73,7%. IBM ha osservato che persino la combinazione più forte lascia ampi margini di miglioramento: nessuna configurazione ha superato integralmente più di circa tre quarti delle migrazioni.

Dove le configurazioni riescono e dove falliscono

Secondo quanto riportato da IBM, la differenza più ampia nella valutazione si è registrata tra il codice che viene compilato e il software che si comporta correttamente. Escluse le quattro attività con punteggio nullo, Claude Opus 5 con Claude Code, Gemini 4 Argon con Antigravity e Gemini 3.8 Flash con mini-swe hanno compilato il 100% delle attività; otto delle dieci configurazioni hanno compilato almeno il 97%. I punteggi dei test smoke, al contrario, presentavano uno scarto superiore a 50 punti. Tra le applicazioni distribuite correttamente, le configurazioni migliori si sono attestate intorno a una percentuale di test superati integralmente compresa tra il 63% e il 76%; Kimi K3 con kimi-code si è fermato al 53%, Gemini 3.1 Pro con OpenHands al 42% e Gemma 4 26B-A4B con mini-swe al 26%.

IBM ha classificato 745 esecuzioni non riuscite: 535, circa il 72%, sono state classificate come errori comportamentali in fase di esecuzione, nei quali l’applicazione veniva compilata e spesso avviata, ma non superava la convalida comportamentale. Questo gruppo comprendeva 304 discrepanze nei contenuti o nelle asserzioni, 210 casi di route mancanti o errori 404 e 21 errori HTTP 500 o 405 espliciti. Gli errori di compilazione o di packaging rappresentavano circa il 20% delle esecuzioni non riuscite, pari a 152 casi; gli arresti anomali all’avvio o nell’iniezione delle dipendenze circa l’8%, pari a 58 casi.

L’articolo presenta esempi a livello di singola attività. In concurrency-taskcreator-quarkus-to-jakarta, Claude Opus 5 con Claude Code ha ottenuto 0/6 dopo che l’endpoint /taskinfo ha restituito “File not found” e un test che si aspettava HTTP 405 non è stato superato. In address-book-jakarta-to-quarkus, GPT-6 Astra con Codex ha ottenuto 2/10 dopo che le pagine di elenco e creazione hanno restituito HTTP 404. In cargotracker-jakarta-to-spring, Gemini 3.8 Flash con mini-swe ha mantenuto la configurazione JSF/JoinFaces nel progetto Spring Boot di destinazione e non è riuscito ad avviarsi durante la creazione di un bean facesContext. In cart-spring-to-jakarta, GPT-6 Astra con Codex ha incontrato un errore di distribuzione perché il tipo di pacchetto lasciato dalla migrazione non era supportato dal runtime Liberty di destinazione.

Secondo IBM, anche l’efficienza variava a seconda della configurazione. Nei 200 task rimasti dopo l’esclusione basata sull’analisi di sensibilità, il numero mediano di turni variava da 32 con Claude Opus 5 e Claude Code a 79 con Gemini 3.8 Flash e mini-swe; con Claude Opus 5.5 e Claude Code era pari a 64. Nei casi in cui gli ambienti di esecuzione riportavano i costi — ossia nelle configurazioni con Claude Code, Codex, mini-swe e kimi-code — il costo per task risolto variava da $1,25 con GPT-6.1 Sol e Codex a $10,10 con Claude Opus 5.5 e Claude Code; gli ambienti Antigravity, qwen-code e OpenHands non fornivano dati sui costi per singola esecuzione.

La classifica di ScarfBench offre una panoramica pubblica di questi risultati. Al lancio non sarà possibile inviare modelli pubblicamente, ma IBM ha dichiarato che questa possibilità è prevista nella roadmap.