FrontierCode Diamond: 13,4% патчей для слияния на 50 трудных задачах (июнь 2026)

Дополнительные рекомендации по работе с инструментами доступны в документации Ailoot.

Что такое FrontierCode и чем он важен?#

Cognition — компания, создавшая Devin, автономного ИИ-инженера, представленного в марте 2024 года, и Windsurf, приобретённый в июле 2025 года. Компания также разрабатывает собственное семейство моделей SWE-1.x. Бенчмарк опубликован в блоге Cognition: cognition.com/blog/frontier-code.

Важнейшее изменение здесь не в новых числах, а в том, каким способом теперь оценивают качество кода.

Структура бенчмарка включает три уровня: Extended — все 150 задач, Main — 100 наиболее трудных, включая Diamond, и Diamond — 50 задач максимальной сложности. По заявлению Cognition, набор Diamond пока «в значительной степени не насыщен»: даже лучшая модель решает менее 15% задач. Такой запас должен продлить срок полезности бенчмарка и помочь избежать быстрого насыщения, которое произошло с HumanEval.

Что проверяет FrontierCode: примет ли мейнтейнер PR?#

Шесть критериев оценки, перечисленных в официальной публикации Cognition:

1. Поведенческая корректность (Behavioral correctness) — решает ли патч поставленную задачу.
2. Защита от регрессий (Regression safety) — не нарушает ли он работу существующего кода.
3. Техническая чистота (Mechanical cleanliness) — проходит ли код сборку, линтеры и проверки стиля.
4. Корректность тестов (Test correctness) — действительно ли работают тесты, созданные агентом. Тесты, проходящие при любом содержимом кода, не засчитываются.
5. Границы изменений (Scope) — ограничивается ли патч файлами, относящимися к задаче.
6. Качество кода (Code quality) — следует ли он соглашениям проекта и остаётся ли понятным для чтения.

Чтобы патч считался пригодным к слиянию, необходимо пройти все шесть критериев. Не выполнен хотя бы один — патч не принимается.

Главное изменение подхода именно в этом. По формулировке Cognition, «корректность стала минимальным условием». Раньше бенчмарк выяснял, прошёл ли код тесты; теперь вопрос в том, одобрит ли его технический руководитель проекта.

Cognition описала три новых способа оценивания:

• Reverse-Classical: тест, написанный агентом, должен завершаться ошибкой на специально сломанном варианте кода. В противном случае тест не подтверждает корректность решения.
• Code Scope: автоматическая проверка удостоверяется, что патч не превысил согласованные в задаче границы по файлам и числу строк.
• Adaptive Classical Grading: инструмент на базе LLM под названием «mutagent» адаптирует строгие тесты так, чтобы они допускали корректные варианты реализации.

Почему прежних бенчмарков недостаточно?#

К 2024 году ИИ-агенты уже достигли предела возможностей HumanEval. SWE-bench Verified сталкивается с похожей проблемой: в августе 2025 года OpenAI публично указала на риск контаминации, когда модели могли встречать набор данных во время обучения. Из-за этого прежние бенчмарки стали хуже различать сильнейшие модели.

В марте 2026 года вышло ключевое исследование, поставившее под вопрос прежнюю систему оценки.

В исследовании:

• Участвовали четыре действующих мейнтейнера из трёх репозиториев: scikit-learn, Sphinx и pytest.
• Им передали 296 созданных ИИ PR из SWE-bench Verified; все эти изменения проходили автоматические тесты.
• Затем сопоставили решения мейнтейнеров с оценками автоматической системы.

Таким образом, автоматический бенчмарк мог засчитать PR, который мейнтейнер не стал бы сливать; в среднем разница составляла около четверти случаев. Три наиболее частые причины отказа, от менее серьёзной к более серьёзной:

1. Качество кода — несоответствие стилю репозитория.
2. Поломка соседнего кода — изменение нарушает работу других частей проекта.
3. Ошибка в основной функции — решение не выполняет задачу полностью, хотя тесты показывают успех.

FrontierCode переводит эту проблему в формат отдельного бенчмарка. Cognition развила тот же принцип, привлекая более 20 мейнтейнеров вместо четырёх.

Ещё одно основание для внимания — исследование безопасности патчей, созданных ИИ, опубликованное в декабре 2025 года.

В нём 61% решений SWE-Agent с Claude 4 Sonnet оказались функционально корректными, но безопасными были только 10,5% из них.

Код может пройти тесты и при этом создать уязвимость. SWE-bench этого не показывает, поскольку не оценивает безопасность. FrontierCode пытается учитывать связанные риски через критерии технической чистоты и качества кода.

Результаты моделей: Opus 4.8 — 13,4%, GPT-5.5 — 6,3%#

Из результатов можно сделать несколько наблюдений:

• Отрыв лидера заметен. Anthropic Opus 4.8 набрала примерно вдвое больше ближайшей модели. На SWE-bench разница могла быть незаметна, а здесь она выражена явно.
• Модели с открытым кодом пока уступают. Kimi K2.6 — лучшая из них на Diamond с результатом 3,8%, что примерно в три-четыре раза меньше результата Opus 4.8. Cognition не привела полные результаты Kimi K2.6 для Main и Extended, поэтому сопоставить модели по всему набору нельзя.
• Cognition включила в таблицу и собственную модель: SWE-1.6 находится в нижней части рейтинга и получила 2,5% на Diamond.

Поднабор Diamond намеренно оставлен «в значительной степени не насыщенным». По замыслу Cognition, запас сложности должен сохранять его актуальность несколько лет. Для сравнения, прежние бенчмарки могли достигать потолка за 12–18 месяцев.

Что означает результат «13% пригодных к слиянию» для работы с Claude Code?#

Важно учитывать, что FrontierCode Diamond состоит из специально отобранных задач высокой сложности. В новом проекте с небольшим числом зависимых модулей агент может справляться заметно лучше. Для Opus 4.8 результат на Extended, включающем все 150 задач, составляет 51,8% пригодных к слиянию.

Результат 51,8% относится к набору Extended из 150 задач. Он выше Diamond, но ни одна цифра не оценивает пригодность патчей всех моделей в ваших задачах. Отсутствующие оценки Main или Extended других моделей не позволяют приписать им результат.

Практические выводы для тех, кто использует ИИ при разработке:

• Успешные тесты ещё не означают, что код готов к слиянию. Тесты, созданные самим ИИ, могут проходить и на неверном коде. FrontierCode проверяет это подходом Reverse-Classical: тест должен провалиться на сломанном варианте.
• Стиль и соглашения проекта влияют на решение. Если агент не следует принятому в репозитории подходу, его изменение могут отклонить. В небольшом личном проекте без установленных правил это может быть менее существенно, но в командной работе становится важным.
• Тесты сами по себе не обеспечивают безопасность. Приведённые выше показатели исследования показывают, что функциональная корректность не гарантирует безопасного решения. Проверяйте риски отдельно, в том числе токены, файлы .env и стандартные пароли.
• Агент может изменить больше, чем просили. Например, запрос на исправление функции авторизации может привести к переписыванию внутреннего слоя и логирования. Контроль объёма правок — один из шести критериев FrontierCode.

Какие шесть типов ошибок встречаются в сложных задачах?#

Рассмотрим каждый критерий на примерах:

1. Поведенческая корректность (Behavioral correctness) — решена ли задача.

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

2. Защита от регрессий (Regression safety) — не сломалось ли что-то ещё.

Изменение одного модуля может нарушить работу другого. Типичный пример — агент меняет сигнатуру функции, не учитывая, что её вызывают ещё в 17 местах. Если тестирование ограничено одним файлом, проблему легко пропустить. FrontierCode запускает весь набор тестов репозитория.

3. Техническая чистота (Mechanical cleanliness) — проходит ли код сборку, линтеры и проверки стиля.

Код может компилироваться локально, но завершить проверку CI с ошибкой: не хватает импорта, вместо пробелов использованы табы, в строке остались лишние пробелы или возникла проблема в eslint.config.js. В действующем проекте соглашения о стиле — часть командных правил.

4. Корректность тестов (Test correctness) — проверяют ли тесты, написанные ИИ, нужное поведение.

Этот критерий легко упустить. Тест может пройти, но пройти на любом варианте кода, в том числе на сломанном. Например, он проверяет только то, что скрипт завершился без ошибки, но не то, что результат верен. Проверка Reverse-Classical в FrontierCode предназначена для обнаружения таких случаев.

5. Границы изменений (Scope) — ограничился ли патч нужными файлами.

Вместо исправления одной функции агент может изменить 12 файлов, не связанных с задачей. Такие непрошеные правки способны нарушить работу проекта. FrontierCode считает соблюдение заданных границ отдельным обязательным критерием.

6. Качество кода (Code quality) — соблюдены ли соглашения репозитория.

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

Как проверять ИИ-код перед отправкой: пять шагов#

1. Запустите полный набор тестов, а не только проверки изменённого участка

   ИИ может затронуть код за пределами запроса, поэтому проблема способна проявиться в соседних тестах. Запускайте весь набор одной командой npm test, не указывая путь к отдельному файлу. В крупных проектах тесты можно выполнять параллельно в git worktree (см. Git worktree в Claude Code).

2. Запустите линтер, проверку стиля и проверку типов

   Последовательно выполните три команды: eslint ., prettier --check ., tsc --noEmit. Агент может оставить табы, лишний пробел в конце строки или другую ошибку форматирования. Если проект использует строгие правила, проверяйте изменения локально до публикации.

3. Убедитесь, что тест действительно обнаруживает ошибку

   Для быстрой проверки временно внесите небольшую поломку, например замените return true на return false. Тест должен завершиться с ошибкой. Если он не проваливается, значит, тест не проверяет нужное поведение. Удалите его и попросите ИИ переписать проверку с условием, что она должна падать на сломанной версии.

4. Посмотрите, какие файлы изменил агент

   Команда git diff --stat показывает перечень изменённых файлов и количество строк. Если на просьбу поправить форму обратной связи агент затронул 12 файлов, это может быть выходом за рамки запроса. Откатите лишние изменения для конкретных файлов.

5. Проверьте безопасность

   Тесты могут не выявить SQL-инъекцию или пароль, записанный прямо в коде. Используйте доступные средства анализа безопасности для Claude Code. Вручную как минимум найдите в проекте слова password, secret и key, а также проверьте, что .env.example содержит все нужные параметры.

Эти пять шагов охватывают пять критериев FrontierCode — с первого по пятый. Шестой критерий, качество кода, оценивается линтерами и проверкой человеком.

Как повысить вероятность того, что ИИ-код примут?#

Без предварительной подготовки ИИ-агент обычно видит только те файлы, которые ему передали. Он может не знать историю решений, принятые соглашения и устройство модулей. На простых правках это не всегда мешает, но сложные изменения требуют более полного контекста.

Чтобы агент лучше учитывал требования проекта, подготовьте следующее:

1. Правила проекта — чтобы агент применял ваши принципы, а не усреднённые советы.

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

2. Карта проекта — папка с описанием структуры и контекста.

В неё можно включить сведения о продуктах, аудитории, экономике, метриках и взаимосвязях. Если агент читает оглавление и нужные разделы перед работой, ему проще определить, к какой части проекта относится запрос. Это также помогает соблюдать стиль и избегать несвязанных изменений.

3. Управление контекстом — решите, что агент увидит до получения задачи.

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

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

Дополнительный способ — разделить написание и проверку между агентами:

• Cursor Bugbot — инструмент Cursor для автоматической проверки PR. По данным Cursor, он обрабатывает около двух миллионов PR в месяц.
• Вложенные субагенты в Claude Code v2.1.172 — один агент может писать код, другой проверять его, третий запускать тесты. Такое разделение ролей помогает отделить создание решения от технической проверки.

См. также: Безопасность вайб-кодинга, Как настроить Claude Code, чтобы он не сломал ваш проект ночью, а также материалы о контекст-инжиниринге.

О дополнительных материалах по работе с инструментами читайте в документации Ailoot.