ScarfBench: почему AI-агенты проваливают миграцию корпоративных Java-приложений
IBM Research представила ScarfBench — первый бенчмарк для оценки AI-агентов на задачах миграции enterprise Java-приложений между фреймворками (Spring, Jakarta EE, Quarkus). Результаты показали: современные агенты справляются с генерацией кода, но проваливаются на сборке, деплое и сохранении поведения приложений. Главная проблема — не перевод кода, а управление зависимостями, конфигурациями и окружением.
Enterprise-миграции — это миллиарды долларов и критические риски для бизнеса. Бенчмарк показывает реальные пределы AI-агентов на задачах, которые нельзя решить простой генерацией кода — и объясняет, почему автономная модернизация приложений всё ещё далека.
Новый бенчмарк для реальной задачи
Миграция корпоративных приложений между фреймворками — одна из самых дорогих и рискованных операций в enterprise-разработке. IBM Research выпустила ScarfBench — открытый бенчмарк, который проверяет AI-агентов не на генерации кода, а на реальной миграции Java-приложений между Spring, Jakarta EE и Quarkus.
В отличие от традиционных бенчмарков (которые сравнивают код с эталоном), ScarfBench проверяет: собирается ли приложение, деплоится ли, сохраняется ли его поведение.
Что показало тестирование
Результаты топовых агентов (включая Claude Code) оказались скромными:
- Агенты переоценивают свой успех: Claude Code сообщил об успешной сборке 29 из 30 приложений, хотя реально собралось меньше. Единственное приложение, которое агент признал провальным, в итоге собралось корректно.
- Компиляция ≠ деплой ≠ работающее приложение: показатели успеха падают на каждом этапе. Успешная сборка сильно переоценивает качество миграции.
- Миграция — итеративный процесс: агенты постоянно возвращаются к конфигурации, зависимостям и базам данных, а не идут линейно от файла к файлу.
Где агенты спотыкаются
Анализ показал:
- Конфигурация съедает основное время: агенты многократно возвращаются к настройкам, пытаясь разрешить зависимости между слоями приложения.
- Окружение и инструменты: проблемы с Maven/Gradle, версиями Java, путями к ресурсам тормозят валидацию даже при правильно мигрированном коде.
- Jakarta EE — самый сложный таргет: миграция на этот фреймворк проваливается чаще всего.
Главный вывод
Проблема не в переводе Java-кода. Проблема — в управлении паутиной зависимостей между конфигурацией, инфраструктурой и runtime-окружением. Современные агенты могут автоматизировать часть процесса, но надёжная валидация и архитектурное мышление остаются критичными.
ScarfBench открыт для исследователей и практиков: можно сравнивать архитектуры агентов или тестировать решения перед продакшеном.
Ключевые выводы
- Успешная компиляция мигрированного кода не гарантирует деплоя и сохранения поведения — показатели падают на каждом этапе
- AI-агенты переоценивают свой успех: Claude Code заявил о 29/30 успешных сборках, хотя реальность оказалась хуже
- Миграция фреймворков — не линейный процесс перевода кода, а итеративное разрешение зависимостей между конфигурацией, БД и инфраструктурой
- Конфигурация и окружение (Maven, пути, версии) съедают больше усилий агента, чем сам код
- Jakarta EE — самая сложная цель для миграции среди протестированных фреймворков
Автор: Артём Ковалёв · Источник: HuggingFace Blog
Это один из тех редких бенчмарков, которые проверяют AI не на игрушечных задачах, а на реальной боли enterprise-разработки. Миграция корпоративных приложений между фреймворками — это не переписать пару файлов, это распутать клубок зависимостей, конфигов, БД и деплоя. И вот тут современные агенты сыплются.
Особенно показательна переоценка собственного успеха: Claude Code заявил о 29 успешных миграциях из 30, хотя реально ситуация хуже. Это напоминает классическую проблему AI — модель не понимает, правильно ли она сработала. Бенчмарк полезен не только исследователям, но и тем, кто думает внедрять AI-агентов в продакшен: теперь есть способ честно проверить, на что они способны до того, как сломать production.
Комментарии