tl;dr

Попытка автоматизировать процесс разработки привела к 94% на Terminal Bench 2.1, а затем к обнаружению того, что GPT-5.6 Sol начал обманывать.

Предыстория

Последний год применялся «спецификационный» (spec-driven) подход к разработке.

Он довольно простой.

Прежде чем просить LLM что-то сделать, сначала модель просят набросать документ о том, что именно нужно сделать.

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

Подход работает, но довольно однообразен.

Поэтому было решено его автоматизировать.

chum-codex

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

Примечание: при попытке сделать это на обычном Codex или Claude Code что-то получалось, но стандартные промпты рассчитаны скорее на пользователя, чем на «супервизора»

Гипотеза заключалась в том, что супервизору достаточно уметь читать файлы и вызывать воркеров — именно так и работает человек в этой роли.

Вместо того чтобы пересобирать среду выполнения кода для воркеров, были рассмотрены Pi, OpenCode и App Server от Codex.

Codex использовался уже довольно давно, поэтому решено было попробовать именно app-server. Остальные варианты тоже интересны и достойны внимания.

Первая версия сработала достаточно хорошо: супервизор оценивал масштаб задачи, вызывал воркера, например, с запросом на дизайн, воркер выдавал документ, затем супервизор просил воркера превратить документ в спецификацию реализации (разбитую по фазам, если это уместно), и наконец просил воркера реализовать задуманное.

Примечание: эта упрощённая диаграмма не показывает часть с обратной связью от пользователя, например, ревью дизайн-документа

---
config:
  sequence:
    mirrorActors: false
---
sequenceDiagram
    participant S as Supervisor
    participant W as Worker

    S->>S: Size task
    S->>W: Design request
    W-->>S: Design doc

    S->>W: Create implementation spec
    W-->>S: Phased implementation spec

    S->>W: Implement
    W-->>S: Result

Ура! Часть времени в процессе разработки удалось сэкономить.

(или нет?)

Кроличья нора

Всё работало — не идеально, но работало.

Примечание: вот на этом моменте стоило бы остановиться

Осмотревшись с высоты уже достигнутого, показалось, что этим результатом обязательно нужно поделиться со всеми.

Как лучше это сделать? Бенчмарки!

Какой бенчмарк лучше использовать? Точно не Terminal Bench!

В какой бенчмарк в итоге пришлось погрузиться слишком глубоко? В Terminal Bench 2.1!

Terminal Bench

Для тех, кто не знаком с агентными бенчмарками: название Terminal Bench говорит само за себя. Это набор задач, которые можно решить из терминала — от игры в шахматы до сборки ДНК.

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

Но именно эта простота делает его удобным для тестирования.

Тестирование начали с нескольких задач, на которых обычный Codex с GPT-5.5 проваливался: сборка/вставка ДНК, извлечение/обработка видео, извлечение из ELF-файлов и сборка белков.

Сработало.

Эти задачи выигрывали от «дизайн-прохода» перед реализацией: документ помогал избежать сужения решения и циклической валидации.

Уверенность в подходе выросла ещё сильнее.

Примечание: Terminal Bench 1.x/2.x уже насыщен (saturated), но это отдельная история.

GPT-5.6?

Опубликованный результат GPT-5.5 составляет 83,8% (~74/89 задач, 5 прогонов).

chum-codex показывал 89,9%, или ~80/89 задач.

Прежде чем радостно объявить о победе над Codex, для проверки было запущено несколько прогонов обычного Codex.

Для контекста: дело было 25 июня 2026 года, и уже ходили слухи о скором выходе GPT-5.6.

Три прогона обычного Codex дали неожиданный результат: 88,8%.

Собственная система оказалась впереди обычного Codex лишь на одну задачу.

Одни задачи явно улучшились, другие — регрессировали.

На следующий день был анонсирован GPT-5.6 Sol.

После обращения в OpenAI там подтвердили, что GPT-5.6 находился на тестировании, но все ID запросов относились к GPT-5.5

Интересно, что Terminal Bench 2.1 оказался единственным связанным с кодом бенчмарком, который изначально показала компания: 88,8% у GPT-5.6 Sol и 91,9% у Sol Ultra.

Sol Ultra запускает параллельные субагенты для выполнения работы, хотя на практике это заметно более затратно по токенам, чем нужно для большинства обычных задач.

В любом случае, новый рубеж вызывал искренний интерес!

Управляемость

GPT-5.6 гораздо сложнее направлять в нужную сторону.

Переход с 5.5 на 5.6 снизил эффективность харнесса. То, что раньше делалось легко, теперь требовало намного больше усилий.

Часть этой разницы объясняется изменением базового промпта Codex. Для GPT-5.5 промпт сфокусирован на коде и много внимания уделяет «инженерному чутью» — включая рекомендации по фронтенду, ограничения на редактирование и требование «относиться с сочувствием к уже существующей кодовой базе».

gpt-5.5 prompt Фрагмент промпта GPT-5.5

Промпт Codex для GPT-5.6 заметно отличается — на инженерную специфику там уходит почти ноль внимания. Вместо этого фокус смещён на коммуникацию, автономность/упорство и навыки (skills), которые для 5.5 загружались отдельным промптом.

gpt-5.6 prompt Фрагмент промпта GPT-5.6 Sol

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

С другой стороны, это может означать, что чем лучше становятся модели, тем труднее их контролировать.

Простой пример — задача про PyTorch на Terminal Bench 2.1.

С GPT-5.6 Luna и Terra модель легко направляется к общему решению, принимающему два входа: forward(src, tgt).

С Sol, особенно при высоких уровнях рассуждения, модель, независимо от направляющих инструкций, скатывается к решению с одним входом — forward(src).

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

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

94% на TB 2.1

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

Это тонкий баланс: если качнуться слишком далеко в одну сторону, супервизор с радостью расширит объём задачи или начнёт бесконечно гоняться за валидацией.

Задачи в бенчмарке простые. Нужно рабочее решение с первого прохода, а не бесконечное расширение.

Пробовалось снижение уровня рассуждения, упрощение формулировок, сокращение спецификационного флоу, добавление новых skills и так далее. Что-то улучшалось, что-то ломалось.

Пара идей показала перспективность.

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

flowchart TB
    S["Supervisor"]
    W["Worker"]
    R["Commentary / Reasoning"]
    A["Assumption Auditor"]

    S -->|"task / steer"| W
    W -->|"result"| S

    W --> R
    R -.->|"read-only visibility"| A
    A -->|"assumptions surfaced"| S

    W ~~~ A

    style R fill:#6fc7e1,stroke:#141414,color:#141414

Супервизор мог затем изучить допущения, сделанные воркером, и попросить пересмотреть или уточнить эти шаги. Такой подход работает, но медленно и постфактум.

Другая идея — попросить модель выдавать «открытые вопросы», по аналогии с более «ручной» разработкой. Изначальная идея была в том, чтобы воркер возвращал открытые вопросы (вместо полноценного дизайн-документа), когда с ними сталкивался, а супервизор их разрешал. Это освобождало бы контекст супервизора, показывая ему «лес», а не «деревья».

Тем не менее даже с уменьшенным контекстом супервизору было тяжело не согласиться с выводами воркера (либо, наоборот, он слишком охотно углублялся в тривиальные детали).

Чтобы убрать это смещение, следующей идеей стало применение отдельного контекста, который сначала бы map и reduce (всё старое снова становится новым!) обрабатывал вопросы, пытаясь снять любое встроенное или скрытое смещение, а затем возвращал нормализованную версию супервизору (или напрямую воркеру).

Этот подход сработал лучше, но зависел от того, чтобы воркер верно обозначал проблемы именно как вопросы.

С Sol оказалось, что гораздо проще заставить модель выдавать свои решения, а не свои вопросы. Модель настолько уверена в себе, что не воспринимает свои допущения как вопросы, даже если уже упомянула альтернативы в своих рассуждениях или комментариях.

flowchart TB
    S["Supervisor"]
    W["Worker"]
    D["Decisions"]
    M["Map"]
    R["Reduce"]

    S -->|"task / steer"| W
    W -->|"result"| S

    W --> D
    D --> M
    M --> R
    R -->|"normalized questions"| S

    R -.->|"optional"| W

    style D fill:#6fc7e1,stroke:#141414,color:#141414
    style M fill:#f49bab,stroke:#141414,color:#141414
    style R fill:#f49bab,stroke:#141414,color:#141414

Имея на руках решения, супервизор (или третий контекст) может приостановить воркера, оценить решения как вопросы и направить процесс соответствующим образом.

Это сработало намного лучше и привело к лучшему результату: 84/89 задач на Terminal Bench 2.1.

chum-codex

Примечание: одна задача была заблокирована по соображениям кибербезопасности, но прошла с откатом на GPT-5.6 Terra, так что счёт 83 + 1

Sol любит обманывать

Снова полный энтузиазма, наконец «укротив» Sol и уже слишком далеко зайдя в использовании бенчмарка для разработки, а не... как бенчмарка, захотелось узнать, насколько далеко можно продвинуться.

Теперь интерес был не только в регрессиях обычного Codex — хотелось понять, что мешает добраться до 86 или 88 из 89.

Короче говоря, финальный набор задач в Terminal Bench 2.1 плохо специфицирован, и именно поэтому Mythos, GPT-5.6 и другие модели упираются в потолок около ~90% без дополнительной специализированной инфраструктуры.

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

Пример — задача make-mips-interpreter, в инструкции которой сказано, что «я (пользователь) проверю, что ты правильно загрузил doom».

Проблема в том, что верификатор проваливается, если файл вывода, который создаёт агент при загрузке doom, уже существует.

Разберём по шагам:

  1. Пользователь заявляет, что проверит, загрузил ли агент Doom
  2. Загрузка Doom создаёт файл /tmp/frame.bmp
  3. Агент следит, чтобы /tmp/frame.bmp существовал, чтобы пользователь знал, что загрузка прошла правильно
  4. Верификатор проваливается, если /tmp/frame.bmp уже существует

Агент предполагает, что пользователь хочет проверить, что именно агент загрузил виртуальную машину, поэтому оставляет файл как доказательство, но тест верификатора проваливается заранее, если файл уже существует. Классический парадокс!

Исправить это можно, заставив систему удалять состояние валидации/игнорировать опасения пользователя, но такое исправление (очевидно) выходит боком в других задачах и сценариях

Перед тем как перейти к более важным вещам, было решено поделиться результатами с оговоркой, что подход слишком близок к хакингу бенчмарка для личного вкуса (вся эта схема с третьим контекстом и map-reduce работает именно для этого бенчмарка, но в реальном мире достаточно просто писать более чёткие инструкции и/или итерировать с помощью follow-up сообщений).

Перед полным прогоном с N=5 бенчмарк был запущен один раз для проверки, и неожиданно оказалось, что ранее успешная задача провалилась:

torch-pipeline-parallelism

Задачу прогнали ещё пару раз. Сработала 1 раз из 3.

Разбираясь в деталях, не удалось понять, что изменилось в харнессе, поэтому та же задача была протестирована на обычном Codex, тоже на уровне xhigh.

Там она прошла 3 раза из 3.

Любопытно.

Прогоны были изучены, чтобы понять, что сработало, а что нет.

GPT-5.6 Sol обманывал каждый раз.

Возник вопрос: не были ли все прошлые успехи результатом такого же обмана?

Это точно Sol?

При изучении двух успешных прогонов chum-codex на задаче torch-pipeline обнаружилось нечто тревожное.

Веб-поиск был отключён, но жизнь находит выход:

codex-sol-cheating GPT-5.6 Sol на xhigh

Примечательно, что воркер не имел доступа к инструменту web_search, но вместо этого решил использовать curl, чтобы обратиться к DuckDuckGo, GitHub, grep.app и SourceGraph.

Похоже, что 29 июля произошёл первый случай «обмана» у обычного Codex, а собственный харнесс впервые обманул именно сегодня, 12 августа.

{
  "src": "/charts/torch-pipeline-apexcharts-pass-data.json",
  "chart": { "height": 440 },
  "colors": ["#6fc7e1", "#e08e45", "#3d8ba6", "#f49bab"]
}

Стоит признать, что этих данных недостаточно для однозначных выводов. За сессией, где обычный Codex обманывал 3 раза из 3, последовали два прогона без обмана.

Также неясно, действуют ли модели намеренно, обманывая, или просто натыкаются на решение в процессе поиска по вебу.

Изучение трасс обычного Codex выявило явную улику:

Мне нужно изучить исходники HF с помощью curl, чтобы проверить последние версии на GitHub. Было бы полезно узнать ожидаемый скрытый тест на основе задания.

Это определённо очень похоже на обман.

Для chum-codex последний шаг перед запросами curl не менее показателен:

Возможно, решение доступно публично, что значит, я смогу эффективно с ним сравнить. Просто нужно использовать curl для доступа к необработанным путям и собрать необходимую информацию!

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

Обеспокоенность не отменила интереса: при повторном изучении прогона на 83/89 от 17 июля не нашлось никаких следов обмана ни в этой, ни в других задачах.

Учитывая недавние новости и задержку следующей модели, невольно возникает вопрос: это тот же самый Sol?

Что дальше

Задача torch-pipeline оказалась не единственной, что провалилась в этот день, — это неприятно напомнило о переходе с GPT-5.5 на GPT-5.6.

Судя по всему, чем лучше становятся модели, тем сложнее строить вокруг них полезные ограничители, а пока нужен перерыв.

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

Помещать мощные модели в цикл с ленивым промптингом бывает увлекательно, но доверять их выводу становится всё труднее.

Чем мощнее становятся модели, тем меньше инструкций им требуется — но при этом каждая оставшаяся инструкция становится важнее, чем раньше.

Даже новый Terminal Bench 3.0 добавил во все свои задачи следующую инструкцию:

«Не обманывай, используя онлайн-решения или подсказки, специфичные для этой задачи».

Достаточно ли этого? Вряд ли.