Исследователи представили SWE-Duel — экспериментальную арену для оценки ИИ-агентов, которые работают с программным кодом. В отличие от традиционных наборов задач, опубликованных заранее, система создаёт задания во время самого тестирования. Один агент добавляет в репозиторий новую функцию и намеренно скрывает в ней дефект, а другой должен обнаружить проблему и исправить её, не зная, что в коде вообще есть ошибка.
Работа опубликована на arXiv под номером 2610.12569. Авторы рассматривают SWE-Duel как способ сделать оценку coding-агентов масштабируемой: сложность заданий должна зависеть от возможностей участников, а не оставаться неизменной после выхода бенчмарка.
Почему статические бенчмарки теряют ценность
Фиксированный набор задач удобен для сравнения моделей, но со временем у него появляется несколько ограничений. Решения могут попасть в обучающие данные, а новые и более сильные агенты — постепенно решить значительную часть опубликованных примеров. В таком случае высокий результат показывает не только способность работать с новым кодом, но и знакомство с конкретным набором заданий.
SWE-Duel пытается устранить эту проблему за счёт генерации задач непосредственно в процессе оценки. В описанной схеме заранее не публикуются ни конкретные изменения в репозиториях, ни набор скрытых тестов, которые должны выявлять дефект. Это, по замыслу авторов, уменьшает вероятность прямой утечки содержимого в обучающие наборы.
Подход не отменяет проблему загрязнения данных полностью: модели всё равно могут знать используемые репозитории, языки программирования и типовые способы исправления ошибок. Однако конкретная комбинация функции, дефекта и проверок появляется только во время турнира.
Как устроен поединок агентов
Соревнование построено вокруг чередующихся ходов «красного» и «синего» участников. Красный агент выступает автором задания. Он работает с реальным репозиторием в трёх изолированных сессиях, чтобы разделить создание функции, внедрение ошибки и последующую проверку.
Сначала агент предлагает и реализует новую возможность, а также добавляет тесты для неё. Затем в код внедряется скрытый дефект и создаются отдельные тесты, предназначенные для его обнаружения. Такой pull request принимается в турнир только при выполнении нескольких условий:
- новая функция проходит собственные тесты;
- существующие тесты репозитория продолжают работать;
- скрытые тесты для дефекта завершаются ошибкой;
- свежая сессия того же агента способна исправить проблему вслепую.
Последняя проверка нужна для отсечения заведомо нерешаемых задач. Если автор задания сам не может восстановить корректное поведение без подсказки, такой пример не должен использоваться для оценки другого агента.
После этого синий агент получает pull request, но не получает информацию о наличии намеренно внедрённой ошибки. Он должен проанализировать изменение и подготовить исправление. Победа засчитывается только в том случае, если итоговая версия проходит все три группы проверок: тесты новой функции, исходные тесты репозитория и скрытые тесты дефекта. Затем роли участников меняются.
Таким образом, система проверяет не только способность написать код по описанию, но и умение провести ревью, заметить неочевидное нарушение поведения и безопасно изменить уже существующий проект.
Первые результаты турнира
В эксперименте участвовали 11 комбинаций моделей и инструментов, использованных как программные оболочки для работы с кодом. Испытания проводились на 15 репозиториях и пяти языках программирования. Всего авторы работы провели 1500 ходов.
Результаты разделили как минимум на два измерения. В роли решающего агента первое место занял GPT-5.5 с Codex CLI: он исправил 98,3% дефектов, которые ему передали на ревью. Этот показатель характеризует способность находить и устранять уже внедрённые проблемы, но не означает, что агент одинаково хорошо создаёт сложные задания.
В качестве автора задач лидировал Claude Opus 4.8 в связке с mini-swe-agent. Его доля побед за красную сторону составила 27,3%. Иными словами, именно задания, созданные этим участником, чаще всего оказывались достаточно сложными для соперника при сохранении формальных требований к тестам.
Авторы также сравнили версии одной модельной линейки. Задания, созданные более новой версией, побеждали фиксированный эталонный решатель в 42,9% случаев против 4,0% для заданий старой версии. В статье этот результат трактуется как предварительный признак того, что способность автора создавать задания может повышать сложность бенчмарка.
Эти числа нельзя напрямую превращать в общий рейтинг моделей. На результат влияют выбранные репозитории, языки, инструментальная оболочка, правила допуска pull request и конкретная реализация тестов. Кроме того, работа описывает один турнир, а не независимую проверку на значительно большем наборе окружений.
Что методика может изменить для оценки coding-агентов
Главное отличие SWE-Duel — разделение ролей автора и решателя. В обычном бенчмарке задача существует до эксперимента, а её сложность задаётся создателями набора. Здесь один агент создаёт новый пример непосредственно во время турнира, а другой пытается его решить. Теоретически это позволяет оценивать более сильные системы без постоянного ручного выпуска новых версий тестового набора.
Для разработчиков ИИ-агентов такой формат даёт несколько практических сигналов. Высокая доля исправлений показывает, насколько система справляется с поиском дефектов в чужих изменениях. Доля побед автора позволяет оценить, умеет ли агент формулировать нетривиальные, но проверяемые задачи. Разрыв между этими показателями может быть информативнее единого итогового балла: модель может хорошо исправлять ошибки, но создавать слишком простые задания, либо наоборот.
При этом динамический бенчмарк требует строгой инфраструктуры. Нужно изолировать контекст разных сессий, проверять, что скрытые тесты действительно обнаруживают только нужный дефект, исключать задания с побочными поломками и контролировать состояние репозитория. Небольшая ошибка в правилах допуска способна исказить сравнение сильнее, чем различие между самими моделями.
Что пока нельзя считать доказанным
SWE-Duel пока следует воспринимать как исследовательский прототип, а не как общепринятый стандарт оценки. Описанные результаты относятся к версии работы, опубликованной на arXiv, и не заменяют независимое воспроизведение. Из доступного материала также нельзя сделать вывод, что методика полностью предотвращает утечки или что приведённые показатели сохранятся на других репозиториях, языках и инструментах.
Перед использованием результатов в сравнении моделей стоит проверить полную статью, описание эксперимента и исходные ограничения. Особенно важно уточнить состав 15 репозиториев, распределение языков, критерии отбора задач и то, как обрабатывались неудачные или неоднозначные исправления. Для практического теста собственного агента полезно отдельно измерять три результата: прохождение исходных тестов, обнаружение скрытого дефекта и отсутствие регрессий после исправления.
Источники работы: страница статьи на arXiv — https://arxiv.org/abs/2610.12569, PDF-версия — https://arxiv.org/pdf/2610.12569, запись в API arXiv — https://export.arxiv.org/api/query?id_list=2610.12569.
