Cursor поставил под сомнение публичные AI-бенчмарки для кода с помощью пяти графиков

11 марта 2026 года Cursor опубликовал объяснение того, как сравнивает модели внутри продукта, и этим неожиданно ударил по всей индустрии AI-бенчмарков для кода. Вместо очередной таблицы лидеров компания показала, почему привычные проценты решённых задач всё хуже описывают реальную пользу для разработчика.

Почему графики важны

Первый вывод Cursor очень практичный: модель для программирования нельзя оценивать только по доле решённых задач. Компания показала график, где рядом стоят две величины - корректность ответа и медианное число токенов на завершение. Для пользователя это не абстракция.

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

Второй удар пришёлся по самой идее «стабильного» теста. CursorBench собирают из реальных сессий через систему Cursor Blame, которая связывает закоммиченный код с запросом к агенту. По данным Cursor, от первой версии к CursorBench-3 масштаб задач примерно удвоился и по объёму кода, и по среднему числу файлов.

Это означает, что разработчики уже просят AI не только чинить маленькие баги, но и тянуть более длинные, размазанные по проекту задачи. На этом фоне замороженные наборы вроде SWE-bench всё быстрее стареют, даже если их результаты формально воспроизводимы.

Пять слабых мест

Если собрать выводы из пяти графиков в одну рамку, получается не реклама внутреннего бенчмарка, а критика всей текущей системы оценки coding-моделей. Cursor фактически говорит: индустрия привыкла мерить то, что удобно посчитать, а не то, что реально ощущает разработчик в редакторе, терминале и длинной рабочей сессии.

• Рейтинг по одной метрике скрывает компромисс между качеством, скоростью и ценой ответа.
• Замороженный набор задач устаревает, пока реальные запросы к агентам становятся длиннее и сложнее.
• Длинные issue с короткими патчами проверяют следование инструкции, а не понимание расплывчатого намерения.
• Слипшиеся результаты у топовых моделей не помогают выбрать инструмент для продакшена.
• Офлайн-баллы мало значат, если они не коррелируют с тем, как модель ведёт себя в реальном продукте.

Как устроен

CursorBench Подход Cursor отличается не только набором задач, но и тем, что именно считается хорошей проверкой. В публичных бенчмарках разработчик часто получает длинное описание бага и делает короткий точечный фикс. В CursorBench картина обратная: описания короче, а решения длиннее.

Это ближе к живой работе, когда человек пишет агенту что-то вроде «почини логин» или «отрефактори пайплайн», а дальше модель сама должна понять контекст репозитория, выбрать стратегию и внести заметные изменения в несколько файлов. То есть проверяется не только аккуратность, но и умение достраивать намерение. Отсюда вытекает ещё один важный эффект: CursorBench лучше разводит результаты моделей на фронтире.

Там, где публичные тесты начинают показывать почти одинаковые баллы и даже ставят более слабые модели рядом с сильными, внутренний набор Cursor сохраняет различия, которые совпадают с опытом пользователей. Компания дополняет офлайн-оценку контролируемыми онлайн-экспериментами на живом трафике и смотрит не на одну цифру, а на набор сигналов - качество результата, поведение агента и полезность для разработчика. Если офлайн-грейдер считает ответ корректным, но пользователю с ним хуже работать, такая деградация всё равно всплывает.

Что это значит История важна не только для пользователей Cursor.

Она показывает, что рынок coding-агентов вошёл в этап, где синтетические таблицы лидеров перестают быть надёжным ориентиром, особенно при выборе между лучшими моделями. Следующая волна конкуренции будет не за самый громкий benchmark score, а за баланс между качеством, скоростью, стоимостью и тем, насколько уверенно агент справляется с реальной, неидеально сформулированной инженерной задачей.