ИИ-агенты для генерации кода решили лишь 41% задач в новом тесте

Когда старые бенчмарки уже слишком лёгкие

С бенчмарками для агентов для программирования происходит знакомая история. Сначала они двигают область вперёд. Потом модели быстро подтягиваются, результаты растут, и метрика перестаёт честно показывать разницу между системами. В задачах уровня SWE-bench это уже видно: передовые модели проходят их всё чаще, а часть нерешённых примеров, как выяснилось, вообще испорчена плохими тестами.

На этом фоне авторы SWE-Bench ProMax предлагают другой способ мерить прогресс. Вместо привычных исправлений ошибок — большие рефакторинги в настоящих репозиториях. То есть такие изменения, где надо не придумать один патч в одном файле, а аккуратно протянуть новую логику через проект, ничего не сломав по дороге.

И тут картина резко меняется. Лучший результат на новом бенчмарке — всего 41,2%. Для нынешних агентов это уже не комфортная зона.

🟠 SWE-Bench ProMax проверяет длинные рефакторинги, а не локальные исправления

🟠 лучший результат — 41,2%

🟠 на старых бенчмарках передовые системы уже уходили далеко выше

Что такое SWE-Bench ProMax

SWE-Bench ProMax — это бенчмарк на 170 задач рефакторинга из реальных коммитов GitHub. Он охватывает 7 языков: Python, Java, TypeScript, Go, C, C++ и Rust. Внутри — не игрушечные примеры, а изменения из живых проектов, где нужно координировать правки сразу в нескольких местах.

Средний масштаб задачи здесь заметно выше привычного:

🟠 в среднем нужно изменить 11,4 исходного файла

🟠 средний размер правки — 261,6 строки кода

🟠 вместе с тестами суммарно получается 15,9 файла на задачу

🟠 почти треть задач требует правок больше чем в 10 файлах

🟠 почти треть задач меняет больше 200 строк

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

Пайплайн отбора и ручной доработки задач: от десятков тысяч коммитов до 170 проверенных примеров.

Почему старым результатам уже не очень верится

Авторы начинают с неприятного факта. В старых бенчмарках проблема не только в том, что они становятся слишком лёгкими. Проблема ещё и в качестве проверки.

В предыдущих наборах задач часто встречались два перекоса:

🟣 слишком узкие тесты, которые отвергают корректное решение, если оно устроено не так, как ожидал автор

🟣 слишком широкие тесты, которые требуют поведение, вообще не описанное в условии

Если вы сравниваете агентов по таким задачам, то метрика начинает шуметь. Модель может провалиться не потому, что не умеет программировать, а потому что тесты проверяют лишнее. Или наоборот: пройти задачу случайно, угадав форму решения.

Есть и ещё одна проблема: загрязнение данными. Если золотой патч уже встречался в обучающих данных, высокие баллы перестают означать реальную инженерную способность. Модель может просто воспроизвести знакомый кусок.

SWE-Bench ProMax строили как ответ сразу на оба вопроса: и на насыщение старых бенчмарков, и на сомнения в качестве оценки.

🟠 проблема старых наборов — не только простота, но и шумная проверка

🟠 узкие тесты могут отбрасывать верные решения

🟠 широкие тесты могут требовать лишнее

🟠 утечка данных искажает результаты

Как собирали задачи

Самое интересное здесь — не только сами задачи, но и дата-пайплайн.

Авторы стартовали почти с 29 782 кандидатов и в итоге оставили только 170. Отсев огромный. Это говорит о том, насколько трудно собрать бенчмарк, где и задача сложная, и окружение воспроизводимо, и тесты не врут.

Пайплайн состоял из трёх этапов.

🟠 Сначала через GitHub API искали подходящие репозитории: минимум 500 звёзд, открытая лицензия, один из семи целевых языков как основной язык проекта.

🟠 Потом вытаскивали коммиты после января 2025 года, где в сообщении есть слово refactor, но нет bug fix, и где менялись и тестовые, и обычные файлы.

🟠 Дальше строили изолированное окружение в Docker, откатывали репозиторий к состоянию до рефакторинга, накладывали золотой патч и проверяли, что всё вообще запускается и проходит тесты.

На этом автоматическая часть не заканчивалась. Дальше включалась ручная работа экспертов.

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

Описание должно быть достаточно точным, чтобы корректное решение было однозначно понятно, а тесты должны проверять именно это.

Почему рефакторинг — хороший стресс-тест

Исправление ошибки часто можно закрыть локально. Нашли источник ошибки, поправили условие, прогнали тесты. Рефакторинг устроен иначе. Он почти всегда требует держать в голове структуру проекта.

Если вы меняете интерфейс API, этого мало в одном модуле. Нужно пройтись по всем вызовам. Если вы переносите типы или выносите общий слой, надо не забыть про сборку, импорты, шаблоны, адаптеры, иногда даже генераторы кода. При этом внешнее поведение должно остаться тем же.

В статье есть пример из NASA F’Prime на C++: один рефакторинг затронул 244 файла. Это уже не задача «допиши функцию». Это задача «не потеряй проект по дороге».

Именно такие случаи лучше показывают, где агенты для программирования пока упираются в потолок.

Что получилось на запуске моделей

Авторы прогнали 6 моделей в двух агентных фреймворках: облегчённом mini-swe-agent и более насыщенном OpenHands. Во всех случаях лимит был одинаковый: до 300 шагов и до 10 долларов на задачу.

Главный результат очень прямой: никто не выглядит уверенно.

🟣 GPT-5.2 — 41,2%

🟣 Claude Sonnet 4.6 — 38,8%

🟣 GLM-5 — 36,5%

🟣 Qwen3.5 — 36,5%

🟣 Kimi-K2.5 — 32,9%

🟣 Gemini-3-Pro — 19,4% в OpenHands

Для контекста: на старом SWE-bench Verified передовые агенты уже переваливали за 75%. Здесь разница почти вдвое.

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

🟠 лучший результат — 41,2%

🟠 на SWE-bench Verified результаты уже были выше 75%

🟠 длинные рефакторинги остаются трудными почти для всех моделей

Открытые модели почти догнали закрытые

Ещё одна интересная часть — экономика.

GLM-5 показала 36,5% при средней цене 0,24 доллара на задачу. Для сравнения, Claude Sonnet 4.6 дошёл до 38,8%, но стоил в среднем 4,77 доллара. GPT-5.2 — 41,2% при 3,60 доллара.

Разница в качестве есть, но по цене она совсем не пропорциональна.

Коротко:

🟠 лучший результат не означает лучшую эффективность по деньгам

🟠 открытые модели уже близко подобрались к закрытым на сложных задачах

🟠 дорогой агент легко тратит шаги на бесполезные циклы, не приближаясь к решению

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

Фреймворк агента влияет почти так же сильно, как модель

Тут есть ещё один слой. Один и тот же модельный мозг в разных агентных фреймворках ведёт себя очень по-разному.

Почти все модели заметно прибавили при переходе с mini-swe-agent на OpenHands. Например, GPT-5.2 вырос с 21,8% до 41,2%. Это почти удвоение.

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

Иными словами, сравнивать «голые модели» в отрыве от агентной обвязки уже мало полезно. Для длинных задач агентный фреймворк — часть системы, а не внешний аксессуар.

🟠 GPT-5.2: 21,8% → 41,2% при смене фреймворка

🟠 качество зависит не только от модели, но и от инструментов агента

🟠 агентный фреймворк надо считать частью системы

Где именно агенты проваливают задачу

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

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

Это выглядит так:

🟣 основная логика изменена правильно

🟣 часть вызовов или периферийных модулей осталась старой

🟣 тесты продолжают падать из-за несогласованности проекта

🟣 агент тратит новые шаги на чтение, частичные правки и откаты, но не расширяет охват

Именно поэтому авторы называют главный режим отказа неполным рефакторингом.

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

Языки ведут себя не так, как можно было ожидать

Бенчмарк многоязычный, и это тоже важно. Обычно оценки агентов для программирования слишком сильно завязаны на Python. Здесь же можно увидеть, как модели ведут себя в разных экосистемах.

Картина получилась неровной:

🟠 GPT-5.2 лучше всех на Python и C

🟠 Claude Sonnet 4.6 лидирует на TypeScript и Rust

🟠 GLM-5 лучше остальных на Java

🟠 Qwen3.5 показывает лучший результат на C++

🟠 Kimi-K2.5 сильнее выглядит на Go

Любопытно, что TypeScript и Rust не оказались одинаково трудными для всех. Для одних моделей они идут хорошо, для других — провально. Значит, дело не только во внутренней сложности языка, но и в том, на каких данных и кодовых паттернах модель училась.

Матрица совместной встречаемости типов задач: рефакторинг часто идёт вместе с изменением API и исправлением ошибок.

Рефакторинг почти никогда не бывает чистым

Ещё один момент: задачи в SWE-Bench ProMax редко сводятся только к рефакторингу в узком смысле.

По разметке авторов, многие примеры одновременно включают:

🟣 изменение интерфейса API

🟣 уборку структуры кода

🟣 исправление ошибок

🟣 добавление новой возможности

🟣 обновление тестов или документации

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

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

Почему это важно для всей области

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

SWE-Bench ProMax показывает три вещи сразу.

🟠 нынешние агенты заметно лучше в локальных правках, чем в длинной координации по коду

🟠 качество бенчмарка зависит не только от размера, но и от ручной проверки описаний и тестов

🟠 открытые модели уже способны конкурировать с закрытыми там, где раньше разрыв казался больше

И, пожалуй, самое практическое: узкое место сейчас — не абстрактное «рассуждение вообще», а способность удерживать план изменений на множестве файлов и доводить его до конца без распада на частичные патчи.

Вывод

SWE-Bench ProMax сдвигает проверку агентов для программирования ближе к реальной инженерной работе. Вместо удобных задач на один-два файла здесь многосвязные рефакторинги, где нужно менять интерфейсы, синхронизировать зависимости и сохранять поведение проекта.

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

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