Кросс-сервисное ИИ-ревью: как агентная система закрывает слепые зоны в GitLab
Habr AI · оригинал
Материал подготовлен автоматизированной редакционной системой. Факты можно сверить по указанному первоисточнику.
Разработчик представил решение для GitLab, которое проводит ревью не отдельных merge request, а всей задачи сразу во всех затронутых сервисах. Система использует ИИ-агента для анализа связей между репозиториями и работает по принципу кворума, где голос нейросети учитывается, но не является решающим.
Традиционные инструменты автоматического ревью часто пропускают ошибки на стыке микросервисов, так как анализируют только diff одного репозитория. Описанный подход позволяет выявлять несовместимости контрактов и логические ошибки в распределённых системах, снижая нагрузку на разработчиков и повышая надёжность деплоев.
В современной разработке микросервисной архитектуры типичная задача затрагивает несколько репозиториев: меняется биллинг, схема событий, потребитель данных и фронтенд. Классические ИИ-ревьюеры, работающие с diff одного merge request (MR), не видят этих связей. Как отмечает автор решения, именно на стыке сервисов чаще всего происходят сбои: продюсер отправляет новое поле, а консьюмер ещё парсит старую структуру. Чтобы решить эту проблему, было создано решение для GitLab, которое запускает ревью по всей задаче (issue), а не по отдельному MR.
Система работает следующим образом: по номеру задачи из имени ветки находятся все репозитории группы, где есть связанные изменения. Эти репозитории клонируются в единое рабочее пространство вместе с описанием задачи и diff'ами. Далее запускается ИИ-агент (например, Codex, Claude Code или Gemini CLI), который самостоятельно навигирует по файлам, анализирует вызовы функций и проверяет совместимость контрактов между сервисами. Агент формирует отчёт с указанием конкретных файлов и строк, где обнаружены блокирующие проблемы, и голосует за или против слияния.
Важным архитектурным решением является использование агента, а не простого анализа diff через API. Автор объясняет, что вопрос о том, сломал ли один сервис другой, невозможно решить только чтением изменений в одном репозитории. Агенту необходимо открыть код соседних модулей, найти все места вызова изменённых функций и проверить соблюдение правил проекта (например, из ARCHITECTURE.md). Это позволяет находить ошибки, которые не видны в изоляции, такие как код, попавший не в тот репозиторий.
Для обеспечения безопасности и корректности процесса реализован механизм кворума «2 из 3». Голос ИИ-ревьюера учитывается, но он не имеет права вето. Если нейросеть отклоняет MR, для слияния нужны два голоса человека. Если же ИИ одобряет, достаточно одного человека. Такой подход защищает команду от ложных срабатываний модели: если разработчики не согласны с ИИ, они могут проголосовать за слияние большинством человеческих голосов.
Техническая реализация включает два пайплайна для разделения секретов: один в проверяемом проекте запускает ревью, второй в отдельном проекте-ревьюере выполняет анализ и публикует результаты. Это позволяет избежать утечки токенов и ключей моделей. Также система учитывает гонки состояний: если ветка изменилась во время ревью, результат отменяется, а повторные запуски для одного коммита ставятся в очередь.
По словам автора, после внедрения этой системы количество найденных им багов вручную резко снизилось, так как ИИ-ревьюер стал надёжным фильтром. Система прошла тестирование на более чем ста задачах без ошибок. Решение заточено под GitLab (версия 17.11+), включая self-managed инстансы, и не работает с GitHub или Bitbucket. Оно универсально для любых языков программирования, так как агент читает код как человек, опираясь на контекст и правила проекта.