AI code review встраивается в CI/CD и убирает bottleneck ревью. Разбираем, как оркестрация агентов снижает latency и шум.
До момента, когда очередь merge request начинает расти быстрее, чем команда успевает её разбирать, пора масштабироваться. Классический code review хорошо ловит баги, но плохо масштабируется: reviewer делает context switch, оставляет замечания, автор отвечает, цикл повторяется. В результате latency первого ответа измеряется часами. Попытка ускорить процесс через AI code review сначала пошла по наивному пути: один LLM, большой prompt, анализ diff. Это дало ожидаемый эффект — шум, ложные срабатывания и советы без контекста. На сложных кодовых базах такой подход деградирует, потому что модель не удерживает границы задачи и не понимает приоритетов.
Решение сместилось от «одной умной модели» к оркестрации специализированных агентов внутри CI/CD pipeline. Вместо универсального ревью используется набор узких проверок: security, performance, code quality, documentation, compliance. Ключевой элемент — координатор, который агрегирует вывод, устраняет дубликаты и оценивает серьёзность. Это компромисс: больше компонентов и orchestration complexity, но меньше шума и выше точность. Дополнительно появляется контроль стоимости — разные задачи отдаются моделям разного уровня, что снижает общий расход токенов без потери качества на критичных этапах.
Реализация опирается на plugin-архитектуру. Входная точка делегирует конфигурацию плагинам, каждый из которых добавляет часть поведения через общий ConfigureContext. Это устраняет жёсткую связанность: VCS, AI provider и внутренние правила изолированы. Lifecycle делится на три стадии: bootstrap (нефатальные параллельные шаги), configure (критичные последовательные зависимости) и postConfigure (асинхронная донастройка). Такой дизайн снижает вероятность полного падения пайплайна из-за второстепенных ошибок и упрощает замену компонентов.
Оркестрация выполняется в два слоя. Снаружи процесс-координатор запускает OpenCode и передаёт данные через stdin, обходя ограничения ARG_MAX для больших merge request. Внутри — runtime-плагин, который поднимает параллельные сессии агентов. Каждый агент работает изолированно, читает только релевантные patch-файлы и возвращает структурированный результат. Это важно для throughput: нет необходимости передавать полный diff в каждый prompt, что резко снижает токенизацию и latency.
Отдельная инженерная деталь — использование JSONL вместо обычного JSON для логирования. В длинных CI-задачах поток может оборваться, и незакрытый JSON становится бесполезным. JSONL решает это: каждая строка — валидный объект. Это позволяет читать события в реальном времени, отслеживать usage, ошибки и триггеры retry без буферизации всего вывода. Например, если модель обрезала ответ по max_tokens, система автоматически перезапускает шаг.
Серьёзная проблема — восприятие пользователем. Мощные модели могут «думать» долго, что выглядит как зависший job. Простое heartbeat-сообщение каждые 30 секунд почти полностью устраняет ложные отмены. Это пример того, как UX влияет на надёжность пайплайна не меньше, чем архитектура.
Качество ревью обеспечивается не столько моделями, сколько ограничениями. Каждый агент получает строгий prompt с указанием, что игнорировать. Например, security-проверка отмечает только реально эксплуатируемые уязвимости. Без этого система превращается в генератор гипотетических рисков, которые команда быстро начинает игнорировать. Вывод стандартизирован в XML с уровнями severity: critical, warning, suggestion. Это позволяет напрямую связать результат с действиями CI — от approve до блокировки merge.
Финальное решение принимает координатор. Он выполняет deduplication, перераспределяет категории и отбрасывает ложные срабатывания. Если уверенности нет, он повторно читает код. Политика смещена в сторону пропуска: единичные warning не блокируют merge. При этом остаётся escape hatch — комментарий break glass принудительно разрешает изменения. Это важно для production-инцидентов, где latency важнее формальной корректности.
Результаты описаны без конкретных метрик, но поведенчески система делает три вещи: автоматически одобряет чистые изменения, точно находит реальные баги и блокирует опасные merge. Дополнительно снижается latency ревью и уменьшается когнитивная нагрузка на инженеров за счёт фильтрации шума. Такой подход выглядит как эволюционное улучшение CI/CD: LLM не заменяет review, а становится фильтром и приоритизатором.