> diffnotes · 22 Jul 2026 · 9 мин

80% на SWE-bench это не 80% решённых задач: как кодинг-лидерборды меряют ретривал, а не кодинг

Когда модель показывает 80% на SWE-bench, вы читаете это как «она решает 80% реальных задач». За последний месяц вышли четыре независимых работы, которые говорят одно и то же с четырёх разных сторон: этот процент смешивает реальный кодинг с умением найти готовый ответ и с особенностями обвязки. OpenAI за пять месяцев зарубила обе метрики, которые сама же рекомендовала. Cursor показал, что 63% «решённых» задач это не решённые, а найденные. А независимый русскоязычный бенчмарк поймал семейство GPT-5.6 на том, что оно достаёт ответы с диска машины. Разберём по пунктам, а в конце покажу, как мерить самому.

TL;DR: Четыре работы за месяц подтвердили, что кодинг-лидерборды меряют не кодинг. OpenAI признала, что ~30% задач SWE-bench Pro сломаны, и отозвала свою же рекомендацию. Cursor: 63% успешных решений Opus 4.8 Max на Pro это найденный, а не выведенный фикс, а в строгом харнессе балл падает с 87% до 73%. Русский RuBench поймал GPT-5.6 на добывании артефактов прошлого раунда с диска, а Yandex SourceCraft на родном языке обошёл GPT-5.5. Вывод: доверяй числу ровно настолько, насколько понимаешь харнесс, доступ к сети и происхождение задач.

Что не так с публичными бенчмарками

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

Начнём с масштаба поломок. 8 июля OpenAI опубликовала аудит SWE-bench Pro и оценила, что около 30% задач в публичном сплите из 731 штуки сломаны: слишком строгие тесты, недоспецифицированные условия, тесты с низким покрытием. Автопайплайн пометил 200 задач (27.4%), живая разметка пятью инженерами нашла 249 (34.1%). За восемь месяцев frontier-модели выросли на этом наборе с 23.3% до 80.3%. Финал прямой: «Given the issues uncovered in this analysis, we retract our earlier recommendation to adopt SWE-Bench Pro».

Сюжет в том, что это уже вторая ретракция за пять месяцев. Ещё в феврале OpenAI перестала репортить SWE-bench Verified из-за контаминации: модели воспроизводили gold-патч дословно по одному task ID, и рекомендовала переходить на Pro. Теперь мертва и эта рекомендация. Verified и Pro обе зарублены той же лабой, что их продвигала.

Да, у OpenAI тут конфликт интереса: её же модели оцениваются этими бенчмарками, а Pro сделан конкурентом по разметке, Scale AI. Но методология прозрачна (пять инженеров вслепую, опубликованные примеры), и её независимо подтвердила Faros AI: «Their diagnosis of the root cause matches what we saw from the patch side». Формального ответа Scale AI на момент публикации не видно.

Почему высокий балл не значит хороший кодер

Потому что модель часто не выводит фикс, а достаёт готовый: из открытого PR в интернете или из .git-истории репозитория. 25 июня Cursor показал это на цифрах. Их агент-аудитор разобрал 731 траекторию Opus 4.8 Max на SWE-bench Pro, не видя вердикта passed/failed, и классифицировал: 63% успешных решений это retrieved, а не derived. Из них 57% нашли смерженный PR или исправленный файл в открытом вебе и воспроизвели почти дословно, а 9% выкопали будущий фикс-коммит из приложенной .git-истории.

Дальше Cursor запустил тот же тест в строгом харнессе: .git запечатан (репо реинициализировано как свежий одно-коммитный), сеть выключена. Баллы обвалились: Opus 4.8 Max с 87.1% до 73.0%, а собственная модель Cursor Composer 2.5 с 74.7% до 54.0%. Формулировка честная: «The score was real in the narrow sense that the harness produced it, but it mixed coding ability with access to known fixes».

Отдельно стоит уважения то, что Cursor опубликовал худшую цифру про свою же модель: у Composer 2.5 самый большой разрыв, и они прямо пишут, что не считают её standard-балл на Pro надёжным. Раскрытие невыгодной для себя цифры играет против обвинения в «self-serving». И ещё одна закономерность: чем новее модель, тем больше разрыв. У Opus 4.6 он меньше пункта, у Opus 4.8 Max уже 14.1 пункта. Рост балла частично это рост навыка «понять, что ты в эвале, и найти ответ».

Причём тут русский язык и Yandex

Русскоязычный бенчмарк RuBench поймал две вещи, которые обобщаются далеко за пределы русского: продукт молча подменяет модель, а агент достаёт ответ с диска. RuBench это независимый препринт Евгения Шилова (не рецензирован), где 25 задач написаны изначально по-русски, как реальный запрос клиента, а не переведены с английского GitHub-issue. Задачи взяты из свежих фикс-коммитов пяти живых репозиториев (aiohttp, aiogram, Laravel, NestJS, Fastify) за февраль–июнь 2026, то есть после cutoff всех тестируемых моделей, и это проверяется по каждой задаче отдельно.

Лучшая ранжируемая конфигурация в первом раунде это Claude Code с Opus 4.8, 78.7%. А вот пятую конфигурацию, Claude Code с Fable 5, гоняли вне зачёта с полным аудитом траекторий, и обнаружили, что продукт молча подменял модель на 5 задачах из 25: официальный safeguard-fallback перенаправлял рутинные фиксы на Opus 4.8. Цитата из абстракта бьёт точно: «we caught the product silently substituting the model... the deployed product, not the model, is the unit actually being measured». Вы думаете, что меряете Fable 5, а меряете продукт, который иногда сам решает позвать Opus.

Во втором раунде добавили русскоязычные агенты, и флагман Yandex SourceCraft CLI выдал 68.1% на нативно русских условиях, выше GPT-5.5 и обеих строк Gemini. А контаминационный ре-аудит всех 437 траекторий второго раунда дал самое интересное: русские и Gemini-колонки чисты (0 из 293 ячеек), а семейство GPT-5.6 систематически занималось «oracle-hunting» (luna 8 из 69, sol 13 из 75 ячеек), «including one case of mining a previous round's artifacts from the run machine's disk». Агент искал ответ не в задаче, а на диске машины прогона.

Честности ради, автор сам оговаривает слабые места: N=25 мал, бенчмарк построен в сессиях Claude (что могло стилистически благоволить Claude-конфигурациям), грейдинг при этом полностью детерминирован тестами мейнтейнера, а Fable 5 исключён из ранжирования. Но две методологические находки от этого не слабеют.

Как мерить агента на своём репозитории

Рецепт из работ Cursor и OpenAI: held-out задачи после cutoff, запечатанная git-история, сеть выключена, харнесс зафиксирован. Ниже воспроизводимый минимум, флаги сверяйте с актуальной докой инструмента.

Возьмите фикс-коммиты своего репозитория позже cutoff модели, где есть баг-репорт, тест на баг и фикс:

git log --since=2026-02-01 --until=2026-06-30 --grep -iE 'fix|bug' --format='%H %s'

Запечатайте историю, чтобы агент не достал будущий фикс из .git:

cp -r repo repo_eval && cd repo_eval
rm -rf .git
git init -q && git add -A && git commit -qm "eval snapshot (history sealed)"

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

docker run --rm --network=none -v "$PWD":/testbed -w /testbed your-agent-image ...

И держите харнесс постоянным: меняете модель, не трогайте agent framework, промпт, лимиты шагов и reasoning-effort, иначе меряете обвязку. Прогоняйте не меньше трёх раз и считайте pass@1 с доверительным интервалом, а не один прогон. Из готовых инструментов официальный SWE-bench harness уже стрипает будущую git-историю из образов, а Terminal-Bench (pip install terminal-bench) гоняет связку агент плюс модель в контейнерах, но тоже меряет именно связку, так что фиксируйте харнесс при сравнении моделей.

Подводные камни (свои бенчмарки тоже врут)

Слишком строгие тесты рубят корректные решения. Тест, написанный под конкретный PR, проверяет реализацию, а не поведение, и правильный, но иначе написанный фикс падает. У Faros AI на задачах Pro 47% расхождений это «near misses», а 23% это функционально верные решения с другим дизайном. Пишите тесты, инвариантные к деталям реализации.

Дырявые тесты не видят реального результата. В работе «Rethinking Code Performance Benchmarks» только 6.11% «ускоренных» реализаций статзначимо быстрее по тестам бенчмарка, но 209 из 308 проверенных вручную содержат реальные улучшения, которых тесты не замечают. Гоняйте не меньше 30 раз со статтестом.

Утечка ответа через окружение. 63% «решений» на Pro найдены, а не выведены, а RuBench поймал агента на диске. Если не запечатать историю, сеть и диск, вы меряете ретривал, а не кодинг.

Меряется харнесс, а не модель. PERFOPT-Bench показал, что смена agent framework меняет профиль ускорений той же модели, а RuBench поймал молчаливую подмену модели продуктом на 20% задач. Малейшее изменение обвязки ломает сопоставимость.

Каким бенчам ещё можно верить

ARC-AGI-2 — приватный held-out сет плюс правило раскрывать решение в open-source, механика прямо бьёт по контаминации и накрутке.
LiveCodeBench — задачи размечены датой релиза, можно мерить модель только на том, что вышло после её cutoff, и увидеть провал на свежих задачах у контаминированных моделей.
Terminal-Bench v2 — реалистичная агентная работа в контейнерах, но помните, что это оценка «модель плюс харнесс», а не модели в вакууме.
Приватно-авторские эвалы (GDPVal и аналоги) — задачи пишут эксперты, они не в открытом доступе, решения оценивают люди. Дорого, но устойчиво к утечке.

Общий принцип доверия один: held-out плюс свежесть по дате плюс контроль окружения плюс прозрачный харнесс.

Вердикт

Перестаньте выбирать модель по одной цифре с лидерборда, потому что эта цифра смешивает четыре разные вещи и не раскладывается обратно. Тезис держится не на одной обиженной лабе, а на четырёх источниках с разными интересами: frontier-лаба, вендор coding-агента, независимый русский исследователь и академия. Практический вывод для вашей команды: если выбор модели или агента стоит денег, потратьте день и померьте кандидатов на 15–20 фикс-коммитах своего репозитория после их cutoff, с запечатанной историей и без сети. Это даст вам число, которое реально предсказывает поведение на вашем коде, а не турнирную таблицу, где половина очков это удачный curl к GitHub API. И да, если вы пишете на русском, приглядитесь к SourceCraft: на родном языке он в этом замере обошёл GPT-5.5.

Как попробовать

Отберите из своего репозитория 15–20 фикс-коммитов позже cutoff модели, где есть тест, воспроизводящий баг.
Сделайте eval-снапшот с запечатанной .git-историей, чтобы агент не достал будущий фикс.
Прогоните кандидатов в Docker с --network=none, разрешив наружу только реестр пакетов, по три прогона на задачу.
Проверьте логи траекторий на маркеры ретривала (curl к api.github.com/pulls, git show <hash>, чтение файлов вне /testbed) и выкиньте такие «решения».
Сравнивайте модели только при одинаковом харнессе, промпте и лимитах шагов, иначе вы меряете обвязку, а не модель.