Почему ревью стало узким местом
Агенты ускоряют написание кода, и очередь на ревью растёт первой. DORA в отчёте 2025 года отдельно выделяет работу небольшими партиями как условие эффекта от AI. Агент легко генерирует большие изменения, а большие изменения сложно проверить и протестировать.
Ревью изменений от агентов сложнее и по другой причине. Код выглядит аккуратно, стиль соблюдён, названия хорошие. Ошибки сидят в логике и в том, чего в коде нет: пропущенный граничный случай, неверное понимание требования, обход архитектурного правила.
Что проверяет агент, а что человек
| Проверка | Кто |
|---|---|
| Форматирование, стиль, типы, известные антипаттерны | Линтеры и анализаторы в CI |
| Соответствие спеке и acceptance criteria | Агент-ревьюер |
| Тесты: покрывают ли они поведение, не ослаблены ли существующие | Агент-ревьюер |
| Нарушения правил проекта и договорённостей команды | Агент-ревьюер |
| Типовые ошибки: граничные значения, обработка ошибок, часовые пояса, деньги | Агент-ревьюер |
| Архитектурные решения, влияние на другие команды | Человек |
| Безопасность, данные, миграции, публичные API | Человек, агент как первая линия |
| Соответствие продуктовой задаче | Человек |
Граница зависит от того, что заденет ошибка. Изменение внутри модуля, покрытое тестами, может пройти автоматический цикл «агент пишет — агент ревьюит — CI проверяет». Изменение, которое задевает другие команды, агент сам отправляет на архитектурное ревью.
Писать и ревьюить должны разные модели
Правило «разработчик не ревьюит свой код» действует и для агентов. Модель, которая написала код, склонна считать свои решения правильными. Другая модель с отдельным контекстом и инструкциями ревьюера находит больше ошибок.
В кейсе Праксора команда из восьми человек перевела quality gates на агентов: одна модель пишет, другая ревьюит. Ревью-агент поймал расхождение в суммах сводного отчёта у части клиентов при зелёных базовых тестах. Причина была в агрегации по серверному UTC вместо местной даты клиента. После разбора в правила ревью добавили проверку часовых поясов.
Как написать правила для агента-ревьюера
Ревьюер без правил выдаёт общие замечания про читаемость и именование. Полезный ревьюер работает по чек-листу проекта:
# review-rules.md
## Сначала
- Прочитай спеку из описания MR. Для каждого AC найди код и тест, который его проверяет.
- Если AC не покрыт тестом — блокирующее замечание.
## Блокирующие замечания
- Изменены или удалены существующие тесты без объяснения в описании MR.
- Суммы во float. Даты без часового пояса. Группировка по дате без учёта client.tz.
- Новый вызов внешнего сервиса без таймаута и обработки ошибки.
- Изменения в migrations/, infra/, packages/shared/ — отправь на ревью владельца.
## Не пиши
- Замечания по стилю и форматированию: их проверяет линтер.
- Предложения «можно улучшить» без конкретной проблемы.
## Формат
- Каждое замечание: файл и строка, что не так, почему это ошибка, как проверить.
- В конце: вердикт approve / request changes и список закрытых AC.Правила ревью растут из реальных дефектов. Каждый дефект, который дошёл до production мимо ревью, — кандидат на новый пункт чек-листа.
Инструменты
AI-ревью можно получить тремя способами:
- Встроенное ревью Git-хостинга. Например, Copilot code review в GitHub. Быстрый старт, но меньше контроля над правилами и моделью.
- Специализированные сервисы. CodeRabbit, Qodo, Greptile и похожие. Подключаются к GitHub и GitLab, поддерживают свои правила.
- Свой агент в CI. Claude Code, Codex или другой агент запускается в пайплайне с вашими правилами ревью и публикует комментарии в MR. Больше всего контроля, работает в закрытом контуре через LLM-шлюз.
Для компаний с требованиями ИБ чаще подходит третий вариант: код не уходит во внешний сервис, а модель выбирается политикой шлюза.
Цикл «ревьюер — исполнитель»
Ревьюер возвращает замечания исполнителю, исполнитель исправляет, ревьюер проверяет снова. Без ограничений цикл может идти долго. Рабочие правила:
- замечания возвращаются через комментарии в MR, чтобы история была видна людям;
- после трёх неудачных пересдач задача уходит человеку;
- каждый случай, когда задача ушла человеку, разбирают: чего не хватило в спеке, правилах или проверках.
Как понять, что AI-ревью работает
- Время от открытия MR до мержа. Должно сокращаться за счёт того, что человек получает изменение уже после первого круга замечаний.
- Доля полезных замечаний. Сколько замечаний агента привели к исправлению. Если меньше половины, правила ревью слишком общие.
- Дефекты, пропущенные ревью. Что дошло до production и почему ревьюер это не поймал.
- Нагрузка на людей. Сколько MR в неделю требуют ревью человека и сколько времени оно занимает.
Quality gates в программе Праксора
Строим автоматический цикл для типовых задач и ревью человека там, где цена ошибки высокая. После пилота у команды остаются регламент code review с AI и чек-лист quality gates по типам задач. Что остаётся у вас
Вопросы
Может ли AI полностью заменить ревью кода человеком?
Для изменений внутри одного модуля, покрытых тестами, — да, при хороших правилах ревью. Архитектурные решения, безопасность, данные и изменения, которые задевают другие команды, проверяет человек.
Почему агент-ревьюер пишет бесполезные замечания?
У него нет правил проекта, и он проверяет по общим представлениям о хорошем коде. Нужен чек-лист с блокирующими проверками, запретом на стилистические замечания и требованием сверять код со спекой.
Можно ли ревьюить код той же моделью, которая его написала?
Можно, но другая модель с отдельным контекстом находит больше ошибок. Правило «разработчик не ревьюит свой код» стоит применять и к агентам.
Как сделать AI-ревью без отправки кода во внешние сервисы?
Запускать агента-ревьюера в своём CI и подключать его к моделям через корпоративный LLM-шлюз с локальной моделью для чувствительных репозиториев.