IBM i Kaggle łączą siły, tworząc stale aktualizowaną tabelę wyników migracji ScarfBench

IBM i Kaggle współpracują nad stale aktualizowaną, publiczną tabelą wyników ScarfBench — otwartego benchmarku IBM służącego do oceny agentów programistycznych pod kątem migracji aplikacji korporacyjnych między platformami Java — jak wynika z noty technicznej IBM Research opublikowanej 27 października 2026 r.

ScarfBench, skrót od Self-Contained Application Refactoring Benchmark, sprawdza, czy agent potrafi wziąć nieznaną mu korporacyjną aplikację Java, przenieść ją między frameworkami Jakarta EE, Quarkus i Spring, a następnie pozostawić działające oprogramowanie. Benchmark weryfikuje, czy wygenerowane aplikacje się budują, uruchamiają i nadal działają zgodnie z oczekiwaniami, wykorzystując zarówno ukierunkowane obciążenia testowe, jak i całe aplikacje. IBM wprowadził ScarfBench wcześniej w 2026 r. jako powtarzalny benchmark migracji wspomaganych przez sztuczną inteligencję; w pierwotnym ogłoszeniu z 11 marca 2026 r. opisano siedem elementów, w tym zweryfikowane przez programistów aplikacje korporacyjne działające we wszystkich trzech frameworkach, ukierunkowane obciążenia testowe wyodrębniające takie zagadnienia jak obsługa trwałości danych i wstrzykiwanie zależności, całe aplikacje łączące wiele warstw architektury, automatyczną weryfikację kompilacji i uruchamiania oraz testy zachowania sprawdzające działanie w czasie wykonywania i równoważność funkcjonalną. Jak podano w ogłoszeniu, każde obciążenie testowe zostało ręcznie zaimplementowane i zweryfikowane przez doświadczonych programistów pod kątem równoważności funkcjonalnej oraz idiomatycznego wykorzystania frameworka.

Współpraca IBM i Kaggle

W ramach partnerstwa Kaggle konsultowało z IBM projekt benchmarku i sposób jego ewaluacji, niezależnie odtworzyło ScarfBench i uruchomiło go na własnej platformie, zapewniając moc obliczeniową, a także będzie długoterminowo utrzymywać benchmark. IBM określił mocne strony obu zespołów jako uzupełniające się: IBM opracował ScarfBench z myślą o modernizacji korporacyjnych aplikacji Java, a Kaggle wnosi niezależną infrastrukturę ewaluacyjną i będzie na bieżąco utrzymywać tabelę wyników.

Wyniki dla 204 zadań migracyjnych

ScarfBench ocenia system agentowy, a nie sam model językowy: każdy wynik odzwierciedla działanie modelu połączonego z platformą agenta programistycznego, która określa sposób interakcji modelu z repozytorium i środowiskiem programistycznym. IBM zastrzegł, że wyniki należy interpretować jako rezultaty uzyskane przez modele w połączeniu z platformami agentów, a nie jako pomiary samych modeli bazowych.

Jak podał IBM, spośród 204 zadań migracyjnych i dziesięciu ocenianych konfiguracji modelu i platformy agenta pierwsze miejsce w głównym wskaźniku testu dymnego zajęła konfiguracja Gemini 4 Argon z platformą Antigravity, uzyskując 75,2%. Kolejne miejsca zajęły Claude Opus 5.5 z Claude Code (70,5%) oraz Claude Opus 5 z Claude Code (69,8%). Wynik testu dymnego, który służy jako wskaźnik w tabeli, uwzględnia częściowe zaliczenie i przyznaje większą wagę większym zestawom testów. W bardziej rygorystycznym pomiarze odsetka zadań, w których zaliczono wszystkie testy, najwyższy wynik — 72,1% — uzyskał Claude Opus 5.5 z Claude Code, nieznacznie wyprzedzając Gemini 4 Argon z Antigravity, który osiągnął 71,1%.

Jak wynika z wpisu, kolejność czołowych konfiguracji nie zmieniła się w analizie wrażliwości. Cztery spośród 204 zadań nie przyniosły żadnej konfiguracji punktów za testy zachowania; po ich wykluczeniu wyniki bezwzględne wzrosły, ale liderzy pozostali ci sami: Gemini 4 Argon z Antigravity uzyskał 79,4%, a za nim uplasowały się Claude Opus 5.5 z Claude Code (74,5%) oraz Claude Opus 5 z Claude Code (73,7%). Jak zauważył IBM, nawet najsilniejszej konfiguracji wciąż pozostawał znaczny margines do poprawy — żadna nie zaliczyła w pełni więcej niż około trzech czwartych migracji.

W czym konfiguracje sobie radzą, a w czym zawodzą

Jak podał IBM, największa rozbieżność w ewaluacji wystąpiła między kodem, który się kompiluje, a oprogramowaniem, które działa poprawnie. Po wykluczeniu czterech zadań, za które wszystkie konfiguracje otrzymały zero punktów, Claude Opus 5 z Claude Code, Gemini 4 Argon z Antigravity oraz Gemini 3.8 Flash z mini-swe skompilowały 100% zadań, a osiem z dziesięciu konfiguracji skompilowało co najmniej 97%. Wyniki testów dymnych różniły się natomiast o ponad 50 punktów procentowych. Wśród aplikacji, które pomyślnie wdrożono, czołowe konfiguracje uzyskiwały pełne zaliczenie testów w około 63–76% przypadków, podczas gdy Kimi K3 z kimi-code osiągnął 53%, Gemini 3.1 Pro z OpenHands — 42%, a Gemma 4 26B-A4B z mini-swe — 26%.

IBM sklasyfikował 745 nieudanych uruchomień: 535, czyli około 72%, zakończyło się błędami działania w czasie wykonywania. W tych przypadkach aplikacja się budowała i często uruchamiała, ale nie przechodziła walidacji zachowania. Do tej grupy zaliczono 304 niezgodności treści lub asercji, 210 przypadków utraty trasy lub błędów 404 oraz 21 jawnych błędów HTTP 500 lub 405. Niepowodzenia kompilacji lub pakowania stanowiły około 20% nieudanych uruchomień — 152 przypadki — a awarie podczas uruchamiania lub wstrzykiwania zależności około 8% — 58 przypadków.

We wpisie opisano przykłady dotyczące poszczególnych zadań. W zadaniu concurrency-taskcreator-quarkus-to-jakarta Claude Opus 5 z Claude Code uzyskał 0/6 punktów, ponieważ punkt końcowy /taskinfo zwrócił komunikat „File not found”, a test oczekujący odpowiedzi HTTP 405 zakończył się niepowodzeniem. W zadaniu address-book-jakarta-to-quarkus GPT-6 Astra z Codex uzyskał 2/10 punktów, ponieważ strony listy i tworzenia zwracały błąd HTTP 404. W zadaniu cargotracker-jakarta-to-spring Gemini 3.8 Flash z mini-swe zachował powiązania JSF/JoinFaces w aplikacji docelowej Spring Boot i zakończył działanie niepowodzeniem podczas uruchamiania, przy tworzeniu komponentu facesContext. W zadaniu cart-spring-to-jakarta GPT-6 Astra z Codex nie zdołał wdrożyć aplikacji, ponieważ pozostawiony po migracji typ pakowania nie był obsługiwany przez docelowe środowisko uruchomieniowe Liberty.

Jak poinformowała IBM, wydajność różniła się również w zależności od konfiguracji. Wśród 200 zadań pozostałych po wykluczeniu w ramach analizy wrażliwości mediana liczby tur wynosiła od 32 w przypadku Claude Opus 5 z Claude Code do 79 w przypadku Gemini 3.8 Flash z mini-swe; dla Claude Opus 5.5 z Claude Code wyniosła 64. W konfiguracjach, dla których środowiska testowe raportowały koszty — Claude Code, Codex, mini-swe i kimi-code — koszt rozwiązania jednego zadania wahał się od $1.25 w przypadku GPT-6.1 Sol z Codex do $10.10 w przypadku Claude Opus 5.5 z Claude Code. Środowiska Antigravity, qwen-code i OpenHands nie podawały kosztów dla poszczególnych uruchomień.

Tablica wyników ScarfBench przedstawia publicznie te rezultaty. W chwili uruchomienia nie można jeszcze zgłaszać publicznie modeli, ale IBM poinformowała, że taka możliwość jest uwzględniona w planach.