Дайте современному AI-агенту чёткое техническое задание — и он напишет рабочий код. Но дайте ему сырой RFC-документ из Kubernetes или Rust — и он пропустит больше половины критических проблем. Новый бенчмарк SpecBench измеряет именно это: способность агентов находить дефекты в спецификациях до первой строчки кода. Лучший результат среди всех протестированных систем — 44,4% у GPT-5.4. Это означает, что даже передовые агенты не видят более половины ошибок, которые эксперты-сопровождающие находят за минуты.

Что такое SpecBench

SpecBench — это бенчмарк для оценки specification-level reasoning, способности агента генерировать полные, однозначные, согласованные и корректные системные спецификации. В отличие от SWE-Bench, который проверяет умение писать код по готовому заданию, SpecBench проверяет умение думать до кодирования.

Каждая задача в бенчмарке построена на реальных RFC-процессах из пяти крупных open-source проектов: Kubernetes, React, Rust, TVM и vLLM. Агенту даётся начальный дизайн-предложение, кодовая база проекта и вся история предыдущих RFC-обсуждений. Задача — найти дефекты спецификации: пропуски, двусмысленности, несогласованности или некорректные предположения. Ответы сравниваются с замечаниями, которые реальные мейнтейнеры оставляли во время исторических обсуждений.

Почему это важнее, чем писать код

Существующие бенчмарки вроде SWE-Bench, TerminalBench и LiveCodeBench измеряют implementation-level reasoning — умение генерировать код по точной спецификации. Они предполагают, что техническое задание идеально. В реальности это редкость. В сложных системах начальные спецификации почти всегда неполны и содержат ошибки. Именно поэтому в зрелых open-source проектах существует процесс Request for Comments: эксперты просматривают предложение, находят проблемы и требуют доработки до начала реализации.

SpecBench выделяет четыре ключевых свойства, которые отличают specification reasoning от обычного кодирования:

Реальное проектирование. Задачи основаны на реальных RFC из Kubernetes, React, Rust, TVM и vLLM. Это не синтетические тесты, а решения, которые формировали долгосрочную архитектуру проектов.

Соответствие ценностям сообщества. Разные open-source сообщества приоритизируют разные вещи: Rust требует строгости в безопасности памяти, React — стабильности API. Агент должен понимать не просто программирование, а философию конкретного сообщества.

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

Долгосрочное рассуждение. Поиск дефектов требует понимания логики кода, системных инвариантов и лет истории архитектурных решений.

Как устроен бенчмарк

Каждая задача включает три компонента: начальный RFC-документ, кодовую базу проекта на момент подачи RFC и историю всех предыдущих RFC с их обсуждениями. Агент не имеет доступа к интернету или Git-истории после даты подачи RFC.

Дефекты классифицируются по четырём категориям, основанным на стандарте IEEE Std. 1028-1997:

Omission — необходимая информация отсутствует в предложении. Например, RFC про gang scheduling в Kubernetes не описывал, что происходит при перезапуске планировщика, хотя вся координация gang хранится в оперативной памяти.

Ambiguous — информация допускает более одной интерпретации. Например, неясно, когда именно запускается таймаут SchedulingTimeoutSeconds и какие действия выполняются при его истечении.

Inconsistent — одна часть предложения противоречит другой или существующей системе. Например, RFC утверждал, что существующие контроллеры работают без изменений, но при этом требовал нового поля spec.workload в Pod, которое никакой контроллер не устанавливает.

Incorrect — информация противоречит другим документам или фактам. Например, утверждение, что при таймауте все поды освобождают ресурсы, невыполнимо в реальном kube-scheduler, где часть подов может уже быть забиндена или запущена.

Результаты: лучший агент — 44,4%

Авторы протестировали ведущие агенты: Codex-5.4, Claude Code (Sonnet 4.6, Extended Thinking) и Gemini CLI. Результаты показывают, что все системы остаются ниже 45% точности при ограниченном бюджете предсказаний.

GPT-5.4 (Codex-5.4) показал лучший результат — 44,4%. Два Claude-агента достигли схожих показателей. На core-дефектах, отражающих высокий консенсус экспертов, все агенты справлялись лучше, чем на extended-дефектах. Это логично: core-элементы представляют общепризнанные проблемы, тогда как extended — более тонкие замечания отдельных рецензентов.

Интересно распределение по репозиториям. Codex-5.4 показал наибольший отрыв в React (+9,5% к ближайшему конкуренту) и vLLM (+8,6%). В Kubernetes и Rust разрыв между агентами меньше, что может говорить о большей сложности спецификаций в этих проектах.

Кейс: Kubernetes RFC 5558 и 19 промахов GPT-5.4

Один из самых показательных примеров — RFC 5558 о gang scheduling в Kubernetes. Golden set содержит 15 дефектов, выявленных мейнтейнерами. GPT-5.4 предсказал 19 дефектов, но совпал с golden set только по 7 из 11 core-элементов. При этом агент нашёл 12 дополнительных проблем, которые эксперты не зафиксировали в историческом обсуждении.

Что GPT-5.4 не увидел из core-дефектов:

Мейнтейнеры указали, что статус WorkloadStatus оставлен как TBD, хотя статус критически важен для наблюдаемости. Агент это пропустил.

Эксперты отметили, что семантика привязки подов к PodGroup не определена — агент не зафиксировал эту проблему.

Рецензенты потребовали явного перечисления поддерживаемых ограничений планирования внутри gang scheduling. Агент об этом не упомянул.

Что GPT-5.4 нашёл дополнительно:

Агент обнаружил, что RFC предлагает продвинуть gang scheduling прямо в core API Kubernetes, минуя CRD-подход, который предыдущий coscheduling KEP считал необходимым. Это архитектурное решение с серьёзными последствиями для совместимости.

Он указал на внутренние противоречия в описании контроллеров: RFC утверждает, что существующие контроллеры работают без изменений, но при этом требует поля spec.workload, которое никто не устанавливает.

Он заметил, что selector-based ассоциация PodGroup открывает ранее идентифицированную проблему масштабируемости, которую старый KEP явно отверг.

Это показывает двустороннюю природу проблемы: агенты могут находить проблемы, которые люди пропустили, но при этом упускают очевидные для экспертов дефекты.

Почему агенты так плохо справляются

Есть несколько фундаментальных причин, почему specification reasoning оказывается сложнее implementation reasoning:

Нет обратной связи. В SWE-Bench агент пишет код, запускает тесты и видит, проходит ли решение. В SpecBench нет тестов. Агент должен полагаться только на анализ текста и архитектурное понимание.

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

Экспертный консенсус сложен. Один эксперт может фокусироваться на производительности, другой — на обратной совместимости. Агент должен уловить, какие проблемы сообщество считает критическими, а какие — второстепенными.

Открытый мир. Пространство валидных спецификационных проблем открыто. Невозможно перечислить все возможные дефекты. Агент может найти валидную проблему, которой не было в историческом обсуждении, и мы не можем сказать, что он неправ.

Что дальше

Авторы SpecBench планируют расширить бенчмарк в нескольких направлениях. Первое — добавить задачи на исправление дефектов, а не только их поиск. Второе — заменить LLM-оценщиков на реальных доменных экспертов для валидации golden labels. Третье — расширить покрытие на отклонённые и заблокированные RFC, чтобы проверять, может ли агент находить проблемы, достаточно серьёзные для блокировки принятия.

Также планируется добавить RFC-экосистемы Python PEPs, Linux kernel и LLVM, а также протестировать больше моделей и конфигураций reasoning.

Часто задаваемые вопросы

Почему 44% — это плохой результат?

В реальной разработке пропуск 56% дефектов на этапе проектирования означает, что эти проблемы попадут в код, а исправление ошибок на поздних этапах стоит в 10–100 раз дороже, чем на этапе спецификации. Для критических систем вроде Kubernetes это недопустимо.

Может ли агент заменить технического писателя?

Пока нет. Агенты хорошо справляются с генерацией текста по шаблону, но плохо — с критическим анализом архитектурных решений. SpecBench показывает, что человеческий экспертный обзор остаётся необходимым.

Какие агенты тестировались?

Codex-5.4 через Codex CLI, Claude Code (Sonnet 4.6 с Extended Thinking) и Gemini CLI. Все использовали стандартные настройки reasoning.

Итог

SpecBench открывает критический пробел в оценке AI-агентов. Мы знаем, что они умеют писать код. Теперь мы знаем, что они плохо умеют проверять спецификации. Для индустрии это означает: агенты могут ускорить реализацию, но не могут заменить архитектурный обзор. Переход от «напиши код по ТЗ» к «проверь ТЗ перед кодом» — это следующий фронтир для AI в software engineering. И пока мы только на 44% пути.