Review в Codex - это отдельная роль, а не вежливая просьба похвалить diff. Хороший обзор ищет реальный поведенческий риск: что сломается, какие ветви не покрыты, где изменилось публичное поведение, а не пересказывает то, что и так видно в изменениях. Локально обзор запускают командой /review внутри сессии или отдельным неинтерактивным codex review. Разница между "перескажи diff" и "найди, что здесь может сломаться" - это разница между украшением и настоящей проверкой.
Ключевое различие ролей - в том, кто пишет и кто проверяет. Модель, написавшая код, и модель, его проверяющая, полезно разнести: обзор отдельной ролью с задачей искать риск даёт больше, чем просьба к тому же агенту оценить собственную работу. Но и здесь важно не впасть в ложную уверенность: обзор от той же модели находит пропуски, однако разделяет с автором те же слепые пятна, поэтому не заменяет тест, статический анализатор и человека, отвечающего за merge.
Приоритет findings важнее их количества. Длинный список замечаний, где критическая уязвимость соседствует со стилистической придиркой, не помогает принять решение. Хороший обзор ранжирует: сначала то, что меняет поведение или открывает риск, потом то, что стоит поправить, и лишь в конце - косметика. Задача обзора - не набрать замечаний побольше, а показать, что действительно требует внимания перед merge, и не утопить это в шуме мелочей.
Полезно один раз увидеть, как запускается обзор в двух формах. Ниже - интерактивный /review внутри сессии и отдельный codex review --uncommitted для неинтерактивного прогона. Точный набор флагов всегда проверяют через codex review --help: CLI-справочник поддерживает обзор незакоммиченных изменений, диффа против базовой ветки, конкретного коммита и обзор с кастомными инструкциями. Форму выбирают под задачу, а не гоняют одну и ту же всегда.
Неинтерактивный codex review удобен там, где обзор встраивают в процесс. Обзор незакоммиченных изменений подходит для проверки перед коммитом; дифф против базовой ветки - для проверки целой ветки перед PR; обзор конкретного коммита - для точечного разбора. Кастомные инструкции позволяют сфокусировать обзор на том, что важно именно этому проекту, - например, на безопасности платежей или на совместимости API, а не на общем "посмотри код".
Ложная уверенность - главная ловушка обзора, и о ней стоит помнить отдельно. Зелёный обзор от модели не является независимым доказательством корректности: он полезен как ещё один слой внимания, но не как финальная печать. Доказательством остаётся прошедший тест и наблюдение реального поведения, а не согласие агента с самим собой. Человек, ответственный за merge, никуда не девается - обзор помогает ему, но не снимает с него решение.
Обзор встроен в тот же цикл доказательства, что и вся работа. Findings обзора - это гипотезы о риске, которые проверяют тем же способом, что и любое утверждение: тестом, который воспроизводит проблему, статической проверкой, наблюдением поведения. Обзор, нашедший потенциальную гонку, ценен не сам по себе, а тем, что задаёт направление для проверки. Принимать замечание обзора на веру так же неправильно, как принимать на веру "исправил" от автора.
Типичные провалы обзора предсказуемы. Просить пересказ diff вместо поиска поведенческого риска. Получить длинный неранжированный список, где важное тонет в косметике. Принять зелёный обзор от той же модели за независимое доказательство и пропустить merge без теста и человека. И гонять одну форму обзора всегда, не выбирая под задачу. Запускайте обзор как отдельную роль, ранжируйте findings, проверяйте их доказательством и держите человека на merge - обзор усиливает внимание, но не заменяет проверку.
# Интерактивно, внутри сессии
/review
# Отдельный non-interactive review
codex review --uncommitted # незакоммиченные изменения
# также: дифф против базовой ветки, конкретный commit, custom instructions
codex review --help # точный набор флагов