← Code Review in the AI Era: Trust, Verify, Merge
06 / 07 · 40 min

Team Policy: What Merges Automatically

Change classes by blast radius: what merges automatically on green CI, where a human is mandatory, how to codify the policy with CODEOWNERS and rulesets, and which metrics to steer it by.

Lesson content is currently available in Russian.

What you will learn

  • →Классифицировать изменения по уровням риска и назначать каждому уровню свои требования к ревью.
  • →Оформлять политику технически: CODEOWNERS, rulesets, обязательные проверки и авто-мерж GitHub.
  • →Управлять политикой по метрикам: escape rate, доля возвратов и время до мержа по уровням.

Зачем формальная политика, когда «и так понятно»

Пока PR пять в неделю, команда обходится неписаными нормами: все примерно понимают, что миграцию смотрят вдвоём, а опечатку в README мержат сразу. Агенты ломают это равновесие объёмом: при пятидесяти PR в неделю неписаная норма превращается в лотерею — один ревьюер неделю вычитывает правку документации, другой апрувит миграцию БД по диагонали, потому что «CI же зелёный». Без явной политики команда получает худшее из двух миров: медленный конвейер и случайное качество.

Основа политики — классификация изменений по радиусу поражения: что будет, если этот дифф окажется дефектным? Практичная шкала из четырёх уровней. Tier 0 — изменения, не влияющие на поведение: документация, комментарии, только-тесты (добавление, не изменение ожиданий). Tier 1 — обратимые изменения с узким радиусом: внутренний код за фича-флагом, патч-обновления зависимостей, конфиги дев-окружения. Tier 2 — бизнес-логика: пользовательские сценарии, интеграции, всё, что заметно снаружи, но откатывается обычным revert. Tier 3 — необратимое и системное: миграции схемы, авторизация и платежи, публичные API-контракты, инфраструктура, секреты, CI-конвейер.

Важно: уровень определяется по самому рискованному файлу диффа. PR «фича плюс маленькая миграция» — это tier 3 целиком; именно поэтому политика подталкивает агентов (и людей) резать изменения на PR одного уровня. Классификация по путям файлов автоматизируется — glob-паттерны в CI размечают PR лейблом уровня без участия человека.

Матрица решений и механика GitHub

Каждому уровню — свой минимальный достаточный процесс:

  • Tier 0 — зелёный CI + агент-ревью без критических находок → авто-мерж. Человек не участвует.
  • Tier 1 — зелёный CI + агент-ревью + один человек «по отчёту»: читает находки ревьюера и diff --stat, апрув за минуты, не часы.
  • Tier 2 — полное ревью одним человеком по протоколу трёх проходов; агент-ревью служит картой внимания.
  • Tier 3 — два человека, один из которых владелец зоны (security для auth, DBA/старший для миграций); авто-мерж запрещён технически, а не договорённостью.

Механика GitHub, которой это оформляется:

  • CODEOWNERS — файлы зон tier 3 закреплены за владельцами; их ревью становится обязательным автоматически;
  • Rulesets на защищённые ветки — обязательные status checks (тесты, SAST, агент-ревью), required approvals, запрет force-push; для путей tier 3 — повышенные требования;
  • Auto-merge — включается на PR и срабатывает сам, когда все обязательные проверки зелёные: это и есть техническая реализация tier 0/1;
  • Dependabot + автомерж патчей — отдельный workflow апрувит и мержит patch-обновления зависимостей после зелёного CI; minor и major идут по tier 2.

Принцип оформления: политика, живущая в голове тимлида, не масштабируется; политика в rulesets исполняется без напоминаний. Всё, что можно закрепить настройкой репозитория, закрепляется настройкой; документ с политикой (короткий REVIEW_POLICY.md в корне) объясняет «почему», а не подменяет «как».

Провенанс и ответственность

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

Провенанс оформляется тремя слоями. Лейбл на PR (ai-generated, ai-assisted) — для маршрутизации и метрик; проставляется автоматически конвейером, который создал PR. Трейлеры в коммитах — стандартный для Git способ машиночитаемых метаданных: строка вида Generated-by с именем агента и модели в footer коммита переживает squash и попадает в blame. Отчёт агента-ревьюера как артефакт PR — при разборе инцидента видно, что было найдено до мержа и какое решение принял человек.

Правило ответственности формулируется жёстко: за AI-PR отвечает человек, который запустил агента. Не «модель ошиблась», а «я смержил» — иначе авто-мерж превращается в машину по производству ничьих багов. Практическое следствие: у каждого автономного агента есть владелец-человек, чьё имя стоит в PR как assignee, и лимит — сколько PR этот человек реально способен курировать. Двадцать PR в день на одного владельца — это не автоматизация, это отказ от ответственности с дополнительными шагами.

Последний элемент — протокол отката политики. Дефект, дошедший до main через авто-мерж, автоматически понижает зону: пути, где случился инцидент, временно переводятся на уровень выше (tier 0 → tier 1, tier 1 → tier 2) до разбора. Разбор отвечает на один вопрос: какой автоматической проверки не хватило, чтобы этот дефект не прошёл? Ответ становится новым правилом SAST, тестом или Semgrep-паттерном — и зона возвращается на прежний уровень. Так политика учится на инцидентах вместо того, чтобы навсегда закручиваться от страха.

Метрики и раскрутка политики

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

  • Escape rate по уровням — доля дефектов, дошедших до main, в разрезе tier. Главный показатель: если tier 1 месяцами держит escape rate на уровне tier 2 с человеческим ревью, значит человеческое ревью на tier 1 не добавляло ценности — можно расширять авто-мерж. Рост escape rate — сигнал сжать.
  • Revert rate — доля откаченных PR среди авто-смерженных против прошедших ревью. Прямое измерение того, что пропускает автоматика.
  • Time-to-merge по уровням — если tier 0 ждёт мержа сутки, политика на бумаге, а не в rulesets; если tier 3 мержится за десять минут — кто-то обходит процесс.
  • Нагрузка на ревьюеров — PR на человека в неделю. Метрика ёмкости: политика обязана держать её в пределах, при которых ревью остаётся честным, а не превращается в конвейерный апрув.

Стратегия внедрения — храповик от консервативного: стартуйте с авто-мержем только tier 0, всё остальное — через человека. Каждые две-четыре недели смотрите метрики и расширяйте автоматику на одну ступень там, где данные это оправдывают. Обратное движение («начнём смело, ужесточим после первого пожара») стоит дороже: один громкий инцидент авто-мержа — и команда откатывается к тотальному ручному ревью, потеряв доверие к самой идее.

Итоговая проверка зрелости политики: новый человек в команде может за десять минут по REVIEW_POLICY.md и настройкам репозитория понять, что случится с любым его PR — и ни один пункт этого пути не зависит от того, кто сегодня дежурит.

Practice

Политика ревью для своего репозитория

Классифицируйте пути своего проекта по четырём уровням риска (glob-паттерны), напишите REVIEW_POLICY.md на одну страницу с матрицей «уровень → требования» и оформите технически: CODEOWNERS для tier 3, ruleset с обязательными проверками, авто-мерж для tier 0 и workflow автомержа патчей Dependabot.

Deliverable

REVIEW_POLICY.md, файл CODEOWNERS, скриншот или экспорт ruleset и один демонстрационный PR каждого уровня, прошедший свой маршрут: tier 0 смержился сам, tier 3 потребовал владельца зоны.

Checkpoint

Защитите свою матрицу авто-мержа перед скептиком-безопасником: почему tier 0/1 безопасно мержить без человека, что технически мешает агенту смержить миграцию и как политика отреагирует на первый пропущенный дефект.

  • ✓ Уровни определены по радиусу поражения с правилом «уровень PR равен уровню самого рискованного файла».
  • ✓ Названы технические барьеры, а не договорённости: rulesets, CODEOWNERS, обязательные status checks, запрет авто-мержа для путей tier 3.
  • ✓ Описан контур обратной связи: escape rate и revert rate по уровням, протокол временного понижения зоны после инцидента и превращение разбора в новую автоматическую проверку.

Check yourself

PR содержит фичу (tier 2) и маленькую миграцию схемы (tier 3). Какой уровень у PR?

01PR содержит фичу (tier 2) и маленькую миграцию схемы (tier 3). Какой уровень у PR?

Чем ruleset лучше договорённости «миграции смотрим вдвоём»?

02Чем ruleset лучше договорённости «миграции смотрим вдвоём»?

Кто отвечает за дефект в авто-смерженном AI-PR?

03Кто отвечает за дефект в авто-смерженном AI-PR?

Escape rate на tier 1 с человеческим ревью месяцами совпадает с tier 0 без человека. Что это значит?

04Escape rate на tier 1 с человеческим ревью месяцами совпадает с tier 0 без человека. Что это значит?

Sources

Team Policy: What Merges Automatically · Code Review in the AI Era: Trust, Verify, Merge · VORCL