Только 13% ИИ-кода готов в прод: бенчмарк FrontierCode (июнь 2026)

Каждый день в Telegram-канале - что нового в вайб-кодинге: инструменты, кейсы, ошибки. Подпишись, чтобы быть в курсе.

Что такое FrontierCode и почему о нём заговорил весь твиттер про вайб-кодинг?

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

Бенчмарк сразу разошёлся: новость подхватила Latent Space, BenchLM собрал свой лидерборд, на Hacker News появился оживлённый тред с разбором методологии. Главный поворот - не про новые цифры. А про то, по какой линейке вообще теперь меряют.

Структура бенчмарка - три уровня сложности: Extended (150 задач, полный набор), Main (100 самых сложных, включая Diamond) и Diamond (50 хардкорных). Diamond Cognition специально оставила «largely unsaturated» - даже лучшая модель решает меньше 15%. Это сделано чтобы у бенчмарка был запас на год вперёд и его не насытили за месяц, как HumanEval.

Что измеряет FrontierCode: «смержил бы мейнтейнер этот PR?»

Шесть осей оценки (из официального блога Cognition):

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

Чтобы патч считался mergeable, должны пройти все шесть осей. Провалил хоть одну - не сольют.

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

Cognition ввела три новых техники для grading'а:

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

Почему старые бенчмарки больше не работают?

ИИ-агенты прошли HumanEval насквозь ещё в 2024-м. SWE-bench Verified - почти то же самое: в августе 2025 OpenAI публично признали проблему контаминации (модели «видели» датасет на тренировке). Бенчмарки потеряли способность дифференцировать топ-модели.

Главное исследование, которое подложило мину под старую линейку - это METR, март 2026. Их статья называется «Many SWE-bench-Passing PRs Would Not Be Merged into Main».

Что они сделали:

• Взяли 4 активных мейнтейнеров из 3 репозиториев (scikit-learn, Sphinx, pytest).
• Прогнали через них 296 ИИ-сгенерированных PR из SWE-bench Verified - все эти PR прошли автотесты.
• Сравнили решения мейнтейнеров и автоматического оценщика.

То есть бенчмарк говорит «прошло», мейнтейнер говорит «не сольёт» - и так в среднем на четверть кейсов. Топ-3 причины отказа от менее серьёзной к более серьёзной:

1. Code quality - не соответствует стилю репо.
2. Breaks other code - ломает соседнее.
3. Core functionality failure - не решает задачу полностью, хоть тест и зелёный.

FrontierCode - формализация именно этой проблемы. Cognition взяла идею METR и развернула в полноценный бенчмарк с 20+ мейнтейнерами вместо 4.

Дополнительный гвоздь - исследование Carnegie Mellon SUSVIBES (декабрь 2025).

Код проходит тест, и при этом каждый второй патч приносит дыру безопасности. На бэнчмарках SWE-bench это не видно вообще - они не меряют безопасность. FrontierCode её хотя бы пытается ловить через ось «mechanical cleanliness» и code quality.

Кто на каком месте: Opus 4.8 - 13.4%, GPT-5.5 - 6.3%

Что вытаскивается из таблицы:

• Лидер один. Anthropic Opus 4.8 примерно вдвое впереди ближайшего конкурента. Тот разрыв, который был на SWE-bench незаметным, на FrontierCode уже видно глазом.
• Открытые модели пока не догнали. Kimi K2.6 - лучшая модель с открытым кодом - даёт 3.8% на Diamond. Это в 3-4 раза ниже Opus 4.8. Cognition не публиковала полную сетку Kimi K2.6 на Main и Extended, поэтому по полному набору пока сравнения нет.
• Cognition честно отдала свою модель в нижнюю часть таблицы. На Hacker News прямо это отметили.

Подсетка Diamond специально оставлена «не насыщенной». Cognition закладывала запас прочности на годы вперёд. Если предыдущие бенчмарки насыщали за 12-18 месяцев, у FrontierCode заявлен потолок выше.

Что значит «13% mergeable» для вайб-кодера в Claude Code?

Сначала важный разворот: FrontierCode - это Diamond, специально хардкорные задачи. На обычных задачах в свежем стартап-проекте, без сорока зависимых модулей, ИИ-агент справляется заметно лучше. Тот же Opus 4.8 на Extended (150 задач, полный набор) даёт 51.8% mergeable. Это уже совсем другая картина.

Но даже эти 51.8% на Extended - это про то, что каждый второй патч от лучшей модели на типичных задачах живой техлид не возьмёт в свой проект без правок. У средней модели картина хуже. У моделей с открытым кодом - ещё хуже.

Что отсюда следует для вайб-кодера, который пушит в прод:

• Зелёный тест больше не равен «готово к слиянию». Тесты, написанные самим ИИ, могут быть пустышкой - они проходят на любом коде. FrontierCode прямо это меряет через Reverse-Classical: если тест не падает на сломанной версии, он не считается.
• Стиль и конвенции репо имеют вес. Если у проекта есть привычный паттерн, и ИИ его не повторил - живой соавтор не примет. В одиночных проектах, где правил нет, это не страшно. В работе с командой - проблема номер один.
• Безопасность не лечится тестами. Помнишь цифру CMU: только 10.5% патчей безопасны при 61% корректных. Это нужно проверять отдельно, инструменты которые ловят токены, .env, стандартные пароли.
• Выход за рамки задачи - типовая ошибка ИИ. Просишь поправить функцию авторизации - получаешь патч, который заодно переписал внутренний слой и логирование. Это одна из 6 осей FrontierCode.

Я сам это видел много раз. Один из участников прошлого потока попросил ИИ «починить форму обратной связи» в своём проекте по аренде недвижимости. Получил патч на 800 строк, который заодно поменял схему базы. Зелёные тесты прошли - они касались только формы. Боевой сайт упал через два часа, когда новая схема базы встретилась со старой админкой. С этого момента у нас в практикуме появилось отдельное правило про границы запроса.

Хочешь собрать связку, которая выводит ИИ из режима «правдоподобный мусор» в режим «готов к слиянию»? FrontierCode показывает проблему, методология её решает. На практикуме за 3 эфира собираешь все три кита: ИИ-клон + Второй мозг + Контекст-инжиниринг. Та самая связка, без которой ИИ-агент пишет красиво, но мимо.

Практикум по вайб-кодингу

+Твой второй мозг

3 вечера - стек, метод, первый проект

Старт 23–25 июня  ·  2 000 ₽

Записаться →

Какие 6 категорий ошибок делает ИИ на сложных задачах?

Разберём каждую ось по-человечески:

1. Behavioral correctness - решает ли патч задачу.

Самая базовая ось. ИИ часто пишет код, который выглядит как решение, но решает не ту задачу. Прошу «добавить отметку прочитанности у сообщения» - получаю функцию markAsRead, но в сам компонент чата её не подключили. Тест на функцию проходит. Бизнес-задача не решена.

2. Regression safety - не ломает ли соседнее.

ИИ изменил один модуль, и теперь не работает другой. Самый частый случай: ИИ-агент меняет сигнатуру функции, забывая что её зовут из 17 других мест. На SWE-bench это не видно - там запускают тесты только на один файл. На FrontierCode прогоняют полный набор тестов репозитория.

3. Mechanical cleanliness - проходит ли сборку, линт, стиль.

ИИ может выдать код, который компилируется локально, но валится в CI: пропущен импорт, табы вместо пробелов, два пустых пробела в конце строки, прокол в eslint.config.js. У живого проекта стиль - не каприз, а правило команды.

4. Test correctness - валидны ли тесты, написанные ИИ.

Самая хитрая ось. ИИ пишет тест, который проходит. Но проходит на любом коде, включая сломанный. Я видел это много раз - тест проверяет «не упал ли скрипт», но не «вернул ли правильный результат». Reverse-Classical у FrontierCode ловит именно такой случай.

5. Scope - не лезет ли патч в чужие файлы.

Прошу починить одну функцию - получаю патч на 12 файлов, в том числе в файлах, которые не имеют отношения к задаче. Это та самая «инициатива ИИ», которая ломает боевой проект, потому что меняет вещи, которые я не просил. У FrontierCode эта ось блокирующая.

6. Code quality - следует ли код конвенциям репо.

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

Как проверять ИИ-код перед пушем: 5 шагов

1. Прогнать весь набор тестов, не только по теме правки

   ИИ часто меняет код за пределами задачи. Проблема всплывёт в соседних тестах. Я запускаю прогон тестов целиком (одной командой npm test без пути), а не только по конкретному файлу. На крупных проектах удобно делать это параллельно через git worktree (см. Git worktree в Claude Code).

2. Прогнать линт, стиль и проверку типов

   Три команды по очереди: eslint ., prettier --check ., tsc --noEmit. ИИ-агент может пропустить и табы, и лишний пробел в конце строки. Если у проекта в проверке стоят жёсткие правила - прогон локально до публикации.

3. Проверить тест на самом тесте

   Самая важная проверка из 5. Я делаю маленькую «поломку» в коде (меняю return true на return false). Тест должен упасть. Если тест не падает - его писал ИИ для галочки, и он бессмысленный. Удаляю тест и прошу ИИ переписать с обязательным условием: тест должен падать на сломанной версии.

4. Посмотреть, в какие файлы влез ИИ

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

5. Прогнать проверку безопасности через готовый скилл

   Тесты не ловят SQL-инъекции и захардкоженные пароли. Я использую готовый скилл безопасности для Claude Code (см. 754 готовых навыка безопасности). Минимум руками - поиск по проекту слов «password», «secret», «key» в коде и проверка .env.example на полноту.

Все 5 шагов закрывают 5 из 6 осей FrontierCode (1-5). Шестая ось - code quality - проверяется автоматически через линт + ревью человека.

Я сам разбирал этот сюжет на эфире про безопасность: участник из ниши интернет-торговли получил «безобидный» патч от ИИ, который заодно обнулил админскую панель оплат. Сервер был со стандартным паролем от базы, прокинутый наружу, ИИ узнал об этом из README. Итог - майнеры на сервере, удаление виртуальной машины, восстановление из резервной копии. Шаг номер пять в этом списке у меня стоит 10 минут, а спасает день.

Что реально повышает шансы на mergeable код?

ИИ-агент в проекте без подготовки видит только сам файл, который ты ему открыл. У него нет твоей истории решений, нет твоих конвенций, нет твоей карты модулей. На простых правках это не страшно. На сложных - выливается в те самые «13% Diamond». То есть в правдоподобный, но не mergeable код.

Что нужно сделать, чтобы превратить эти 13% в нечто, что реально пушится в прод:

1. ИИ-клон - чтобы ИИ воспроизводил твою логику, а не среднюю из интернета.

Это набор твоих готовых решений, привычек, выученных правил - в формате, который ИИ-агент читает каждый запрос. У меня это в ai-clone/feedback/ и ai-clone/principles/. Когда правил 30+, ИИ перестаёт изобретать «средний по индустрии» и предлагает в твоём стиле. Выход за рамки задачи лечится одной строкой в правилах: «не трогай файлы за пределами явно названных в запросе».

2. Второй мозг - папка business/ с картой проекта.

Сюда складываются: продукты, аудитория, экономика, метрики, связки. ИИ-агент перед каждым запросом читает оглавление и понимает, в какую часть бизнеса он сейчас лезет. Это автоматически снимает 3-ю и 4-ю причины отказа из METR (стиль и breaks other code).

3. Контекст-инжиниринг - управление тем, что ИИ видит до запроса.

Не «как сформулировать промпт», а «что положить в окно контекста ДО промпта». CLAUDE.md, prerequisites, прицельные ссылки на файлы. Это снимает behavioral correctness fails и code quality fails.

Связка работает как фильтр: ИИ-агент сам отказывается писать код, который не пройдёт FrontierCode по 5 из 6 осей. Не потому что модель умнее. Потому что у неё на входе достаточно сигнала, чтобы понять контекст задачи.

Дополнительный слой - ревью-агенты:

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

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

Полная схема по вайб-кодингу за вечер: ИИ-клон + Второй мозг + Контекст-инжиниринг. 3 эфира, 2 000 ₽. Записи остаются у тебя.

Практикум по вайб-кодингу

+Твой второй мозг

3 вечера - стек, метод, первый проект

Старт 23–25 июня  ·  2 000 ₽

Записаться →

Новые материалы - дайджестом, без спама

Гайды выходят регулярно. Подпишись, чтобы не пропускать: пришлю подборку в Telegram или на email. Раз в неделю или каждый день - выбираешь сам.

Подписаться в Telegramили на email