Ревью кода с Codex: как находить реальные дефекты

Автор: Казачкин Даниил Михайлович · Обновлено 19 августа 2026 г.

Codex может провести отдельное review незакоммиченных изменений, коммита или diff относительно базовой ветки. Цель ревью — найти ошибки, которые автор захочет исправить:…

Codex может провести отдельное review незакоммиченных изменений, коммита или diff относительно базовой ветки. Цель ревью — найти ошибки, которые автор захочет исправить: нарушение поведения, потерю данных, уязвимость, гонку или отсутствующую проверку. Пересказ diff не является finding.

Сначала зафиксируйте scope

Укажите точный набор изменений:

working tree;
конкретный commit;
текущая ветка против base branch;
выбранные файлы;
pull request, доступный через подключённый источник.

Команда /review в поддерживаемых поверхностях предлагает готовые области и запускает dedicated reviewer без изменения working tree. При этом review pane показывает состояние Git, включая пользовательские правки, а не только строки, созданные Codex.

Формат полезного замечания

Каждый finding должен содержать:

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

Пример:

HIGH — profile.service.ts, обновление email.
Два параллельных запроса проходят проверку уникальности до записи.
Один из них завершится ошибкой базы и превратится в 500 вместо ожидаемого 409.
Обработайте duplicate-key на границе записи и добавьте конкурентный
integration test; предварительную проверку можно оставить для UX.

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

Проверяйте изменение в контексте

Diff показывает новую строку, но ошибка часто зависит от вызывающего кода, схемы или старых данных. Reviewer должен прочитать непосредственно поддерживающий контекст, не превращая review конкретной ветки в аудит всего репозитория.

Особенно важны:

изменение публичного типа без обновления потребителей;
новая ветка без отрицательного теста;
миграция без совместимости со старым приложением;
cleanup, который не выполняется при ошибке;
изменение авторизации после загрузки ресурса;
обработка async-результата после смены сессии.

Разделяйте review и исправление

Первый проход полезно выполнять read-only: так findings не смешиваются с собственной реализацией reviewer. После того как владелец принимает замечание, Codex может исправить его в обычных sandbox/approval границах.

Цикл:

получить findings;
проверить сценарий и серьёзность;
выбрать замечания для исправления;
внести минимальный patch;
добавить регрессионный тест;
повторно проверить изменённый diff.

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

Review checklist по риску

Для backend:

validation и trust boundaries;
авторизация на каждом ресурсе;
транзакции, идемпотентность и гонки;
ошибки и утечки деталей;
совместимость данных.

Для frontend:

stale async responses;
loading/error/empty states;
права и скрытие чувствительных действий;
accessibility и keyboard flow;
SSR/hydration и cleanup.

Checklist направляет внимание, но finding появляется только при доказуемом сценарии.

Практика: два прохода

Проведите review одного diff дважды:

correctness — логика, данные, конкуренция и тесты;
security — ввод, auth, secrets, filesystem и network.

Для каждого замечания потребуйте сценарий отказа. Затем удалите пересказы, общие пожелания и пункты без связи с изменённым кодом. Оставшиеся findings отсортируйте по ущербу.

Что важно запомнить

У review должен быть точный diff и критерии.
Finding описывает воспроизводимый сценарий и последствие.
Reviewer читает поддерживающий контекст, но не расползается в полный аудит.
Разделяйте read-only поиск замечаний и последующее исправление.

Частые вопросы

Может ли /review изменить мои файлы?

Официальный режим review сообщает findings и не меняет working tree. Если после этого попросить применить исправления, начнётся обычная задача с текущими разрешениями.

Нужно ли исправлять все замечания Codex?

Нет. Проверяйте доказательство, область и приоритет. Ложноположительное замечание следует отклонить с причиной; полезное — превратить в тест и минимальное исправление.

Почему reviewer должен видеть базовую ветку?

Без правильного merge base он может анализировать чужие или уже существующие изменения, пропустить удалённый контекст и неверно определить регрессию текущей работы.