Автоматичне рев’ю коду з ШІ: що доручити і як перевірити результат

Коротка відповідь: ШІ варто підключати до рев’ю pull request як додаткового рецензента, який пояснює зміни, нагадує про пропущені перевірки й підсвічує підозрілі місця. Він не замінює статичний аналіз безпеки, перевірку залежностей, пошук секретів, тести та рішення відповідального розробника. Головна умова впровадження — кожне зауваження ШІ вважається гіпотезою, доки її не відтворили. Коментар моделі не доводить, що дефект існує, а відсутність коментарів не доводить, що код безпечний.

Тому безпечний старт виглядає так: ШІ пише підказки; під час пілоту команда вимикає для нього можливість схвалювати зміни, а злиття лишає за відповідальною людиною; обов’язкові перевірки лишаються такими самими, як були; команда заздалегідь домовляється, як рахувати користь і шум. Після прочитання ви зможете вирішити, які задачі рев’ю віддати ШІ, як вбудувати його в наявний процес, як перевіряти його зауваження й за якими ознаками розширювати або зупиняти пілот.

Які задачі віддати ШІ

Найкраще ШІ-рецензент справляється з роботою, яка забирає увагу людини, але не вимагає остаточного рішення. Перша така задача — зведення змін. Коли pull request зачіпає двадцять файлів, короткий опис «що змінилося і навіщо» допомагає рецензенту швидше зорієнтуватися. Друга — пропущені перевірки: необроблена помилка, відсутня валідація вхідних даних, забута обробка порожнього значення, тест, який не покриває нову гілку логіки. Третя — порушення домовленостей команди: назви, структура модулів, заборонені бібліотеки, правила логування. Четверта — підозрілі місця, на які варто подивитися уважніше: ручне складання SQL-запиту, нове звернення до зовнішнього сервісу без таймауту, зміна прав доступу.

Домовленості команди можна передати рецензенту явно. Наприклад, у Copilot code review можна використовувати файли інструкцій у репозиторії: загальні правила для всього проєкту та окремі правила для певних шляхів. Що чіткіше записані правила, то менше загальних порад отримає команда.

Важливо одразу розділити два типи результату. Корисна підказка — це зауваження, яке спрямовує увагу: «тут, можливо, не перевіряються права». Підтверджений дефект — це проблема, яку відтворили: є вхідні дані, дія і неправильний результат. ШІ видає перше. Друге з’являється лише після перевірки людиною або автоматичним тестом.

Окремо перевірте налаштування конкретного інструмента. У Copilot за замовчуванням відгук типу «Comment» не зараховується до обов’язкових схвалень. Адміністратор може окремо дозволити схвалення Copilot, яке за певних налаштувань задовольнить правило обов’язкового схвалення PR. Для пілоту залиште схвалення за людиною. Copilot може пропустити проблему або помилитися, тому перевіряйте кожне зауваження.

З чого складається перевірка безпеки

Безпека коду перевіряється кількома різними способами, і кожен ловить свій клас проблем. Розмовне рев’ю ШІ — лише один із них.

У GitHub code scanning виконує статичний аналіз коду на вразливості й помилки та створює сповіщення. Він може використовувати CodeQL або сторонні аналізатори з результатами у форматі SARIF. Доступність і умови для приватних репозиторіїв залежать від тарифу й організаційних налаштувань. Copilot code review також має тарифні та адміністративні умови; окремі сценарії оплачуються ШІ-кредитами, а агентні функції можуть використовувати хвилини GitHub Actions. Перед пілотом перевірте актуальні умови саме для вашої організації й репозиторію.

Практичний висновок: якщо до впровадження ШІ у вас уже працював SAST, він лишається. Якщо не працював, рев’ю ШІ не закриває цю прогалину — його потрібно налаштувати окремо.

Як вбудувати рев’ю в PR

Технічно підключити ШІ-рецензента нескладно. Складніше зробити так, щоб він допомагав, а не засмічував обговорення. Ось рішення, які варто ухвалити до запуску.

Коли запускати. У Copilot code review ручний запит є типовим режимом, але автоматичну перевірку можна ввімкнути в налаштуваннях репозиторію чи організації. Перевірка кожного нового коміту також потребує окремого налаштування; без нього повторний запуск можна замовити вручну. Для пілоту почніть із ручного запуску: розробник сам визначає, коли зміни готові до першого перегляду. Перевірка кожного коміту збільшує кількість коментарів, а повторний запуск може знову показати попередні зауваження, навіть якщо їх уже закрили або відхилили.

Що бачить рецензент. Принцип мінімальних прав: ШІ має доступ лише до тих репозиторіїв і інструментів, які потрібні для рев’ю. У Copilot налаштування репозиторію можуть дозволяти рев’ю використовувати MCP-інструменти — підключення до зовнішніх сервісів. Перевірте, які саме інструменти підключені і до яких даних вони мають доступ.

Звідки беруться інструкції. Copilot читає файли інструкцій з гілки pull request, а не з основної гілки. Отже, автор PR може змінити правила рев’ю тим самим PR. Зміни у файлах інструкцій варто перевіряти так само уважно, як зміни коду, і закріпити за ними власника.

Хто автор коментаря. Зауваження ШІ мають бути явно позначені як автоматичні. Рецензент-людина повинен бачити, де думка колеги, а де згенерована підказка.

Як уникнути дублів. Якщо SAST уже створив сповіщення для рядка, а ШІ написав про те саме, розробник отримує дві задачі замість однієї. Домовтеся вести дублі в одному сповіщенні статичного аналізу, а коментар ШІ на те саме місце закривати з посиланням на нього. Саме сповіщення теж потрібно перевірити: SAST може помилятися.

Як оцінювати зауваження

Кількість коментарів не є метрикою якості рев’ю і тим паче не є метрикою безпеки. Потрібні чотири показники.

1. Підтверджені дефекти — зауваження, які відтворили і виправили.
2. Хибні спрацьовування — зауваження, які не підтвердилися після перевірки.
3. Пропуски — дефекти, знайдені пізніше тестами, QA або користувачами в тих самих змінах, які ШІ переглядав і не позначив. Щоб їх порахувати, потрібна розмічена вибірка: набір PR, для яких ви знаєте, які дефекти там були насправді.
4. Час розробника — скільки хвилин іде на читання, перевірку і закриття зауважень, включно з хибними.

Частку зауважень, які виявили підтверджений дефект, рахують так: кількість таких зауважень поділити на всі зауваження за період. Наприклад, якщо з 200 зауважень підтвердилися 18, частка — 9%. Це навчальні числа, а не результат пілоту BotLabs. Сама по собі ця цифра нічого не вирішує: 18 знайдених проблем можуть бути дуже цінними, якщо серед них є діра в авторизації, і зовсім неважливими, якщо це стиль. Тому кожне підтверджене зауваження отримує оцінку серйозності вже після перевірки, а не зі слів моделі.

Навчальна матриця: як перевірити зауваження ШІ

Нижче навчальний приклад, а не реальний випадок. Розробник додав сторінку керування замовленнями. В інтерфейсі кнопка «Видалити» показується лише адміністраторам. Серверний обробник видалення замовлення роль користувача не перевіряє.

Ключовий рядок — перший. Модель може дуже переконливо пояснити, чому сервер вразливий. Але доказ — це не пояснення, а запит від користувача без прав і відповідь сервера. Якщо сервер відмовив, зауваження хибне, хоч яким би логічним воно здавалося. Якщо погодився — дефект підтверджено, і тест, який це перевіряє, лишається в наборі назавжди.

Для пілоту заздалегідь зафіксуйте, як рахуєте час на розбір хибних зауважень: наприклад, розробник позначає кожне закрите зауваження міткою «підтверджено» або «не підтверджено» і вказує орієнтовні хвилини на перевірку. Без цього через місяць залишаться лише враження.

Як поводитися з виправленнями

Деякі інструменти не лише коментують, а й пропонують готові виправлення. Тут правило одне: виправлення приймається як звичайна зміна коду, з тими самими перевірками.

Автоматичні виправлення мають кілька типових ризиків. Запропонована зміна може бути синтаксично неправильною або потрапити не в те місце. Вона може бути коректним кодом, який змінює поведінку програми, бо система не знає намірів розробника. Вона може не усунути вразливість або додати нову. Вона може виправити проблему лише частково. І вона може запропонувати вигадану залежність з правдоподібною назвою. Тому кожну пропозицію потрібно переглянути й за потреби відредагувати до прийняття.

Робочий порядок виглядає так:

• Виправлення оформлюється як окремий зрозумілий diff, а не вбудовується мовчки в чужий коміт.
• Перед прийняттям додається тест, який падав до виправлення і проходить після нього. Без такого тесту невідомо, чи закрита саме та проблема.
• Після виправлення повторно запускаються всі обов’язкові перевірки: збірка, тести, статичний аналіз, перевірка залежностей.
• Будь-яка нова залежність перевіряється вручну: чи існує пакет, хто його підтримує, чи немає відомих вразливостей.
• Зміни в чутливих модулях — авторизація, платежі, криптографія, міграції даних — погоджує власник модуля. Якщо у вас використовується файл власників коду, саме він визначає обов’язкового рецензента.

Пілот і розширення

Почніть з одного репозиторію і обмеженого періоду, наприклад кількох тижнів активної розробки. Оберіть репозиторій із регулярними pull request середнього розміру: на дуже малих змінах ШІ мало що додасть, а на величезних його зауваження важко перевірити.

Перед стартом зафіксуйте вихідний рівень: скільки часу зазвичай проходить від відкриття PR до першого відгуку і до злиття, скільки дефектів знаходять після злиття. Під час пілоту порівнюйте схожі PR: однакового типу, розміру і складності. Порівняння «великий рефакторинг до» і «маленький фікс після» нічого не покаже.

Заздалегідь визначте, коли шум переважає користь. Типові сигнали:

• розробники перестали читати зауваження ШІ і закривають їх пачками;
• частка підтверджених зауважень залишається низькою, а серед підтверджених немає жодного важливого;
• час на розбір хибних зауважень більший, ніж час, зекономлений на зведенні змін і нагадуваннях;
• зауваження ШІ системно дублюють сповіщення статичного аналізу.

Якщо сигнали шуму з’явилися, не обов’язково відмовлятися від інструмента. Спочатку спробуйте звузити задачу: уточнити інструкції, вимкнути повторне рев’ю на кожен коміт, обмежити рев’ю певними типами файлів. Якщо і після цього користь не перевищує витрат, пілот варто зупинити — це теж корисний результат.

Підсумок і перші кроки

ШІ-рецензент корисний, коли він доповнює наявні перевірки, а не замінює їх. Його зауваження — привід перевірити, а не вирок. Рішення про розширення ухвалюється за підтвердженими дефектами, часом команди і рівнем шуму, а не за кількістю коментарів.

Що можна зробити на своєму процесі вже зараз:

1. Перелічити обов’язкові перевірки, які діють сьогодні, і письмово зафіксувати, що ШІ-рев’ю жодну з них не замінює.
2. Перевірити свій тариф і налаштування репозиторію: які функції рев’ю і статичного аналізу реально доступні.
3. Обрати один репозиторій для пілоту, вимкнути для ШІ будь-які права на схвалення чи злиття, перевірити підключені інструменти.
4. Записати правила команди у файли інструкцій і призначити їм власника.
5. Домовитися про мітки «підтверджено» / «не підтверджено» та облік хвилин на розбір.
6. Зібрати розмічену вибірку PR із відомими дефектами, щоб рахувати пропуски.
7. Через обраний період порівняти схожі PR і прийняти рішення: розширити, звузити задачу або зупинити.

Якщо вам потрібно визначити межі такого технічного пілоту — які репозиторії включити, які критерії перевірки зафіксувати, хто відповідатиме за супровід інтеграції, — команда BotLabs може розібрати з вами ваш процес рев’ю і допомогти сформулювати перший реалістичний крок.

Часті запитання