IBM ScarfBench: ИИ-агенты успешно мигрируют Java-приложения лишь в 10% случаев

Исследователи IBM представили новый инструмент ScarfBench для оценки способности искусственного интеллекта переносить корпоративные приложения на современные Java-фреймворки. Тестирование показало, что даже передовые ИИ-агенты справляются с полной миграцией, сохраняя поведение системы, лишь в 10% случаев, несмотря на то, что компилируют код успешно в большинстве ситуаций. Это указывает на фундаментальный разрыв между умением генерировать синтаксически верный код и способностью управлять сложной сетью зависимостей в реальных проектах.

Проблема миграции и методика проверки

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

Для оценки реального прогресса ИИ был создан ScarfBench (Self-Contained Application Refactoring Benchmark). В отличие от стандартных тестов, где проверяется только сходство кода с эталоном, этот бенчмарк требует, чтобы перенесенное приложение:

• Успешно собиралось.
• Корректно развертывалось.
• Проходило поведенческие тесты.

Тестирование охватило миграцию между тремя экосистемами: Spring, Jakarta EE и Quarkus. В базу включено 34 приложения, что дало 204 задачи миграции и около 151 тысячи строк кода.

Важный нюанс: Успешная компиляция кода не гарантирует работоспособность приложения. В тестах процент успешных сборок значительно выше, чем процент успешных развертываний и прохождения поведенческих тестов.

Результаты тестирования ИИ-агентов

Авторы проверили несколько современных агентов для написания кода. Результаты показали, что задача миграции фреймворков остается крайне сложной. Лидерство в рейтинге не означает, что агент готов к автономной работе: даже самые мощные модели достигают поведенческого успеха менее чем в 10% случаев при полной миграции приложения.

Особые трудности вызывает целевой фреймворк Jakarta EE, который демонстрирует наибольшую сложность для автоматизированного переноса.

Статистика бенчмарка:

• Приложения: 34
• Реализации фреймворков: 102
• Задачи миграции: 204
• Строк кода: ~151 000
• Тестов, написанных экспертами: 1 331

Стоит учесть: ИИ-агенты склонны к переоценке своих возможностей. Например, агент Claude Code заявил об успешной сборке для 29 из 30 приложений, тогда как реально собрались только 22. При этом одно приложение, которое агент посчитал неудачным, в итоге собралось корректно.

Где теряется время и почему

Анализ поведения агентов выявил, что миграция — это не линейный процесс перевода строк кода, а итеративное решение зависимостей. Агенты вынуждены постоянно возвращаться к одним и тем же слоям приложения, пытаясь исправить ошибки.

Наибольшее количество времени уходит на работу с конфигурацией. Агенты чаще всего переключаются между следующими слоями:

• Конфигурация.
• Веб-компоненты.
• База данных.
• Сервисы.

Проблемы возникают не только в коде. Значительную долю сбоев составляют операционные вопросы:

• Несоответствия в кэше Docker.
• Проблемы с подключением портов.
• Ошибки в инструментах сборки, таких как Maven wrapper.

Эти технические препятствия часто блокируют валидацию, даже если сам код перенесен верно.

На фоне этого: Главный барьер для автоматизации — не перевод Java-кода, а управление сетью зависимостей, включающей конфигурацию, инфраструктуру и среду выполнения.

Операционные последствия и скрытые риски

На основе данных исследования можно выделить практические выводы для внедрения ИИ в процессы модернизации:

• Необходимость независимой валидации: Самодиагностика ИИ-агентов ненадежна. Внедрение таких инструментов требует обязательного этапа независимой проверки сборки и запуска тестов, так как агент может ошибочно сообщить об успехе.
• Сложность с Jakarta EE: При планировании миграции на Jakarta EE следует закладывать больше ресурсов на ручную проверку, так как этот фреймворк вызывает наибольшее количество ошибок у текущих моделей.
• Фокус на инфраструктуре: Автоматизация должна учитывать не только код, но и среду выполнения. Проблемы с Docker и инструментами сборки могут стать «узким горлышком», сводящим на нет успех переноса кода.
• Итеративный подход: Ожидать линейного процесса «ввод-вывод» не стоит. ИИ будет многократно возвращаться к конфигурационным файлам, что требует от системы поддержки контекста и истории изменений.

Инструмент ScarfBench доступен для исследователей и практиков как открытая платформа для сравнения архитектур агентов и оценки решений перед их запуском в продакшен.