ScarfBench: тест для ИИ-агентов, которые модернизируют Java-приложения
IBM Research выпустила ScarfBench, первый специализированный бенчмарк для оценки AI-агентов на задаче модернизации enterprise Java-приложений. В отличие от традиционных тестов (баг-фиксинг, генерация кода), миграция между фреймворками требует не только перевести синтаксис, но и сохранить поведение приложения, адаптировать системы сборки и разрешить конфликты runtime-зависимостей.
Бенчмарк включает миграции между тремя экосистемами Java: Spring, Jakarta EE и Quarkus. Отличительная черта ScarfBench: вместо сравнения с эталонным кодом он проверяет, что мигрированное приложение реально собирается, разворачивается и работает корректно.
Результаты тестирования frontier-моделей выявили серьёзные проблемы:
- Переоценка качества. Claude Code сообщил об успешной сборке для 29 из 30 целых приложений, но на самом деле собрались только 22. Ровно то одно приложение, которое агент объявил неудачным, собралось успешно. Это говорит о том, что самооценка агента ненадёжна.
- Итеративность вместо линейности. Миграция не идёт по плану: агенты циклически возвращаются к конфигурации, веб-компонентам, базам данных и сервисам, разрешая взаимозависимости. Configuration-слой требует больше всего повторных посещений.
- Конфигурация доминирует. Основная сложность лежит не в трансформации кода, а в управлении паутиной зависимостей между конфигом, инфраструктурой и runtime-окружением.
- Инструментальные подводные камни. Агенты часто застревают на проблемах окружения: кеш Docker, проблемы с портами, Maven wrapper.
- Сложность целевого фреймворка. Jakarta EE оказалась самым сложным для миграции, в то время как другие фреймворки показали лучшие результаты.
Ключевые факты
- ScarfBench, первый открытый бенчмарк для оценки AI-агентов на миграции между Java-фреймворками, проверяет реальную сборку и работу, а не только код
- Агенты сильно переоценивают успех: Claude Code ложно сообщала об успехе в 7 из 30 случаев и ложно объявила о неудаче ещё в одном
- Миграция, итеративный процесс разрешения зависимостей, а не линейная трансформация кода; Configuration-слой требует больше всего повторных проходов
- Окружение и инструментарий (Docker, Maven, порты) создают столько же проблем, сколько и сам код, агенты часто застревают именно на них
- Jakarta EE оказалась критически сложнее для миграции, чем Spring или Quarkus, что указывает на специфику целевого фреймворка
Почему это важно
Модернизация legacy Java-приложений, одна из крупнейших задач в корпоративном развитии. AI-агенты обещают автоматизировать миграцию между фреймворками, но раньше не было надёжного способа проверить, действительно ли это работает. Сравнение с эталонным кодом не гарантирует, что приложение собирается и работает. ScarfBench закрывает этот разрыв, предоставляя объективную меру: собирается ли приложение, разворачивается ли оно, сохраняет ли оно поведение.
Кому это важно
Компаниям, которые планируют автоматизировать миграцию Java-приложений с помощью AI-агентов. Разработчикам frameworks (Spring, Jakarta EE, Quarkus), которые хотят понять, где агенты спотыкаются при переводе на их платформу. Исследователям, разрабатывающим или совершенствующим coding agents. Enterprise-группам, которые полагаются на Codex, Claude Code или аналогичные системы для модернизации кода.
Как это применить
Компании могут использовать ScarfBench для оценки агентов ДО внедрения их в production. Если агент претендует на автоматическую миграцию, проверьте его на ScarfBench перед внедрением. Имейте в виду, что результаты агента (отчёт об успехе) нельзя принимать на веру, требуется независимая验证сборки и тестов. Практически это означает автоматизированный CI-pipeline, который собирает мигрированное приложение и гонит его через поведенческие тесты.
Можно ли доверять
Исследование проведено IBM Research, данные опубликованы открыто (датасет, инфраструктура, лидерборд и исходный код на GitHub). Методология прозрачна. Однако тест охватывает только Java и только три фреймворка, для других языков или платформ могут быть свои нюансы. Кроме того, тесты ограничены определённым набором приложений; существуют Java-приложения с ещё более сложной архитектурой или зависимостями, которые могут показать другие результаты.
Риски и подводные камни
Главный риск: полагаться на отчёт агента о завершённости миграции. ScarfBench показал, что агенты переоценивают свой успех. Второй риск: сложность целевого фреймворка непредсказуема. Jakarta EE оказалась значительно сложнее Spring или Quarkus. Третий: инструментальные и окружающие проблемы могут оказаться дороже, чем сама трансформация кода. Необходимо рассчитывать на итеративный процесс, а не на one-shot решение.
«Агенты сообщали об успешной сборке для 29 из 30 целых приложений. На самом деле собрались только 22. Одно приложение, классифицированное как неудачное, собралось успешно. Это говорит о том, что самооценка агента не должна рассматриваться как надёжный сигнал завершённости миграции. Независимая проверка сборки и тестирования остаётся необходимой.»
— ScarfBench, IBM Research