Cognition выпустила FrontierCode 2.0: лучший результат — всего 45,5%

Cognition, компания за агентом Devin, опубликовала FrontierCode 2.0 — второе поколение бенчмарка, который оценивает не прохождение тестов, а «мёрджабельность» кода: принял бы такой пулл-реквест мейнтейнер реального проекта. Лучший результат принадлежит Claude Opus 5.5 — 45,5%. В предыдущей версии FrontierCode 1.1 у него было 54,6%. Разрыв между моделями стал заметнее, а потолок задан далеко: бенчмарк не насыщен.

Почему Cognition ужесточила планку

По опыту Devin, агентная разработка далека от решённой задачи. Модели плохо угадывают намерение пользователя, нарушают неочевидные ограничения и не предвидят долгосрочных последствий правок, поэтому человеку приходится вмешиваться. Большинство кодинг-бенчмарков этого не видят: они дают подробную спецификацию и быстро насыщаются. Пример — задача vf2-speedup-networkx из Terminal-Bench 4.0, где полностью описаны подход, формат и условия проверки, включая ускорение минимум в 5000 раз.

FrontierCode устроен иначе. Более 20 мейнтейнеров открытых проектов потратили по 40+ часов на каждую задачу, собирая её из собственных репозиториев. В версии 2.0 задачи взяты из на 55% большего числа репозиториев и включают патчи безопасности и оптимизации производительности. Блокирующих критериев стало на 43% больше. Эталонные решения меняют в среднем на 67% больше файлов и на 89% больше строк, а кодовые базы больше на 25%. Отдельно Cognition усилила аудит: в 80% задач эталон отличается от upstream-PR (в 1.0 было 60%). Один из автоматических аудитов даже нашёл уязвимость в upstream-реализации, о ней сообщили мейнтейнерам.

Таблица: кто сколько потерял

Ниже оценки в формате «FrontierCode 1.1 → FrontierCode 2.0»:

• Claude Opus 5.5 — 54,6% → 45,5%. Лидер, на парето-границе с дорогой стороны.
• GPT-6 Astra — 53,3% → 42,8%.
• Grok 4.7 — 47,6% → 28,6%.
• Gemini 4 Argon — 47,5% → 26,3%.
• Muse Wonder 1.0 — 47,0% → 24,3%.
• SWE-2 — 50,0% → 23,9%.
• DeepSeek V4.1 Flash — 43,9% → 19,3%.
• Kimi K3 — 44,2% → 17,7%.

На парето-границе «цена — качество» вместе с Opus 5.5 стоят Luna, Haiku и Sol на дешёвом краю. GPT-6.1 Sol Cognition отдельно выделяет за сильный результат относительно стоимости. Вывод по открытым моделям жёсткий: запас для роста большой, а у западных OSS-моделей особенно.

Тщательность вместо послушания

Главное изменение — рост доли критериев «thoroughness»: число блокеров этого типа выросло с 168 до 501, то есть втрое. Они проверяют то, что агент должен вывести из инструкции и кода, хотя это не сказано прямо. Например, исправить баг во всех местах, а не только в названном, или поддержать соседние типы входных данных, если похожий код их уже обрабатывает. Доля проваленных проверок здесь выросла с 11,7% до 19,2%, и это самая высокая частота провалов среди категорий. Для core behavior — 14,9% против 9,5%, для обратной совместимости — 5,9% против 2,9%.

Другие категории блокеров изменились так: core behavior 399 → 353, избегание регрессий 174 → 259, качество тестов 202 → 213, lint/format/typecheck 112 → 183, scope 56 → 123, обратная совместимость 85 → 76, компиляция 86 → 69, целостность тестов 48 → 48.

Больше усилий — не всегда лучше

FrontierCode не вознаграждает за объём написанного кода, поэтому оценка может падать при росте уровня рассуждений. Причина — scope-критерии. У Claude Opus 5 доля пройденных scope-критериев падает с 69,2% на low до 51,1% на max, у Opus 4.8 — с 81,9% до 70,9%, у Claude Fable 5 — с 79,1% до 63,4%, у GPT-5.6 Sol — с 79,7% до 68,3%. При этом критерии реализации растут: у Opus 5 с 79,3% до 83,0%. Модели при большем «усилии» трогают больше файлов, иногда лишнего. Среди менее значимых причин Cognition называет более частое жульничество (случайную подгрузку коммита с решением) и «передумывание», когда модель убеждает себя в неверном прочтении задачи.

В версии 2.0 scope-требования смягчили, чтобы не штрафовать за неожиданное, но приемлемое поведение: средняя доля провалов упала с 9,0% до 3,8%. На пуле из Claude Opus 5.5, Claude Fable 5.1, GPT-6.1 Sol и GPT-6 Astra тщательность проваливается в 26,0% проверок на low и в 15,3% на max.

Показателен пример Mock Service Worker: задача — исправить баг, при котором resetHandlers() не перезапускает генераторные резолверы. Opus 5.5 на любом уровне усилия, от low до max, не прошёл ни одного из пяти прогонов: исправление работало как заявлено, но грейдер отметил сам подход к правке.

Что учесть командам

Если вы выбираете модель для автономного кодинга, смотрите не на pass@1 по чётко описанным задачам, а на поведение при неполном промпте. Практически: закладывайте код-ревью на предмет побочных правок и пропущенных «соседних» случаев, не ставьте максимальный reasoning effort по умолчанию без замеров на своих репозиториях и сравнивайте модели по стоимости прогона, а не только по баллу. Для open-source стека результаты 2.0 — повод закладывать запас на ручную доводку.