Codex как ревьюер в GitLab и GitHub

Ревью-агент — самый быстрый способ снять с людей часть нагрузки при растущем потоке MR. Но он же самый лёгкий способ получить ложное чувство безопасности. В этом уроке — как Codex работает ревьюером в GitLab и GitHub, что нужно для подключения, как писать для него правила и как измерить, помогает ли он вашей команде. Описание актуально на октябрь 2026 года, интерфейсы меняются — сверяйтесь с документацией по ссылкам.

Три способа получить ревью от Codex

1. Локально — команда /review в CLI, IDE или ChatGPT desktop: против базовой ветки, по незакоммиченным изменениям или по коммиту. Ревьюер работает отдельно и не меняет файлы (code review). Это инструмент автора до открытия MR.
2. Интеграция с GitLab или GitHub — Codex сам комментирует MR по триггеру или по упоминанию @codex review. Это тема урока.
3. Свой конвейер в CI — codex exec в задании GitLab CI с вашим промптом. Пример — в уроке «Ворота качества», подробно — в «Автоматическое ревью merge request».

GitLab: что есть в бете

По документации, поддержка GitLab находится в бете и доступна на всех планах ChatGPT (GitLab). Что умеет:

• Ревью по запросу: комментарий @codex review в MR. Ручное ревью может включать находки приоритетов P0, P1 и P2.
• Автоматическое ревью: включается переключателем, триггер на выбор — при открытии MR, на каждый пуш или экспериментальный «умный» триггер. Автоматические ревью сосредоточены на P0 и P1.
• Исправление: @codex fix the P1 issue просит исправить находку и может запушить в ветку, если есть права. Любой другой комментарий с @codex, кроме review, запускает облачную задачу с MR в контексте.

Для ревью на GitLab.com, исправлений и других задач нужно настроенное окружение проекта (project environment). Групповая активность поддерживает только ревью.

Self-managed и Dedicated

Self-managed GitLab поддерживается, но подключение сложнее:

• Администратор рабочего пространства настраивает шаблон подключения, затем каждый ревьюер подключается сам.
• Нужен сервисный аккаунт с доступом уровня Developer к выбранным группам или проектам. Его может создать Codex, или можно использовать существующий; токену нужен scope api и срок действия не меньше 30 дней.
• Подписанные вебхуки проекта и группы требуют GitLab 19.0 или новее; групповые вебхуки — ещё и редакции Premium или Ultimate.
• Для проектного вебхука нужны права Maintainer или Owner.

Прежде чем планировать внедрение, узнайте у администраторов версию и редакцию вашего GitLab. Стоит заодно обсудить с ними сеть: интеграция работает через вебхуки и API, так что облачному сервису нужен доступ к инстансу. И главное: ревью в облаке означает, что код MR обрабатывается на стороне OpenAI. Можно ли так делать с кодом конкретного клиента, решает не тимлид, а техдир и договор — см. «Данные и код клиентов».

GitHub

В GitHub интеграция не в бете. Автоматическое ревью включается в настройках Codex на странице code review для конкретного репозитория; для этого нужны права push или admin. Ручной запуск — тот же комментарий @codex review, Codex отвечает обычным GitHub-ревью. Документация для GitHub говорит, что Codex отмечает только проблемы P0 и P1, чтобы комментарии оставались сфокусированными (GitHub).

Полезная деталь — разовый фокус: @codex review for issues in the database migration. Есть и отдельное ревью безопасности @codex security review в статусе research preview.

Правила ревью в AGENTS.md

И GitLab, и GitHub читают раздел ## Code Review Rules в AGENTS.md, ближайшем к изменённому коду. Общие правила — в корневом файле, специфичные для сервиса — во вложенных. Рекомендации документации: начать с двух-трёх коротких правил, описывать существенное для репозитория поведение, указывать безопасный путь или исключение, убирать правила, которые создают шум.

## Code Review Rules

### Данные пользователя
- Токены и персональные данные хранятся только в защищённом
  хранилище платформы, не в обычных настройках приложения.
- Логи не содержат телефонов, email и токенов.

### Совместимость
- Изменение формата ответа API в клиенте без поддержки
  старого формата — ошибка: часть пользователей не обновит
  приложение сразу.

Чего здесь нет: «используй табы», «не длиннее 120 символов». Это задача линтера.

Цифры OpenAI и что из них следует

OpenAI опубликовала данные о своём ревью-агенте (OpenAI Alignment, декабрь 2025):

• авторы меняют код в ответ на комментарий в 52,7% случаев;
• на PR, полностью сгенерированных облачным Codex, ревьюер оставлял комментарии в 36% случаев, и 46% этих комментариев приводили к изменению кода — против 53% на PR, написанных людьми;
• команда сознательно пожертвовала частью полноты ради точности: меньше находок, но выше доверие к каждой.

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

Как понять, что ревьюер полезен

Через месяц работы посмотрите на свои данные, а не на чужие:

• Доля принятых комментариев — сколько замечаний агента привели к изменению кода. Та же метрика, что у OpenAI.
• Ложные срабатывания — сколько замечаний команда отклонила как неверные. Если много, правила в AGENTS.md создают шум.
• Пропуски — баги, найденные людьми или QA после того, как агент «не нашёл проблем». Это не повод отключать ревьюера, а материал для правил и тестов.
• Время до первого ревью и время человеческого ревью — изменились ли они.

Учтите расход: по документации отдельная категория учёта есть только у ревью через GitHub, остальные ревью расходуют общий лимит (pricing). Триггер «на каждый пуш» в активном проекте — дорогая настройка; начните с «при открытии MR» или с ручного вызова.

Порядок внедрения

1. Две-три недели — только ручной @codex review на выбранных MR, правила в AGENTS.md.
2. Автоматический триггер при открытии MR на одном проекте.
3. Разбор метрик, чистка правил, решение о расширении.

На всех этапах действует одно: агент не одобряет MR, защита веток и обязательные одобрения остаются. Документация формулирует это прямо: правила ревью направляют Codex, но не заменяют тесты, защиту веток и обязательные одобрения.