AI-агенты в цикле ревью: Code Review и PRD Review
Контекст. Распределённая инженерная команда, телеком-продукт, годами накопленное легаси. Ревью долгое, senior-времени мало, PRD часто дырявые. Нужно было встроить AI так, чтобы использование было нулевым усилием для разработчика — иначе инструмент умирает за неделю.
Что не сработало — и почему это важно
Прошли пять промежуточных этапов за год. Каждый закрыл гипотезу, а не отменил следующий:
01
✗Индивидуальные подписки ChatGPT / Copilot
Нет общего контекста, несопоставимые результаты, нет интеграции с GitLab/Confluence.
02
✗Локальные Ollama + Open WebUI
Своё «ChatGPT» с данными компании. Модели слишком медленные, MCP практически не работает, требования к железу высокие.
03
✗Централизованные платные подписки
MCP-серверы нужно ставить локально — не все в команде готовы. Стандарта нет, каждый со своими промптами.
04
✗n8n + Claude API
Удобная оркестрация мышкой, первый работающий AI code review — но проекты не шарятся между пользователями, упёрлись в rate limits.
05
✓Jenkins + Claude Code headless в Docker
Навыки живут в GitLab — общие для всей команды. Никакой настройки на рабочем месте, один стандарт, всё через webhook.
Как работает сейчас
Разработчик пишет @ai mr review в комментарии к MR. Дальше — без его участия: Jenkins banner показывает прогресс прямо в MR, GitLab MCP подтягивает diff и контекст репозитория, Jira MCP сверяет релевантность тикету, результат возвращается inline-комментариями плюс аппрув.
Второй процесс — PRD Review в Confluence — на том же каркасе: триггер в комменте, Confluence + PDF MCP читают спецификацию, модель проверяет три критерия: противоречивость, полноту, верифицируемость. Дырявый PRD автоматически создаёт тикет в Jira.
Что бы сделал иначе
Сразу начал бы с headless-агента в CI. Локальные UI-first решения (Ollama, n8n) — тупик для production. Единственная архитектура, которая выживает: триггер в существующем инструменте разработчика → оркестрация на стороне CI → агент с доступом к корпоративному контексту через MCP.
stack: Jenkins · Claude Code (headless) · Docker · GitLab MCP · Jira MCP · Confluence MCP · Playwright MCP · PDF MCP · кастомные skills
Эволюция DevOps в SpaceBridge: от BASH до платформы
Контекст. Пришёл в компанию по спутниковой связи в 2017-м. На входе: ручная сборка, никакого контроля среды сборки, ручные релизы. GitoLite, GitLab, Jenkins — и «немного BASH». Задача растянулась на девять лет маленькими шагами.
2017
Первая задача: долгая сборка прошивки.Docker + Jenkins DSL + lint. Реакция команды: «А можно оставить всё старое рядом?». Можно.
2018–19
Перенос старых сред сборки в Docker, автоматизация и документирование.Миграция хранилища кода на GitLab. Внедрение merge-requests. Бинари — с windows share на Artifactory.
2020
All-as-Code: Jenkins declarative, универсальные pipelines.Atlassian-стек (Jira, Confluence). Мониторинг инфраструктуры разработки на Telegraf + Grafana. Инвентори — NetBox.
2021–23
Cloud NMS: сравнительный анализ AWS / GKE / on-prem k8s.Миграция legacy NMS в Kubernetes, помощь в распиливании монолита. Дистрибутив + документация для установки и поддержки.
2022+
Поддержка российского офиса в санкционных условиях.Удержание команды, механизмы финансовой устойчивости, легальные схемы расчётов, обучение людей новому стеку.
2024–25
Платформенный подход: универсальные pipelines под однотипные компоненты.SatCloud from firmware to SaaS. Продукт уезжает в облако, embedded остаётся — gap закрывается общим инструментарием.
Вынос — маленькие обратимые изменения работают. Переход от BASH к платформе в лоб не взлетает: люди отторгают. Работающая формула: добавить новое рядом со старым, дать команде время адаптироваться, убирать старое, когда она сама начинает спрашивать «а нельзя так же, как в соседнем проекте?».
stack: Docker · Jenkins (DSL & declarative) · GitLab · Artifactory · Atlassian · Kubernetes · Ansible · Grafana · NetBox · Yocto · cmake · Ant · Composer
За пределами ревью: BC-checks и тесты Web UI, которые пишет агент
После того, как два AI-процесса закрепились в production, естественный следующий шаг — расширить охват. Два живых эксперимента:
Backward compatibility checks
Релизится новая версия — агент должен увидеть, что в ней сломает обратную совместимость. Триггер — комментарий к release notes в Confluence. GitLab MCP изучает diff между релизами, модель детектирует изменения конфигов (новые обязательные поля, удалённые параметры, изменение типов и дефолтов) и протоколов (переименование методов, изменение структур сообщений, новые обязательные поля). Отчёт — комментарием в Confluence.
Автотесты Web UI NMS
Триггер на релиз NMS. Ansible обновляет тестовый сетап, Confluence MCP вынимает тесты на человеческом языке, модель превращает их в последовательность конкретных шагов, Playwright MCP выполняет. Работает — но честно: далеко не готовый процесс. Открытые проблемы:
- Динамические UI-элементы — Playwright теряет селекторы после обновления
- Шаги из Confluence неоднозначны → модель интерпретирует по-разному
- Контекстное окно — большие наборы тестов не влезают, агент теряет часть сценариев
- Главный вопрос: как понять, что тест прошёл корректно, а не просто без ошибок
План решения: разделение тестов по веткам Confluence с запуском в отдельных сессиях, subagents для изоляции контекста, скриншоты на каждом шаге для полной трассируемости. Честное «не факт, что взлетит именно так» — часть этого процесса.
stack: Claude Code · Playwright MCP · Confluence MCP · GitLab MCP · Ansible · Jenkins
