За последние пару лет агенты на базе больших языковых моделей уверенно вошли в повседневную разработку: умеют читать репозитории, чинить баги, предлагать патчи и гонять тесты. На классическом SWE-Bench-Verified топовые системы уверенно берут более 70% задач с первой попытки. Проблема в том, что такой прогресс создаёт ложное чувство готовности к реальной индустрии. Там задачи редко ограничиваются одной строкой, и почти всегда требуют изменений в нескольких местах, согласования интерфейсов и аккуратной работы с зависимостями. Исследователи представили более жёсткий полигон — SWE-Bench Pro — и увидели прагматичную картину: даже сильнейшие модели пока далеки от уровня профессионального инженера. Пока можно спать спокойно.
Что именно собрали
SWE-Bench Pro включает 1 865 задач из 41 активно поддерживаемого репозитория. Это бизнес‑приложения, B2B‑сервисы и инструменты для разработчиков. Набор разделён на три части: открытый публичный (11 репозиториев), скрытый held‑out (12) для контроля переобучения и коммерческий (18) из приватных кодовых баз, где публикуются только результаты.
Главное отличие — сложность. Исключены микроправки на одну-две строки: каждое задание требует минимум 10 строк изменений. В среднем эталонное решение — это 107 строк кода в 4 файлах, а более сотни задач превышают рубеж в 100 строк. Такой масштаб регулярно встречается в компаниях, где правка одной функции почти всегда тянет за собой обновление интерфейсов и тестов.
Как готовили задания
Исходной точкой служит пара последовательных коммитов: базовый и тот, что фиксирует баг или добавляет фичу. Тесты разделены на патч для проверки и рабочее решение. Базовая версия с новыми тестами должна падать, а с эталонными изменениями — проходить. Это классическая схема fail2pass.
Чтобы убрать неоднозначность, авторы руками дополнили каждую задачу описанием проблемы, списком требований и, при необходимости, явным интерфейсом: названиями классов, сигнатурами методов, ожидаемыми роутами. Среды запуска упакованы в Docker‑образы для Python, Node.js и Go; все экземпляры отфильтрованы от ненадежных тестов многократными прогонами и ручной проверкой.
Как оценивали
Команда использовала единый каркас на основе SWE‑Agent: до 200 шагов, доступ к инструментам, унифицированный промт. Главная метрика — Pass@1, то есть доля задач, решённых с первой попытки так, что все тесты проходят. Дополнительно применялась оценка моделью как судьёй, чтобы классифицировать типичные отказы: ошибки алгоритма, синтаксис, промахи в использовании инструментов, переполнение контекста и так далее.
Что получилось
На публичном датасете лучший результат показал GPT‑5 — 23.3%. Claude Opus 4.1 — 22.7%, Sonnet 4 — 17.6%, Gemini 2.5 Pro Preview — 13.5%. Среди открытых моделей SWE‑Smith‑32B набрал 6.8%, GPT‑4o — 4.9%, Qwen‑3 32B — 3.4%. На коммерческом датасете показатели ещё ниже: у Opus 4.1 — 17.8%, у GPT‑5 — 14.9%, дальше — однозначные проценты. Это резкий контраст с прежними бенчмарками, где сильные системы закрывали львиную долю задач.
По языкам картина неоднородная. На Python и Go модели ощутимо увереннее, тогда как JS/TS дают более низкую и нестабильную точность. Разброс по репозиториям тоже велик: есть проекты, где решения почти не проходят, и есть заметные «островки» повышенной успешности.
Где агенты чаще всего ошибаются
Анализ отказов показывает, что большие модели чаще промахиваются по смыслу — в логике и алгоритмах на больших правках, а меньшие — по синтаксису и инструментам. У некоторых систем встречались переполнения контекста и бесконечное чтение файлового дерева, ошибки форматирования и несовместимости сборки. Иначе говоря, длинный горизонт разработки вскрывает не только понимание задачи, но и дисциплину инженерного процесса: умение вносить согласованные изменения в нескольких местах, поднимать окружение, чинить миграции и тестовые фикстуры.
Почему это важно
SWE-Bench Pro возвращает оценку ИИ‑агентов к тем сценариям, где они реально нужны компаниям: многофайловые патчи, заметные изменения интерфейсов, сложные зависимости и тестовые наборы, близкие к продакшн‑уровню. Видимая «просадка» до ~23% — не провал, а честная точка отсчёта. Такой бенчмарк позволяет измерять прогресс там, где ценность автоматизации максимальна, и даёт диагностические сигналы: где упираемся в контекст, где хромают инструменты, где нужна лучшая модель мира кода.
Что дальше
Авторы планируют расширить языковое покрытие (Java, C#, Rust, Kotlin), выйти за пределы «прошли тесты/не прошли» к метрикам качества, безопасности и производительности, добавить сценарии совместной разработки: мультиагентные системы, ревью, мердж‑конфликты, распределённые пайплайны. Это движение к оценке всей инженерной деятельности.
📜 Полная статья
💾 Код
***
Если вам интересна тема ИИ, подписывайтесь на мой Telegram‑канал — там я регулярно делюсь инсайтами по внедрению ИИ в бизнес, запуску ИИ-стартапов и объясняю, как работают все эти ИИ-чудеса.
Источник: habr.com
