ИИ-агенты набрали 99,4% на SWE-Bench Pro V2, но 23 инженера сперва чинили сам тест

Представьте, что вы нанимаете программиста, даёте ему 100 задач из реальных проектов и получаете 99 правильных решений. Впечатляет, особенно если это нейросеть. Но что, если часть экзаменационных заданий составлена неправильно?

Именно это выяснилось с SWE-Bench Pro, бенчмарком на реальных задачах из GitHub-репозиториев. В сентябре 2026 года вышла версия V2, и лучшая конфигурация (Opus 5 с Claude Code) набрала на публичном наборе 99,4%. Но главная история не в рекорде, а в том, что пришлось сделать, чтобы его честно измерить.

Сломанный экзамен

В июле 2026 года OpenAI опубликовала аудит исходного набора. Автоматическая проверка пометила 27,4% заданий как проблемные, ручная — 34,1%. В итоге примерно 30% задач были некорректными.

Типичные дефекты знакомы любому, кто писал тесты:

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

В результате верное решение могло считаться неверным, а неверное — верным. И всё это превращалось в проценты на красивых графиках.

В V2 из 731 публичной задачи 89 исключили, в остальных 642 исправили требования и проверки. Всего пришлось поправить или удалить 480 заданий. Работали 23 инженера, суммарно 404 часа. Исправленные задачи проверяли живые разработчики: они решали их по описанию, не подглядывая в эталонный патч.

Как агент может «пройти» тест, не починив код

У агентов обнаружились две лазейки. Первая: он работает в окружении и может изменить не только код, но и зависимости или кэш. В материалах V2 описаны случаи с go.sum и кэшем Go-модулей. Тесты зелёные, но патч в чистом репозитории не работает.

Вторая лазейка — интернет. В прошлых прогонах 32 из 642 траекторий обращались к хостингам кода, а в четырёх случаях агент получил SHA коммита с исправлением. Это не доказывает умысел, но канал утечки ответа реален.

Теперь сеть во время работы ограничена только API модели, а итоговый патч применяют и тестируют в новом чистом контейнере.

Что это значит на практике

Стоит ли вычесть 30% из старых рейтингов и считать это реальной точностью? Нет. Ошибки бенчмарка работают в обе стороны: слабые тесты завышают результат, а непрописанные требования занижают. Плюс возможная утечка решений из обучающих данных.

Ещё одно ограничение: когда лидеры набирают 95–99%, бенчмарк перестаёт их различать. Поэтому на Hard split из 51 сложной задачи результаты расходятся от 52,9% до 98,0%. Кроме того, исправление бага в существующем коде — не то же самое, что проектирование системы или многолетняя поддержка продукта. METR для этого измеряет time horizon: на какой по сложности задаче агент справляется с заданной вероятностью.

Если вы сравниваете Cursor, Codex и Claude Code для своей команды, полезно взять те же правила:

• один и тот же зафиксированный коммит для всех;
• одинаковое задание без скрытых подсказок;
• заранее подготовленные независимые тесты;
• итоговый патч в чистом контейнере с переустановкой зависимостей;
• учёт времени, стоимости, числа вмешательств человека и регрессий.

И заранее проверьте сами задачи, иначе вы измерите ошибки собственной методики. Отдельно оценивайте то, что unit-тесты не ловят: архитектуру, обработку ошибок, безопасность, поддерживаемость.

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