Ревью при росте потока MR

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

Почему ревью становится узким местом

Агент удешевляет создание изменения, но не его понимание. Команда OpenAI, строившая продукт полностью руками агентов, описывает, как узким местом стал человеческий QA, и в ответ сделала интерфейс, логи и метрики доступными самому агенту (Harness engineering). Авторы спецификации Symphony добавляют другой предел: большинство людей комфортно ведут 3–5 параллельных сессий с агентами, дальше продуктивность падает.

Для тимлида из этого следует простое: пропускная способность команды теперь определяется не скоростью написания, а скоростью проверки. Оптимизировать нужно именно её.

Правило первое: автор отвечает за MR

Тот, кто запустил агента, — автор MR со всеми обязанностями. До того как позвать ревьюера, он:

• сам прочитал весь дифф и может объяснить каждое изменение;
• запустил тесты и проверил поведение — на стенде, в браузере, на устройстве;
• прогнал локальное ревью командой /review и разобрал находки;
• убрал лишнее: случайные правки форматирования, отладочный код, файлы не по задаче.

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

Правило второе: маленькие MR

Агенту всё равно, сколько файлов менять, ревьюеру — нет. Договоритесь о верхней границе размера MR и проверяйте её в CI (пример — в уроке «Ворота качества»). Крупную задачу агент может разбить сам:

Разбей эту задачу на последовательность независимых MR,
каждый из которых можно проверить и смёржить отдельно.
Для каждого укажи: что меняется, как проверить, от какого зависит.

Если без большого MR не обойтись — например, при массовом переименовании, — отделите механическую часть от смысловой: механический MR проверяется скриптом и выборочно, смысловой — внимательно.

Шаблон описания MR

Ревьюеру нужно понять за минуту, что изменилось и чему верить. GitLab подхватывает шаблоны из .gitlab/merge_request_templates/:

## Что и зачем
Карточка: <ссылка>. Одно-два предложения о сути изменения.

## Как проверено
- [ ] Тесты: какие добавлены, какие запускались
- [ ] Ручная проверка: где и какой сценарий
- [ ] Что НЕ проверено и почему

## Участие агента
- [ ] Код написан с агентом, автор прочитал весь дифф
- Что агент делал сам, что правилось вручную

## На что смотреть ревьюеру
Места, где автор не уверен, и решения, которые стоит обсудить.

Раздел «Что НЕ проверено» — самый ценный: он честно показывает риск и направляет внимание ревьюера.

Уровни ревью по риску

Одинаково тщательное ревью для всех MR — роскошь, которой больше нет. Разделите изменения по риску и договоритесь о правилах для каждого уровня.

Уровень определяется по путям файлов: в GitLab для этого есть файл CODEOWNERS и правила одобрения, которые требуют подтверждения владельца при изменении определённых каталогов (обязательное одобрение владельцев кода доступно не во всех редакциях GitLab — проверьте свою). Правила ревью для агента по тем же путям лежат во вложенных AGENTS.md (см. «Командные стандарты»).

Разделение обязанностей

Агент — хороший первый проход: ищет ошибки, пропущенные проверки, несоответствие соглашениям. В Codex ревью-агент нацелен на серьёзные проблемы — в документации говорится о приоритетах P0 и P1 (GitHub). Человек отвечает за то, что агент оценить не может: соответствует ли изменение задаче и замыслу продукта, не усложняет ли архитектуру, понятно ли оно будущей команде.

Два правила стоит закрепить явно:

• Агент не одобряет MR и не мержит его. Одобрение — действие человека, защита веток остаётся.
• Код, написанный агентом, проверяет не тот же агент в той же сессии. Отдельный ревьюер — другой человек или хотя бы отдельный запуск ревью — видит то, что автор пропустил. В исследовании OpenAI ревью-агент находил что исправить и в коде, полностью написанном Codex (OpenAI Alignment).

Подробно о настройке ревью-агента — в уроке «Codex как ревьюер в GitLab и GitHub».

Ритм команды

• Время до первого ревью — договорённость, а не пожелание: например, в течение рабочего дня. Измеряйте его в GitLab.
• Ревью-слоты. Вместо того чтобы прерываться на каждый MR, ревьюеры проверяют пачкой два-три раза в день.
• Лимит незавершённой работы. Если у автора три MR ждут ревью, он не запускает четвёртую задачу, а помогает с ревью. Иначе очередь растёт бесконечно.
• Ротация. Не все MR к одному сеньору: ревью — способ распределять знание о коде, особенно для джуниоров.

Что делать с советами «убрать гейты»

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