Лидер привычного coding-бенчмарка может оказаться плохим выбором для реального репозитория. SWE-Bench ProMax показывает разрыв: когда агенту нужно не закрыть локальный тикет, а согласованно изменить много файлов без регрессий, лучший результат падает до 41,2%.
Для бизнеса с ИИ вывод практический. Сравнивать агентов только на коротких задачах уже недостаточно. Перед следующей покупкой модели или продлением подписки стоит дать кандидатам одну настоящую миграцию из своего бэклога и посмотреть, кто вернёт поддерживаемый код, а кто просто произведёт убедительный многофайловый diff.
Что проверяет новый бенчмарк
Как пишет The New Stack, SWE-Bench ProMax разработали исследователи Shanghai Jiao Tong University, Peking University, Douyin Group и других организаций. В набор вошли 170 задач из реальных коммитов на Python, Java, TypeScript, Go, C, C++ и Rust.
Создатели специально отбирали задачи с достаточной сложностью и изменениями в нескольких файлах. Описания проблем уточняли, тесты проверяли вручную, слишком узкие и слишком широкие проверки удаляли. Это важно на фоне аудита, который цитируют исследователи: почти 60% нерешённых задач SWE-bench Verified содержали дефектные тесты.
Результат оказался неудобным для красивых таблиц. Даже лучший агент решил только 41,2% задач. Именно поэтому бенчмарк полезен: он пока не превратился в экзамен, ответы на который модели могли встретить в обучающих данных, и проверяет класс работы, который обычно исключают ради скорости и воспроизводимости теста.
Большой рефакторинг требует одновременно удерживать зависимости между файлами, сохранять поведение системы и не пропускать побочные эффекты. Войтех Павлик из SUSE говорит The New Stack, что современные LLM пока не способны прочитать крупную кодовую базу и понять её целиком. Когда репозиторий упирается в предел контекстного окна, модель может терять важные наблюдения и путаться.
Шейн Уорден из ActiveState формулирует проблему ещё жёстче: близость токенов не означает понимания структуры. Можно загрузить код в большое контекстное окно и получить серию правдоподобных правок, но правдоподобие здесь не равно корректности. У рефакторинга нулевая терпимость к изменению поведения, а значит, почти правильный результат остаётся неправильным.
Почему короткий тикет больше не годится как закупочный тест
Популярные бенчмарки оптимизированы под задачи, которые можно быстро запустить и однозначно проверить. Это удобно для рейтинга, но создаёт ложную уверенность у покупателя. Агент может отлично чинить локальную функцию и одновременно терять связь между интерфейсом, реализацией и тестами в разных частях репозитория.
На практике именно эта связь определяет ценность инструмента для команды. Coding-агент покупают не ради победы в таблице, а ради сокращения инженерной работы. Если после большой правки разработчик вручную ищет забытые зависимости, исправляет регрессии и заново собирает архитектурный замысел, автоматизация лишь перенесла труд из написания кода в ревью чужого черновика.
SWE-Bench ProMax при этом не стоит принимать за полную репетицию production-миграции. Павлик отдельно указывает на ошибки, возникающие там, где код сталкивается со временем: race conditions, потерю идемпотентности и атомарности, неверную обработку повторных попыток. Код может пройти тесты и сломаться при тайм-ауте, повторном клике или почти одновременном завершении двух задач. Один публичный рейтинг всего этого за вашу систему не проверит.
Поэтому новый бенчмарк полезен не как очередная таблица чемпионов, а как шаблон собственного eval. Возьмите завершённый рефакторинг из истории репозитория, уберите готовый diff, дайте агентам одинаковое описание и прогоните существующие тесты. Затем посчитайте ручные исправления, пропущенные файлы и регрессии. Победителем должен стать не тот, кто написал больше кода, а тот, чей результат команда готова принять.
Маркер на следующий выбор инструмента простой: сравните рейтинг кандидатов на коротких задачах с результатом одной большой внутренней миграции. Если лидеры поменяются местами, SWE-Bench ProMax попал в реальную проблему, а прежний закупочный тест измерял удобство демо, не надёжность агента.