Opus 5 прошёл 24% контрольных точек SlopCodeBench, но код стал многословнее

SlopCodeBench, относительно новый (март 2026 года) бенчмарк для оценки долгих кодерских задач, созданный в лаборатории GOrlanski в Университете Висконсина в Мэдисоне (UW Madison). Его особенность: модель не видит всю постановку задачи сразу, как в большинстве бенчмарков, а получает требования порциями, по мере прохождения так называемых контрольных точек (checkpoint), имитируя реальную разработку, где кодовую базу нужно развивать во времени. В оригинальной статье лучшие на тот момент модели, GPT-5.4 и Opus 4.6, прошли строгую проверку лишь на 11% и 17% задач соответственно, то есть бенчмарк далёк от насыщения.

Автор поста, инженер компании Humanlayer (ник dhorthy на Hacker News), прогнал через часть бенчмарка три модели Anthropic, Opus 4.8, Sonnet 5 и Opus 5, и наблюдал за процессом вживую шесть часов. Взял три задачи с суммарно 17 контрольными точками: circuit_eval (лёгкая, 8 точек), database_migration (средняя, 5 точек) и dynamic_config_service_api (сложная, 4 точки). Критерий «строгого прохождения»: зелёными должны быть не только новые тесты текущей точки, но и все унаследованные регрессионные тесты предыдущих, то есть один дефект на четвёртой точке блокирует зачёт всех последующих, даже если код там технически корректен.

Результат: Opus 5 показал лучший итог, 24% строгих прохождений (4 из 17 контрольных точек): первые три точки задачи circuit_eval плюс первая точка database_migration. Opus 4.8 и Sonnet 5 набрали по 6% (1 из 17), ту же самую первую точку database_migration. Ни один из девяти прогонов (три модели на три задачи) не довёл ни одну задачу до конца без единого дефекта, даже задачу, помеченную как «лёгкая».

SlopCodeBench параллельно считает 41 детерминированную метрику качества кода: размер, сложность, дублирование, декомпозицию, нарушения линт-правил и здоровье графа зависимостей. У всех трёх моделей качество кода ухудшалось по ходу задачи: доля «многословных» строк выросла примерно с 65% на первой точке до 80% к восьмой, включая Opus 5. Доля строк, нарушающих хотя бы одно «слоп»-правило: у Opus 4.8, 98%, у Opus 5, 93%, у Sonnet 5, 89%.

Opus 5 написал впятеро больше функций, чем Opus 4.8 и Sonnet 5, за те же задачи, около 2000 функций всего, при этом сохранив самую низкую среднюю цикломатическую сложность на функцию; правда, значительная часть прироста, это тесты, а объём собственно продакшен-кода у Opus 5 оказался лишь примерно в 1,8 раза больше, чем у Opus 4.8. Opus 4.8 и Sonnet 5 реагировали на растущую сложность задачи иначе, укрупняя отдельные функции вместо декомпозиции: у Opus 4.8 функции выросли в среднем на 70% за восемь точек, а самая сложная функция достигла цикломатической сложности 93. Дублирование кода разошлось ещё сильнее: у Opus 4.8 доля задублированных строк выросла с 4,6% до 16,8% (с переломом на третьей точке, когда новые требования начали конфликтовать с изначальной архитектурой), тогда как у Opus 5 дублирование почти не изменилось, с 2,41% до 2,64%. Доля функций, вызванных ровно один раз: у Opus 4.8, около 50%, у Sonnet 5, 71,5% (максимум среди трёх моделей).

Отдельно автор попросил модель «5.6-Sol» собрать упрощённый набор правил (76 детекторов против 200+ в оригинальной Python-библиотеке SlopCodeBench) и применил его к собственному TypeScript-репозиторию компании. С оговорками (меньше правил, паритет с исходным набором не проверен) результат вышел показательным: код, который Opus 5 написал без контроля человека, содержал более чем в 11 раз больше «слоп»-срабатываний на тысячу строк, чем собственный код команды, на 99% сгенерированный ИИ, но тщательно проверенный людьми.

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

Вывод автора: результаты впервые дают числовое подтверждение тезису, который он много месяцев формулировал «на ощущениях», что для реалистичной инженерной работы, где требования раскрываются постепенно, сегодняшним моделям пока нельзя доверять автономную работу без присмотра человека. Качество кода деградирует у всех моделей по ходу задачи, и даже лучшая из протестированных, Opus 5, не довела до чистого финала ни одну из трёх задач.

Ключевые факты

• Opus 5 показал лучший результат на подмножестве SlopCodeBench, 24% строгих прохождений (4 из 17 контрольных точек); Opus 4.8 и Sonnet 5, по 6% (1 из 17)
• Ни один из девяти прогонов (3 модели × 3 задачи) не завершил задачу без единого дефекта, даже помеченную как «лёгкая»
• Opus 5 написал впятеро больше функций, чем Opus 4.8 и Sonnet 5, при этом 93%/98%/89% строк кода трёх моделей нарушают хотя бы одно правило «слоп»-детектора
• Доля многословных строк у всех моделей выросла с ~65% на первой контрольной точке до ~80% к восьмой, включая Opus 5
• На собственном TypeScript-репозитории автор нашёл: неконтролируемый код Opus 5 даёт более чем в 11 раз больше «слоп»-срабатываний на 1000 строк, чем тщательно проверяемый ИИ-код его команды

Почему это важно

SlopCodeBench закрывает слепую зону обычных кодерских бенчмарков: там модель видит всю задачу целиком, а здесь требования раскрываются постепенно, как в реальной разработке, и оценивается не разовое решение, а способность поддерживать и развивать кодовую базу во времени. Прогон показал: даже лучшая модель, Opus 5, строго прошла лишь 24% контрольных точек, а качество кода у всех моделей падает по ходу задачи, это прямое подтверждение опасений насчёт полностью автономной работы ИИ-агентов над длинными инженерными задачами.

Кому это важно

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

Как это применить

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

Можно ли доверять

Это независимый пост одного инженера (dhorthy, Humanlayer), а не рецензируемое исследование: выборка, всего 17 контрольных точек в трёх задачах, по одному прогону на модель на задачу, а сам SlopCodeBench, оригинальная академическая работа лаборатории GOrlanski (UW Madison). Автор сам отмечает ограничения своей дополнительной проверки на TypeScript (меньше правил, паритет с оригинальным набором не подтверждён). В автоматически сгенерированном отчёте о стоимости и дефектах попалась фраза «Каждый доллар покупал корректность. Просто никто не купил её достаточно», сам автор не любит такие обороты, но решил её не вычёркивать.

Риски и подводные камни

Выборка крошечная, девять прогонов всего, при одной попытке на модель и задачу, поэтому цифры (24% против 6%) стоит воспринимать как сигнал, а не как точный рейтинг. Метрики качества кода детерминированы, но, по признанию самого автора, их легко «обыграть» и они не полностью отражают реальную поддерживаемость кода. Главный практический риск, который подтверждают данные: качество кода у всех протестированных моделей деградирует по мере роста задачи, и ни одна не довела ни одну из трёх задач до чистого финала, это ограничивает доверие к полностью автономной («lights-off») работе моделей над длинными инженерными задачами.

«Каждый доллар покупал корректность. Просто никто не купил её достаточно.»

— автоматически сгенерированный отчёт о стоимости и дефектах, оставлен без правок dhorthy (Humanlayer)