AI code review на каждый PR

AI code review запускается автоматически при каждом pull request и даёт первичную обратную связь раньше человека. Агент проверяет код по чек-листу команды, оставляет комментарии прямо в PR и отмечает места, которые требуют внимания сеньора. Цель — снять mechanical слой проверок и оставить человеку архитектурные решения.

Что происходит при открытии PR

1. Триггер. Hook в Git-репозитории ловит событие pull_request: opened или synchronize и передаёт diff AI-агенту.
2. Статический анализ. Агент прогоняет diff через rubric: стиль, security patterns, обработка ошибок, тестовое покрытие изменённых файлов.
3. Семантический разбор. AI-агент на AI-модели читает diff в контексте проекта — понимает, что именно изменилось и зачем, а не только как.
4. Комментарии. Агент оставляет inline-комментарии в PR: замечания по строкам, предложения рефакторинга, ссылки на гайдлайны команды.
5. Summary-отчёт. В описание PR добавляется сводка: риски, затронутые модули, рекомендация (ready for human review / needs author revision).
6. Эскалация. Если агент находит критическое замечание (security, breaking change, архитектурный риск) — ставит label и тегает ответственного сеньора.
7. Reaction loop. При пуше новых коммитов агент переобновляет ревью: отмечает исправленные замечания, фокусируется на diff от предыдущей версии.

Что автоматизация НЕ делает

• Не заменяет финального human review. Merge требует подтверждения человека. Агент снимает mechanical слой, но архитектурные решения остаются за командой.
• Не решает проблему неясных требований. Если задача поставлена некорректно, агент это не починит — он оценивает код, а не продуктовую логику или соответствие тикету.
• Не гарантирует отсутствие багов. Снижение bugs per developer на 20% — это верхняя граница из референсных кейсов. Агент ловит типовые паттерны, но edge cases и интеграционные проблемы остаются зоной тестов и QA.

Побочный эффект — размер PR падает на 82%. Разработчики видят быструю автоматическую обратную связь и переключаются на более мелкие, инкрементальные коммиты. Это упрощает merge-флоу, сокращает время до ревью и снижает риск регрессий при откате.

AI code review собирается как набор связанных сервисов вокруг Git-провайдера. Центральный компонент — AI-агент, который получает diff и возвращает структурированные комментарии с привязкой к строкам.

Технический flow

Цепочка запускается webhook'ом из Git-провайдера (GitHub, GitLab, Bitbucket, self-hosted Gitea). Webhook попадает в обработчик, который выполняет следующие шаги:

1. Загружает контекст PR: diff, метаданные, связанные файлы, предыдущие комментарии агента.
2. Формирует промпт с rubric команды и передаёт его AI-агенту на языковой модели.
3. Получает структурированный JSON-ответ: список inline-комментариев, summary, risk-level.
4. Публикует комментарии через API Git-провайдера.
5. Обновляет status check PR: ai-review: passed / ai-review: needs-attention.

Шаги внедрения

1. Инвентаризация rubric. Снимаем с команды правила, которые уже применяются при ручном ревью: код-стиль, security requirements, паттерны обработки ошибок, требования к тестам. Это входной документ для агента.
2. Выбор стека. AI-модель — дефолт для семантического анализа кода. Для отдельных проверок (линтинг, security scan) используются специализированные инструменты, AI-агент агрегирует их результаты.
3. Подключение webhook. Настраивается pull_request webhook в Git-провайдере с фильтрацией по событиям (opened, synchronize, ready_for_review).
4. Pilot на одной команде. Включаем агента на одном репозитории или одной команде на 2 недели. Собираем feedback от сеньоров: где агент помогает, где шумит.
5. Калибровка rubric. По результатам пилота правим промпт и правила эскалации — убираем false positives, добавляем недостающие проверки.
6. Раскатка. После пилота подключаются остальные репозитории. Добавляется dashboard: PR throughput, changes requested, время до первого комментария.

Компоненты решения

Как агент работает с rubric

Rubric передаётся агенту как system prompt: набор правил с примерами хорошего и плохого кода. Каждое правило имеет приоритет (blocker / warning / suggestion). Агент возвращает ответы в структурированном JSON — inline-комментарии привязаны к строкам, summary описывает общие риски.

При обновлении PR агент повторно прогоняет diff, но учитывает предыдущие комментарии: не дублирует замечания, отмечает fixed issues, фокусируется на новых изменениях.

Что получает команда

Метрики из референсных кейсов: PR throughput +110% (с 11.4 до 23.9 PR на разработчика), changes requested -39%, bugs per developer -20%, средний размер PR -82%. Время до первого комментария на PR сокращается с часов до минут — разработчик не ждёт сеньора, чтобы понять, что код готов к merge.

Базовый набор — Git-провайдер с API и webhook'ами, формализованные правила ревью, готовность команды адаптировать процесс.

Данные и доступ

• Git-репозиторий с API. GitHub, GitLab, Bitbucket или self-hosted Gitea — любой провайдер с pull/merge request API и webhooks.
• Токен с правами на комментирование PR и установку status checks.
• Существующий rubric или гайдлайны код-стиля. Если нет — их нужно собрать до старта, это 1-2 дня работы с техлидом.
• CI/CD pipeline (опционально). Если агент должен читать результаты тестов и покрытия — нужен доступ к CI-артефактам.

Готовность команды

• Техлид или сеньор отвечает за rubric и калибровку агента на пилоте.
• Разработчики согласны на новый шаг в PR-флоу. AI-комментарии — подсказки, а не блокер; финальное решение остаётся за человеком.
• SLA на реакцию на AI-комментарий. Без процессного правила агент превращается в шум, который игнорируют.

Таймлайн

Сложность — weekend (базовая конфигурация). Реалистичный срок внедрения — 2-4 недели:

1. Неделя 1: инвентаризация rubric, выбор стека, подключение webhook.
2. Неделя 2: настройка AI-агента, тесты на одном репозитории.
3. Неделя 3-4: пилот на одной команде, калибровка, раскатка.

Для команд со сложной монорепой или специфичными требованиями (compliance, closed-source security rules) срок растёт до 6-8 недель.