Двухролевой процесс Codex

Кратко

Спецификация служит контрактом.
Проверка не должна быть самооценкой исполнителя.
CI замыкает цикл внешним доказательством.

Зачем нужны две роли

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

Разделение работает только тогда, когда у ролей разные контракты. Две сессии, выполняющие одну широкую инструкцию, не создают контроля качества.

Рабочий контракт

Роль реализации получает границы задачи, критерии приёмки и перечень допустимых изменений. Роль проверки получает те же критерии, но не внутренние допущения автора. Она должна ссылаться на доказательства: тест, diff, журнал или воспроизводимый сценарий.

спецификация → реализация → независимая проверка → CI → решение человека

Что должен проверять CI

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

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

Типичные сценарии отказа

Первый — расширение границ задачи во время реализации. Второй возникает, когда review обсуждает стиль, но не выполняет сценарий приёмки. Третий — зелёный CI, основанный на тестах, которые не затрагивают изменённый путь.

Где паттерн полезен

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

01 / METHOD

Какой вопрос должен решить тест

Двухролевой процесс — не разговор двух персонажей. Он разделяет контракт реализации и независимую проверку артефакта, поэтому сообщение «готово» не заменяет тест, review или решение о merge. Ценность материала в том, что читатель может отделить вопрос пользователя от удобной метрики инструмента и назвать момент, когда результата уже недостаточно для дальнейшей работы.

02 / METHOD

Материал и контрпримеры

ТЗ фиксирует вход, результат, границы, тест и владельца приёмки. Handoff передаёт состояние и доказательства, а не личный нарратив исполнителя или скрытые данные сессии. Контрольный материал не должен подтверждать тезис автора: его задача — выявить случай, где правдоподобный результат опасно вводит в заблуждение для данного процесса.

03 / METHOD

Метод контроля

Последовательность проста: ТЗ, реализация, pull request, CI, независимый review и решение. Дополнительный агент не является целью; его роль должна вносить отдельный критерий контроля. Описание включает порядок шагов, вход и след результата, чтобы независимый человек мог проверить, что измерялось и чего процедура вообще не измеряет.

04 / METHOD

Матрица приёмки

Evidence packet для PR содержит diff, результаты тестов, ограничения, решение reviewer и rollback point. Если gate не проходит, изменение возвращается ответственной роли, а не проходит по уверенно написанному описанию. Критерии заданы до чтения результата, поэтому один удачный пример не может заменить контроль критического типа ошибки.

05 / METHOD

Передача и повторный тест

Минимальный runbook объясняет, как запустить тест, найти артефакт, воспроизвести дефект и использовать rollback. Это позволяет продолжить работу без зависимости от автора prompt. Воспроизводимость включает и возможность показать, почему следующий запуск отличается от предыдущего и кто принимает решение использовать новую версию.

06 / METHOD

Границы вывода

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

07 / METHOD

Пример контроля

Минимальный проход можно проверить на одном pull request: ТЗ называет требование и тест, реализация даёт diff, CI проверяет артефакт, а reviewer фиксирует независимый критерий и решение. Если тест или review не проходит, работа возвращается ответственной роли, а не превращается в очередной текстовый отчёт.

08 / METHOD

Запись об источнике и review

Evidence packet содержит только воспроизводимые следы: ссылку на PR, объём diff, результат CI, ограничения, решение reviewera и rollback point. Не нужно публиковать личные prompt, данные сессий или credentials, чтобы другой человек мог отличить выполнение от утверждения.

LIM

Ограничения и область применения

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

SRC

Источники и внешняя версия

Оригинальный или более ранний материал на Medium

Инструменты AI использовались для структуры и редактирования. Окончательная версия прошла human editorial review фактов, источников, выводов и атрибуции.

LOG

История изменений

05 мар. 2026 г.Первая расширенная версия в собственном архиве.
02 авг. 2026 г.Проверка структуры, ограничений и доказательных связей.