Когда агентов много: мерж и ревью

Оркестрация решает задачу «как запустить много агентов». Следующая проблема появляется сразу: MR приходят быстрее, чем их успевают принять. Ревью, нестабильные тесты, конфликты и очередь на мерж превращаются в главное ограничение. В уроке — что предлагают источники, почему одну из самых цитируемых практик нельзя переносить без оговорок и как перестроить мерж-процесс агентства, не отказываясь от контроля.

Что делает одна команда OpenAI

В статье Harness engineering описана философия мержа команды, которая пять месяцев писала продукт без ручного кода:

• блокирующих merge-гейтов минимум;
• PR короткоживущие;
• нестабильные тесты чаще перезапускают, чем позволяют им блокировать работу;
• люди могут смотреть PR, но не обязаны, и со временем почти всё ревью перешло к агентам.

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

Прочтите это внимательно: это практика одной команды на внутреннем продукте, в greenfield-репозитории, где среду строили под агентов с первого коммита, а не рекомендация OpenAI для всех. Та же статья подчёркивает, что поведение агентов в их репозитории не переносится на другие проекты без сопоставимых вложений в обвязку.

Проверки не исчезли, они переехали

Если сопоставить статью OpenAI с принципом «keep quality left» у Биргитты Бёкелер (Harness engineering for coding agent users), противоречия нет. OpenAI не отменяет проверки — она переносит их внутрь агентного цикла: локальная валидация, структурные тесты и линтеры, агенты-ревьюеры, которые гоняют PR, пока все не будут удовлетворены. Убираются человеческие ожидания, а не сами проверки.

Наш вывод. Снижать число блокирующих гейтов можно ровно настолько, насколько сильны датчики внутри цикла. Команда, у которой нет структурных тестов, наблюдаемости и независимого ревьюера-агента, убрав гейты, получит не скорость, а инциденты.

Что говорят данные

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

• Отчёт DORA 2025: связь между внедрением AI и пропускной способностью стала положительной, но связь с стабильностью поставок по-прежнему отрицательная. Авторы называют AI усилителем того, что уже есть в команде.
• OpenAI в материале о масштабировании проверки кода называет агента-ревьюера инструментом поддержки, а не заменой внимательного суждения, и главным риском считает отношение к чистому ревью как к гарантии безопасности.
• METR отмечает, что при параллельной работе нескольких агентов привычный учёт времени ломается — оценивать эффект по ощущениям нельзя.

Что меняется в мерже

Размер и срок жизни MR

Это общий знаменатель всех источников. Маленький MR быстрее ревьюится, реже конфликтует и дешевле откатывается. Ограничение можно сделать механическим: CI-задача, которая предупреждает, если дифф больше заданного числа строк вне сгенерированных файлов, и подсказывает агенту разбить изменение.

Очередь и конфликты

При десятке параллельных веток main меняется каждые полчаса. В Symphony система сама следит за CI, делает rebase, разрешает конфликты и перезапускает нестабильные проверки. В GitLab часть этого закрывают merge trains (доступность зависит от редакции GitLab): MR проверяется поверх уже стоящих в очереди. Перебазирование и разрешение простых конфликтов можно отдать агенту — это хорошо формализуемая работа, если после неё прогоняются все тесты.

Нестабильные тесты

Перезапуск по умолчанию прячет реальные баги, блокировка по умолчанию останавливает поток. Середина — карантин с владельцем и сроком:

e2e:
  stage: test
  script:
    - npx playwright test --grep-invert @quarantine
  retry:
    max: 1
    when: [script_failure]

e2e_quarantine:
  stage: test
  allow_failure: true
  script:
    - npx playwright test --grep @quarantine

Тест получает тег @quarantine только вместе с задачей в трекере на починку; если список карантина растёт, это сигнал для фоновой уборки (урок об энтропии). Разбор причин нестабильности — в уроке о нестабильных тестах.

Ревью по классам риска

Вместо «все MR ревьюит человек» или «никакие» — правила по классу изменения. Пример для сайта агентства:

Класс определяется по путям: в GitLab для этого есть CODEOWNERS и правила одобрения, которые требуют конкретных ревьюеров для конкретных каталогов. Агент никогда не одобряет собственный MR — независимость ревьюера сохраняется и тогда, когда ревьюер тоже агент. Правила для агента-ревьюера живут в разделе ## Code Review Rules в AGENTS.md; документация GitLab-интеграции Codex напоминает, что они не заменяют тесты, защиту веток и обязательные одобрения.

Пакет доказательств

Самый действенный способ ускорить человеческое ревью — не убрать его, а сократить. В Symphony PM и дизайнер получают пакет для ревью с видео. Для MR агентства пакет может состоять из:

• трёх строк «что и зачем» со ссылкой на задачу;
• скриншотов изменённых страниц на 360 px и 1440 px;
• видео или трассы Playwright для изменённого сценария;
• отчёта тестов и списка проверок, которые агент прогнал локально;
• явного списка того, что не проверено.

Последний пункт важнее остальных: он показывает ревьюеру, куда смотреть.

Метрики потока

Если поток вырос, а метрики качества не видны, вы не знаете, стало ли лучше. Минимальный набор:

• время от открытия MR до мержа и отдельно — время ожидания ревью;
• доля MR, принятых без доработок;
• доля замечаний агента-ревьюера, по которым код изменили (этой метрикой пользуется сама OpenAI);
• change failure rate: откаты и хотфиксы после релиза;
• размер карантина нестабильных тестов.

Если время до мержа падает, а change failure rate растёт, вы повторяете вывод DORA на своих данных. Подробнее о метриках для команды — в уроке о метриках, о процессе ревью при росте потока — в уроке о ревью.

Напряжение, которое не исчезнет

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