# FrontierCode Diamond: 13,4% патчей для слияния на 50 трудных задачах (июнь 2026) > Результаты FrontierCode июня 2026 года: 13,4% на 50 трудных задачах Diamond и 51,8% на Extended. Как проверять патч ИИ перед слиянием. Source: https://ailoot.ai/blog/ru/frontiercode-benchmark-mergeable-ai-code/ Canonical: https://ailoot.ai/blog/ru/frontiercode-benchmark-mergeable-ai-code/ Language: ru Publisher: Ailoot (https://ailoot.ai/) Translation: guide-173 Revision: sha256-86903188631747ed08179f1fcf45cc9ae4d4e4a3a029f8ca8a042469b5a4d6ab
Коротко о главном 8 июня 2026 года Cognition представила FrontierCode — бенчмарк, который проверяет, согласится ли сопровождающий открытый репозиторий мейнтейнер принять и слить код, созданный ИИ. Результат показателен: даже Claude Opus 4.8, сильнейшая модель в опубликованном сравнении, решила лишь 13,4% из 50 самых трудных задач. Прежние бенчмарки вроде HumanEval и SWE-bench проверяли, работает ли решение по тестам; FrontierCode оценивает, одобрит ли его мейнтейнер. Для тех, кто использует ИИ-код в продакшене, это меняет критерий готовности.
Дополнительные рекомендации по работе с инструментами доступны в [документации Ailoot](https://ailoot.ai/docs/).
[Руководства Ailoot](https://ailoot.ai/docs/)
## Что такое FrontierCode и чем он важен?
Коротко о главном FrontierCode — бенчмарк Cognition для оценки кода, созданного ИИ, опубликованный 8 июня 2026 года. Он оценивает соответствие патча критериям слияния, ориентированным на мейнтейнера. Это заданный результат бенчмарка, а не общая доля всего ИИ-кода, готового к продакшену. Более 20 мейнтейнеров крупных проектов с открытым исходным кодом потратили свыше 40 часов на каждую задачу, чтобы подготовить примеры, где важны не только корректность, но также стиль, безопасность и качество тестов.
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?
Коротко о главном 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» адаптирует строгие тесты так, чтобы они допускали корректные варианты реализации. ## Почему прежних бенчмарков недостаточно?
Коротко о главном HumanEval (Codex, 2021) и SWE-bench проверяют прохождение автоматических тестов. Они не выявляют ситуации, когда тесты зелёные, но патч не принимают: например, из-за плохого стиля, поломки соседних модулей или выхода за рамки запроса. В марте 2026 года независимое исследование рассмотрело 296 сгенерированных ИИ PR из SWE-bench Verified вместе с четырьмя действующими мейнтейнерами. Их оценки возможности слияния в среднем были на 24 процентных пункта ниже результатов автоматического оценщика. Следовательно, заметная часть PR, признанных успешными бенчмарком, может не пройти проверку в реальном репозитории.
К 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%
Коротко о главном Cognition опубликовала результаты 12 моделей на трёх поднаборах. В Diamond лидирует Claude Opus 4.8 от Anthropic с результатом 13,4%. За ней следуют GPT-5.5 — 6,3%, Claude Opus 4.7 — 5,2% и Gemini 3.1 Pro от Google — 4,7%. Лучший результат среди моделей с открытым кодом у Kimi K2.6 от Moonshot — 3,8%. Собственная модель Cognition SWE-1.6 получила 2,5% и оказалась ближе к концу таблицы.
| Модель | Diamond (50) | Main (100) | Extended (150) | |---------------------------------|--------------|------------|----------------| | **Claude Opus 4.8** (Anthropic) | **13.4%** | 34.3% | 51.8% | | GPT-5.5 (OpenAI) | 6.3% | \- | \- | | Claude Opus 4.7 (Anthropic) | 5.2% | \- | \- | | Gemini 3.1 Pro (Google) | 4.7% | \- | \- | | GPT-5.4-mini (OpenAI) | 4.6% | \- | \- | | Kimi K2.6 (лучшая модель с открытым кодом) | 3.8% | \- | \- | | Claude Sonnet 4.6 | 3.5% | \- | \- | | **SWE-1.6** (Cognition) | **2.5%** | \- | \- | | MiniMax M2.7 | 2.4% | \- | \- | | MiniMax M2.5 | 1.1% | \- | \- | | Kimi K2.5 | 1.0% | \- | \- | | Gemini 3.1 Flash Lite | 0.7% | \- | \- | Из результатов можно сделать несколько наблюдений: - **Отрыв лидера заметен.** 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?
Коротко о главном В опубликованном запуске Opus 4.8 на 50 отобранных трудных задачах Diamond 13,4% патчей прошли критерии слияния, а 86,6% — нет. Это не устанавливает, что все отклонённые патчи выглядели правильными или что та же доля действует в обычной проектной работе. Для сложных изменений одного зелёного теста недостаточно.
Важно учитывать, что FrontierCode Diamond состоит из специально отобранных задач высокой сложности. В новом проекте с небольшим числом зависимых модулей агент может справляться заметно лучше. Для Opus 4.8 результат на Extended, включающем все 150 задач, составляет 51,8% пригодных к слиянию. Результат 51,8% относится к набору Extended из 150 задач. Он выше Diamond, но ни одна цифра не оценивает пригодность патчей всех моделей в ваших задачах. Отсутствующие оценки Main или Extended других моделей не позволяют приписать им результат. Практические выводы для тех, кто использует ИИ при разработке: - **Успешные тесты ещё не означают, что код готов к слиянию.** Тесты, созданные самим ИИ, могут проходить и на неверном коде. FrontierCode проверяет это подходом Reverse-Classical: тест должен провалиться на сломанном варианте. - **Стиль и соглашения проекта влияют на решение.** Если агент не следует принятому в репозитории подходу, его изменение могут отклонить. В небольшом личном проекте без установленных правил это может быть менее существенно, но в командной работе становится важным. - **Тесты сами по себе не обеспечивают безопасность.** Приведённые выше показатели исследования показывают, что функциональная корректность не гарантирует безопасного решения. Проверяйте риски отдельно, в том числе токены, файлы `.env` и стандартные пароли. - **Агент может изменить больше, чем просили.** Например, запрос на исправление функции авторизации может привести к переписыванию внутреннего слоя и логирования. Контроль объёма правок — один из шести критериев FrontierCode.
[Руководства Ailoot](https://ailoot.ai/docs/)
## Какие шесть типов ошибок встречаются в сложных задачах?
Коротко о главном Шесть критериев 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/` агент может написать собственную реализацию, выбрать непривычный способ именования переменных или поместить логику не в тот архитектурный слой. Тесты могут проходить, но мейнтейнер всё равно решит не принимать такой код. ## Как проверять ИИ-код перед отправкой: пять шагов
Коротко о главном Пять проверок ниже помогают оценить критерии FrontierCode и отдельно уделить внимание безопасности. Применяйте этот список к каждому патчу перед публикацией. Проверки короткие, а раннее обнаружение проблем помогает избежать длительного отката и восстановления проекта из резервной копии.
1. ### Запустите полный набор тестов, а не только проверки изменённого участка ИИ может затронуть код за пределами запроса, поэтому проблема способна проявиться в соседних тестах. Запускайте весь набор одной командой `npm test`, не указывая путь к отдельному файлу. В крупных проектах тесты можно выполнять параллельно в git worktree (см. [Git worktree в Claude Code](https://ailoot.ai/blog/ru/claude-code-git-worktree/)). 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 — с первого по пятый. Шестой критерий, качество кода, оценивается линтерами и проверкой человеком. ## Как повысить вероятность того, что ИИ-код примут?
Коротко о главном FrontierCode показывает проблему, а на результат работы с ИИ влияют подготовка проекта и передаваемый агенту контекст. Полезно заранее описать проектные правила, составить карту проекта и выбрать нужные сведения для контекста запроса. Это помогает агенту точнее учитывать требования, но не гарантирует определённый результат бенчмарка.
Без предварительной подготовки ИИ-агент обычно видит только те файлы, которые ему передали. Он может не знать историю решений, принятые соглашения и устройство модулей. На простых правках это не всегда мешает, но сложные изменения требуют более полного контекста. Чтобы агент лучше учитывал требования проекта, подготовьте следующее: **1. Правила проекта — чтобы агент применял ваши принципы, а не усреднённые советы.** Соберите принятые решения, рабочие привычки и усвоенные правила в инструкции, которые агент получает при каждом запросе. Когда таких правил становится больше, они помогают агенту придерживаться вашего подхода и не предлагать типовой вариант без учёта проекта. Например, зафиксируйте: «не изменяй файлы за пределами тех, которые прямо указаны в запросе». **2. Карта проекта — папка с описанием структуры и контекста.** В неё можно включить сведения о продуктах, аудитории, экономике, метриках и взаимосвязях. Если агент читает оглавление и нужные разделы перед работой, ему проще определить, к какой части проекта относится запрос. Это также помогает соблюдать стиль и избегать несвязанных изменений. **3. Управление контекстом — решите, что агент увидит до получения задачи.** Важно не только формулировать запрос, но и заранее предоставлять необходимые сведения: например, инструкции `CLAUDE.md`, предварительные условия и точные ссылки на файлы. Правильно подобранный контекст помогает точнее реализовать требуемое поведение и соблюдать стандарты кода. Эти приёмы помогают агенту учитывать условия задачи и лучше ориентироваться в проекте. Они не делают результат автоматически пригодным к слиянию: изменения всё равно нужно проверять. Дополнительный способ — разделить написание и проверку между агентами: - **Cursor Bugbot** — инструмент Cursor для автоматической проверки PR. По данным Cursor, он обрабатывает около двух миллионов PR в месяц. - **Вложенные субагенты в Claude Code v2.1.172** — один агент может писать код, другой проверять его, третий запускать тесты. Такое разделение ролей помогает отделить создание решения от технической проверки. См. также: [Безопасность вайб-кодинга](https://ailoot.ai/blog/ru/vibe-coding-security/), [Как настроить Claude Code, чтобы он не сломал ваш проект ночью](https://ailoot.ai/blog/ru/claude-code-safe-overnight-setup/), а также материалы о контекст-инжиниринге.
### Источники - [Cognition — Introducing FrontierCode (8 июня 2026)](https://cognition.com/blog/frontier-code) - [Cursor Bugbot — инструмент для проверки кода](https://cursor.com/bugbot)
О дополнительных материалах по работе с инструментами читайте в [документации Ailoot](https://ailoot.ai/docs/).
[Руководства Ailoot](https://ailoot.ai/docs/)
[Перейти на Ailoot](https://ailoot.ai/)
## Вопросы и ответы ### Означают ли 13,4%, что только такая доля всего ИИ-кода готова к продакшену? Нет. Это опубликованный результат пригодности к слиянию Opus 4.8 на 50 отобранных трудных задачах FrontierCode Diamond. Та же таблица даёт 51,8% на Extended из 150 задач. Ни одна доля не измеряет весь созданный ИИ код. ### Почему успешного теста недостаточно для слияния патча? Бенчмарк также проверяет регрессии, сборку и стиль, обнаружение тестами сломанной реализации, границы правки и качество кода. Изучите настоящий diff и выполните проверки репозитория. Один зелёный тест не подтверждает всех условий. ## Ailoot · Компания и портфель её проектов Ailoot опирается на накопленный опыт работы, большую клиентскую базу, стабильный сервис и постоянный контроль KPI. Компания и портфель её проектов: миллионы клиентов; продажи на миллиарды ежемесячно. Этот опыт Ailoot использует для API-доступа к нейросетям в продуктах клиентов, агентах, приложениях и автоматизациях.