Проверка Codex: как принимать работу агента без веры на слово
Самый опасный способ работать с агентом — смотреть только на уверенный ответ. Codex может звучать убедительно, но рабочее решение принимается не по тону сообщения. Его нужно принимать по изменениям, по diff, по комментариям, по тому, что можно stage, вернуть на правку или откатить.
Официальная документация OpenAI описывает это как Review в Codex. Для разработчика это знакомая зона изменений. Для владельца проекта, редактора или оператора это можно перевести проще: review — место, где агентная работа перестает быть рассказом и становится проверяемым артефактом.
Какая рабочая боль здесь решается
Когда Codex делает задачу, у человека возникает соблазн принять результат по общей логике: “выглядит нормально”. В коротких задачах это иногда проходит. В живом проекте так нельзя. Изменения могут затрагивать несколько файлов, старые правки пользователя, последние действия агента и соседние незавершенные изменения.
Review нужен, чтобы не смешивать все это в одну кашу. Он показывает, что изменилось, где именно, и какую часть результата человек готов принять.
Что устанавливает официальный источник
Документация говорит, что review pane показывает изменения, сделанные Codex, изменения пользователя и другие незакоммиченные изменения в репозитории. Также можно смотреть весь diff относительно базовой ветки или только изменения последнего turn. В review можно оставлять inline comments, работать с результатами code review и управлять staged/unstaged состояниями.
Для ONFF важен управленческий вывод: Codex не должен сам превращать сделанную работу в принятую работу. Между “агент изменил” и “человек принял” должен быть приемочный слой.
Что дать Codex на вход
| Что смотреть | Зачем | Человеческое решение |
|---|---|---|
| All branch changes | увидеть полный объем изменений | можно ли принимать весь пакет |
| Last turn changes | отделить последний шаг агента | не испортил ли он предыдущее |
| Inline comments | дать точную обратную связь | что вернуть Codex на доработку |
| Staged/unstaged | отделить принятое от спорного | что войдет дальше, а что нет |
| Revert | убрать ошибочное изменение | где остановить агентную работу |
Перед review полезно дать Codex не просьбу “проверь себя”, а критерии приемки:
Задача: проверить изменения Codex перед принятием.
Смотри:
- весь diff;
- изменения последнего turn;
- файлы, которые я менял сам;
- строки, где нужно оставить комментарий;
- изменения, которые нельзя stage без моего решения.
Верни:
- список готовых изменений;
- список спорных изменений;
- вопросы ко мне;
- рекомендации: stage, доработать или revert.Так Codex помогает подготовить review, но не подменяет человека.
Какой артефакт должен вернуть Codex
Хороший артефакт — это карта приемки. Не “все нормально”, а конкретная таблица:
- файл;
- что изменилось;
- почему это связано с задачей;
- риск;
- действие: принять, прокомментировать, вернуть на правку, откатить;
- человеческое решение.
Если Codex не может отделить свои изменения от чужих, это сигнал остановиться. В таком состоянии нельзя публиковать, отправлять или делать вид, что gate пройден.
Как проверить без программирования
Даже человек без глубокого кода может проверить работу через вопросы:
- Понятно ли, какие файлы изменились?
- Видно ли, что именно сделал Codex?
- Отделены ли последние изменения от старых?
- Есть ли спорные места?
- Есть ли решение по каждому спорному месту?
Если review превращается в стену непонятного текста, значит нужен дополнительный слой: summary, комментарии по строкам или короткая карточка приемки.
Где это место в контент-заводе
В нашем журнале review — это брат ARTICLETEXTREVIEW.yaml, VISUALQA.yaml и LIVEPUBLICBODYAUDIT.yaml. Все они решают одну задачу: не доверять красивому результату без проверяемого перехода.
Codex может написать статью, собрать визуал, подготовить соцпост, но каждая стадия должна иметь свой review. Иначе фабрика становится ускорителем ошибок.
Что попросить перед принятием работы
Хороший приемочный запрос к Codex должен быть конкретнее, чем "проверь, все ли хорошо". Лучше попросить агента показать три слоя: что он изменил, почему это связано с задачей и где остаются риски. Тогда review становится не угадыванием, а рабочей картой.
Минимальный запрос может звучать так: "Собери приемочную карточку. Раздели изменения на готовые, спорные и опасные. Для каждого спорного места покажи файл, причину, риск и рекомендуемое действие. Отдельно отметь, что ты не стал менять". Такой формат особенно полезен для владельца проекта: он не обязан читать весь код, но видит, где именно нужно принять решение.
Если Codex не может объяснить, почему изменение относится к задаче, это не значит, что изменение плохое. Но это значит, что его рано принимать. Сначала нужно вернуть агенту вопрос, сузить задачу или попросить отдельный diff только по последнему turn.
Что остается человеческим
Человек решает: принять изменение, вернуть Codex на доработку или откатить.
Codex может показать diff, сгруппировать риски и предложить действие. Но он не должен сам объявлять работу принятой, если gate еще не пройден. Хороший review не замедляет агентную работу. Он делает ее управляемой.