Garage Eight убрала чужие апрувы в 69 MR внутреннего сервиса с AI-ревью

Команда ускорила написание кода с помощью ИИ, а потом упёрлась в ревью: проверяющих больше не стало. В Garage Eight одна Android-фича из 35 merge request могла неделю ждать по два апрува на каждый. Практический вопрос здесь простой: какие изменения можно пропускать после проверки ботом, чтобы люди успевали разбирать действительно дорогие ошибки?

По рассказу Анны Саботович, которая ведёт внедрение AI-ревьюера, в октябре во внутреннем сервисе аналитики разработки смержили 69 MR без апрува другого человека. В репозитории самого ревьюера чужой апрув был только у шести из 35 MR. Это полезный кейс для команд с растущей очередью изменений, но универсального разрешения убрать ревьюеров он не даёт.

Число проверяющих зависит от цены ошибки

Garage Eight разделяет сервисы на четыре уровня риска. Для ревью важно, что произойдёт, если сервис выдаст неправильный результат. Оценку ставят архитекторы доменов по худшему сценарию; сервис без оценки считают самым рискованным.

Например, ошибка во внутреннем эксперименте может затронуть только его авторов. Ошибка в расчёте выплаты уже касается денег клиента. Требовать одинаковое количество апрувов для этих изменений удобно административно, но внимание команды расходуется без учёта последствий.

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

На самом высоком уровне, где затронуты деньги и требования регулятора, остаются два человека. До появления автоматического возврата обязательного человеческого апрува компания сохраняет людей на обоих верхних уровнях риска.

Закрытое замечание ещё не означает исправленный баг

Первая метрика выглядела убедительно: 92% замечаний бота закрывали. Но в мобильных репозиториях GitLab запрещает merge, пока остаётся открытое обсуждение. Среди разобранных замечаний на смерженных MR закрыты были все 647 из 647. Метрика фактически показывала выполнение условия слияния.

Поэтому команда стала смотреть, менялся ли до merge код рядом со строкой замечания. Затем сравнила результат с фоном: как часто меняется случайное место в том же файле.

За третий квартал в 12 репозиториях бот оставил 585 серьёзных замечаний. После 219 из них код рядом изменили — это 37% против фоновых 7%. Из 27 вручную проверенных случаев в 25 правка действительно относилась к замечанию. По оценке автора материала, за квартал до merge исправили около 200 серьёзных проблем, включая 98 багов.

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

Боту тоже нужны очередь, проверки и предохранители

Инфраструктура быстро стала частью качества ревью. Одна проверка на внутренней модели заняла около 50 минут и задержала остальные MR. В сентябре ревьюер молчал семь суток, в октябре — ещё 30 часов: оба раза закончился бюджет API. После этого появились алерты на молчание, зависшие проверки и баланс.

Для проверки смены моделей команда собрала 42 исторических MR; в 32 человек подтвердил реальные проблемы. Такой набор помогает сравнивать версии ревьюера, хотя его недостаточно для широких выводов о надёжности.

Есть и проблема бесконечных обсуждений: на одном MR бот проверил 27 коммитов и оставил 45 находок, на 44 ответил агент автора. Команда считает необходимыми ограничение числа циклов и проверку только нового диффа.

Практический вывод: начинать стоит с одного репозитория с понятной ценой ошибки и измеримой очередью к людям. Затем проверить, какие замечания приводят к полезным правкам, сколько шума создаёт бот и что происходит при его отказе. Автоматический возврат человека при росте откатов у Garage Eight пока в планах. Именно этот незакрытый пункт ограничивает дальнейшее снятие апрувов.