Почему ИИ-агенты хорошо чинят баги, но плохо доводят продукт до релиза

За последний год агенты для программирования заметно прибавили: они умеют находить место поломки, править код и прогонять тесты. Но есть важная оговорка: большинство популярных бенчмарков проверяют точечные достижения — исправление конкретного бага или добавление небольшой фичи в рамках одного issue. В реальной разработке всё иначе. Код живёт годами, требования меняются, появляются новые версии зависимостей, а правки приходится размазывать по десяткам файлов так, чтобы ничего не сломать по пути.

Авторы работы SWE‑EVO предлагают посмотреть правде в глаза и измерять то, что ближе к повседневной инженерии: способность агента эволюционировать кодовую базу между релизами, опираясь не на аккуратно сформулированный issue, а на release notes — короткие пункты о том, что изменилось и что должно работать в следующей версии.

Почему старых проверок уже недостаточно

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

SWE‑Bench и похожие бенчмарки приблизили оценку к реальности, потому что основаны на настоящих GitHub issues и проверяют патч тестами. Однако это по-прежнему в основном одиночные, относительно изолированные задачи. SWE‑EVO специально сделан так, чтобы агенту приходилось проходить длинную дистанцию от текста релизных изменений к последовательным правкам по всему репозиторию.

Как устроен SWE‑EVO

SWE‑EVO собран на базе семи зрелых open-source Python‑проектов. Всего в бенчмарке 48 задач, и каждая — это переход от одной версии к следующей. Формулировка для агента берётся из release notes (по сути, это мини‑SRS на уровне продукта), а проверка делается запуском тестов в зафиксированном окружении.

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

Авторы отдельно подчёркивают совместимость с существующими фреймворками агентов: бенчмарк сделан «plug-and-play» для инфраструктуры SWE‑Bench, чтобы его было проще взять и прогнать на типичных настройках.

Чем меряют успех

Как и в SWE‑Bench, основная метрика — доля полностью решённых задач: все тесты, которые должны были перестать падать, проходят, и при этом ничего из того, что раньше работало, не ломается. Но в long-horizon сценариях эта бинарность становится слишком грубой. Если у вас сотни проваленных тестов, агент может починить половину из них и всё равно получить «ноль» из‑за оставшихся проблем.

Поэтому SWE‑EVO вводит Fix Rate: долю проваленных тестов, которые агент сумел починить. Получается более честный индикатор частичного прогресса — полезный и для анализа, и для сравнения подходов, когда абсолютные проценты пока низкие.

Экспериментальная проверка

Авторы прогнали 11 современных LLM в двух агентных оболочках — OpenHands и SWE‑agent — и проверили два режима постановки: только release note или release note плюс контекст из связанных PR/issue (если на них есть ссылки).

Картина получилась довольно жёсткой. Лучший результат показывает GPT‑5 в связке с агентом: около 21% решённых задач на SWE‑EVO. Для сравнения, на SWE‑Bench Verified те же системы дают порядка 65%. Добавление контекста из PR/issue помогает, но умеренно: сам по себе «дополнительный текст» не превращает задачу в лёгкую, потому что главная сложность — удержать смысл изменений и разнести их по коду.

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

Как это меняет ИИ-агентов для программирования

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

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

💾 Код