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 тижнів.