IBM и Kaggle зажигают лидерборд миграции Java-фреймворков

ScarfBench (Self-Contained Application Refactoring Benchmark) — это открытый бенчмарк от IBM для оценки того, могут ли агенты кодирования успешно переносить корпоративные приложения Java между фреймворками, сохраняя при этом рабочее поведение приложения. В рамках миграций на Jakarta EE, Quarkus и Spring он проверяет, собираются ли сгенерированные приложения, запускаются ли они и продолжают ли вести себя должным образом, используя как целевые рабочие нагрузки, так и приложения целиком.

Модернизация корпоративного приложения — это не задача написания кода для одного файла. Перенос приложения между фреймворками может потребовать скоординированных изменений в внедрении зависимостей (dependency injection), персистентности, доступе к базам данных, веб-эндпоинтах, системах сборки, дескрипторах фреймворков и инфраструктуре развертывания. ИИ-агент может создать миграцию, которая выглядит правдоподобно или даже компилируется, но при этом приложение все равно дает сбой при развертывании или проверке его ожидаемого поведения.

ScarfBench задает практический вопрос: может ли агент взять незнакомое приложение, перенести его через границы фреймворков и оставить после себя работоспособное программное обеспечение?

Компания IBM представила ScarfBench в начале 2026 года в качестве воспроизводимого бенчмарка для миграций на базе ИИ. Теперь IBM и Kaggle объединяют усилия, чтобы сделать эту оценку более простой для воспроизведения, сравнения и расширения с течением времени. Kaggle консультировала по вопросам дизайна оценки, независимо воспроизвела и запустила ScarfBench на своей платформе, выступив спонсором вычислений, а также будет поддерживать бенчмарк по мере выпуска новых моделей. Это сотрудничество превращает ScarfBench из опубликованного бенчмарка в непрерывно обновляемое представление о прогрессе в сфере агентской модернизации ПО.

В первоначальном анонсе ScarfBench подробно описаны структура бенчмарка, проверенные разработчиками рабочие нагрузки и подход к воспроизводимой оценке. Эта публикация посвящена тому, что последняя оценка говорит нам о комбинациях моделей и агентов, где они терпят неудачу и как бенчмарк развивается вместе с Kaggle.

Оценка комбинаций моделей и агентов

ScarfBench оценивает агентскую систему, а не языковую модель изолированно. Каждый результат отражает модель в паре с агентом кодирования, который определяет, как она взаимодействует с репозиторием и средой разработки. Следовательно, результаты следует воспринимать как результаты работы модели/агента, а не как показатели только базовой модели.

Среди 204 задач миграции Gemini 4 Argon с Antigravity занял первое место по основному показателю дымового тестирования (smoke-test) с результатом 75,2%, за ним следуют Claude Opus 5.5 с Claude Code (70,5%) и Claude Opus 5 с Claude Code (69,8%). Было оценены десять конфигураций моделей и агентов.

Три метрики раскрывают важный нюанс. Оценка smoke, являющаяся метрикой лидерборда, начисляет частичные баллы и уделяет больше внимания крупным наборам тестов. По этому показателю комбинация Gemini 4 Argon + Antigravity показала лучший результат. Однако у Claude Opus 5.5 + Claude Code был самый высокий процент прохождения всех тестов (all-tests-pass), составивший 72,1%, что немного опережает Gemini 4 Argon. Другими словами, комбинация Argon/Antigravity набрала больше всего частичных баллов по всему бенчмарку, в то время как комбинация Opus 5.5/Claude Code преобразовала чуть больше отдельных задач миграции в полностью успешные наборы тестов.

Рейтинг остается стабильным при анализе чувствительности. Четыре из 204 задач миграции получили нулевой балл по поведенческим тестам от каждой оцениваемой комбинации модели/агента. Исключение этих четырех задач повысило абсолютные оценки, но не изменило порядок лидеров: Gemini 4 Argon + Antigravity набрал 79,4%, за ним следуют Claude Opus 5.5 + Claude Code с 74,5% и Claude Opus 5 + Claude Code с 73,7%. Этот результат говорит о том, что относительный рейтинг не определяется этим небольшим набором одинаково сложных задач.

Даже самая сильная комбинация оставляет значительный запас для роста: лучший общий показатель smoke составил 75,2% по всему бенчмарку, и ни одна конфигурация не прошла полностью более чем примерно три четверти миграций.

Главный фактор различий — поведенческая точность, а не компиляция

Самый очевидный результат — это разрыв между кодом, который собирается, и программным обеспечением, которое ведет себя правильно. Исключив четыре задачи с нулевым результатом, Claude Opus 5 + Claude Code, Gemini 4 Argon + Antigravity и Gemini 3.8 Flash + mini-swe успешно скомпилировали по 100% задач, GPT-6 Astra + Codex и Kimi K3 + kimi-code — 99,0% и 98,5%, а Claude Opus 5.5 + Claude Code и GPT-6.1 Sol + Codex — 98,0% и 98,5%. Тем не менее, результаты дымовых тестов остались намного ниже.

По всем 10 конфигурациям успешность компиляции среди решаемых задач охватывала около 25 процентных пунктов, но большинство конфигураций группируются ближе к верху (8 из 10 компилируют 97% и более); производительность дымовых тестов охватывала более 50 пунктов. Среди успешно развернутых приложений ведущие конфигурации сгруппировались примерно на уровне от 63 до 76% для полностью прошедших тесты; Kimi K3 + kimi-code упали до 53%, Gemini 3.1 Pro + OpenHands — до 42%, а Gemma 4 26B-A4B + mini-swe — до 26%. В этой оценке сохранение поведения оказалось гораздо более надежным критерием различия, чем обеспечение компиляции мигрировавшего приложения.

Где терпят неудачу конфигурации агентов

Из 745 классифицированных неудачных запусков 535 (приблизительно 72%) были сбоями поведения во время выполнения: приложение собралось и часто загружалось, но не прошло поведенческую валидацию. Эта группа включала 304 несоответствия содержимого или утверждений (assertions) и 210 ошибок потерянных маршрутов/404; 21 ошибка была явными ошибками HTTP 500/405. Ошибки компиляции или упаковки составили примерно 20% (152 запуска), а сбои загрузки или внедрения зависимостей — примерно 8% (58 запусков).

• Потерянные маршруты и семантика HTTP: В задаче concurrency-taskcreator-quarkus-to-jakarta комбинация Claude Opus 5 + Claude Code получила 0/6 после того, как /taskinfo вернула «Файл не найден» (File not found), а тест, ожидающий HTTP 405, завершился ошибкой. В address-book-jakarta-to-quarkus комбинация GPT-6 Astra + Codex получила 2/10 после того, как страницы списка и создания вернули HTTP 404.

Потерянные маршруты и семантика HTTP: В задаче concurrency-taskcreator-quarkus-to-jakarta комбинация Claude Opus 5 + Claude Code получила 0/6 после того, как /taskinfo вернула «Файл не найден» (File not found), а тест, ожидающий HTTP 405, завершился ошибкой. В address-book-jakarta-to-quarkus комбинация GPT-6 Astra + Codex получила 2/10 после того, как страницы списка и создания вернули HTTP 404.

• Сохранение привязок исходного фреймворка в целевом: В задаче cargotracker-jakarta-to-spring комбинация Gemini 3.8 Flash + mini-swe сохранила привязки JSF/JoinFaces в целевом объекте Spring Boot, что затем привело к сбою во время запуска при создании бина facesContext.

Сохранение привязок исходного фреймворка в целевом: В задаче cargotracker-jakarta-to-spring комбинация Gemini 3.8 Flash + mini-swe сохранила привязки JSF/JoinFaces в целевом объекте Spring Boot, что затем привело к сбою во время запуска при создании бина facesContext.

• Упаковка, несовместимая с целевой средой выполнения: В задаче cart-spring-to-jakarta комбинация GPT-6 Astra + Codex столкнулась с ошибкой развертывания, поскольку тип упаковки, оставленный после миграции, не поддерживался целевой средой выполнения Liberty.

Упаковка, несовместимая с целевой средой выполнения: В задаче cart-spring-to-jakarta комбинация GPT-6 Astra + Codex столкнулась с ошибкой развертывания, поскольку тип упаковки, оставленный после миграции, не поддерживался целевой средой выполнения Liberty.

Эти сбои иллюстрируют, почему ScarfBench проверяет нечто большее, чем просто компиляцию: почти три из четырех классифицированных сбоев в этой оценке произошли во время выполнения.

Эффективность агентов демонстрирует различные профили работы

Из 200 задач, оставшихся после исключения четырех задач по чувствительности, конфигурация Claude Opus 5 + Claude Code использовала наименьшее медианное число шагов — 32. GPT-6.1 Sol + Codex использовала 36, Gemma 4 26B-A4B + mini-swe 40, Gemini 4 Argon + Antigravity 42, GPT-6 Astra + Codex 45, Kimi K3 + kimi-code 47, Qwen 3.8 Max + qwen-code и Gemini 3.1 Pro + OpenHands 53, Claude Opus 5.5 + Claude Code 64, а Gemini 3.8 Flash + mini-swe 79.

Там, где были доступны данные о стоимости, предоставленные обвязкой (для обвязок Claude Code, Codex, mini-swe и kimi-code; обвязки Antigravity, qwen-code и OpenHands не выводили стоимость за один запуск), конфигурации показали различные стоимостные профили:

IBM и Kaggle создают постоянно обновляемую таблицу лидеров ScarfBench

Последняя оценка ScarfBench также знаменует собой начало более глубокого сотрудничества между IBM и Kaggle. Две команды привносят взаимодополняющие сильные стороны: IBM разработала ScarfBench с акцентом на модернизацию корпоративного ПО на Java, в то время как Kaggle предоставляет независимую инфраструктуру оценки и долгосрочную поддержку таблицы лидеров. Сотрудничество призвано сделать бенчмарк воспроизводимым за пределами его первоначальной среды разработки и полезным по мере выхода новых конфигураций моделей и агентов.

Сотрудничество состоит из трех конкретных частей. Во-первых, Kaggle проконсультировала IBM по вопросам строгого проектирования бенчмарка и оценки. Во-вторых, Kaggle независимо воспроизвела и запустила оценку на своей платформе, а также спонсировала вычислительные ресурсы. В-третьих, Kaggle будет осуществлять долгосрочную поддержку бенчмарка и добавлять новые модели по мере их выхода. Таблица лидеров ScarfBench обеспечивает публичный просмотр этих результатов. Общедоступная отправка моделей недоступна на момент запуска, но входит в планы развития.

Что мы узнали к настоящему моменту

ScarfBench был создан на основе требовательной предпосылки: кодинг-агенты, участвующие в значимой модернизации корпоративного ПО, должны оцениваться по результату, который в конечном итоге волнует предприятия — по работающему программному обеспечению.

Последняя оценка подтверждает эту предпосылку. Ведущие конфигурации могут скомпилировать практически каждую задачу из набора чувствительности, но компиляция скрывает более сложную проблему. Маршруты исчезают, поведение HTTP меняется, связи исходного фреймворка переживают миграции, приложения дают сбой во время запуска, а бизнес-логика отклоняется от ожидаемой работы системы.

Этот разрыв между кодом, который собирается, и программным обеспечением, которое работает, является тем аспектом, где ScarfBench наиболее информативен. По мере появления новых комбинаций моделей и обвязок поддерживаемый бенчмарк может показать, достигается ли прогресс за счет более качественных сгенерированных изменений, более эффективной отладки и итераций, более эффективного использования инструментов или сочетания этих возможностей.