GitHub Copilot Code Review: як перевірити AI-код перед злиттям

Що таке Copilot Code Review

Це функція GitHub, яка аналізує зміни у pull request або в редакторі, залишає коментарі з рівнями важливості та, де можливо, пропонує конкретні виправлення. Простими словами: ви відокремлюєте нову роботу в гілку, показуєте різницю з основною версією проєкту й просите AI пошукати проблеми до злиття.

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

Якщо потрібно однаково перевіряти багато файлів, розподіляти їх між кількома агентами й збирати спільний звіт, використовуйте нові GitHub Copilot Dynamic Workflows. Звичайний Code Review залишається простішим вибором для одного pull request.

Що змінилося у вересні 2026 року

GitHub оновив інтерфейс і логіку рев’ю. Підсумковий коментар тепер показує поточну оцінку pull request, використаний рівень глибини та згруповані результати. Copilot точніше закриває власні зауваження після нових комітів і може позначити причину як Won't Fix або Incorrect. Якщо прийняти кілька сумісних пропозицій пакетом, GitHub генерує змістовне повідомлення коміту.

23 вересня з’явилася окрема сторінка персональних налаштувань Code Review для всіх платних планів Copilot. У ній можна ввімкнути автоматичне рев’ю під час створення pull request, виходу з draft, нових push і навіть чернеток, а також задати власний типовий рівень перевірки. Для підприємств доступний спільний типовий рівень із можливістю перевизначення на рівні організації або репозиторію.

Покроково: від AI-правки до злиття

1. Створіть окрему гілку. Не давайте агенту працювати прямо в main. Назва на кшталт feature/contact-form одразу пояснює мету.
2. Перевірте зміни локально. Запустіть застосунок, тести, лінтер і збірку. AI-рев’ю не замінює виконання коду. Якщо проєкт не збирається, спершу виправте це.
3. Відкрийте pull request. Напишіть, що змінено, навіщо, як перевіряли та які ризики бачите. Добрий опис дає Copilot і людині однаковий контекст.
4. Додайте Copilot у Reviewers. Оберіть рівень перевірки: Lite для невеликої звичайної зміни або Balanced для складної логіки, авторизації, платежів, міграцій та взаємодії кількох сервісів. Не покладайтеся на напис Default: із 28 вересня він означає Balanced.
5. Читайте причину, а не лише готовий патч. Для кожного коментаря перевірте файл, сценарій помилки й наслідки. Якщо пропозиція правильна — прийміть її окремо або разом із сумісною групою.
6. Повторіть тести. Після прийняття виправлення знову запустіть перевірки. Навіть коректна локальна правка може зламати інший сценарій.
7. Запросіть повторне рев’ю. Натисніть повторний запит біля Copilot у списку рецензентів або відкрийте Profile → Copilot settings → Code review і ввімкніть автоматичну перевірку нових push.
8. Залучіть людину до критичних змін. Для доступу до даних, авторизації, платежів, інфраструктури та production-конфігурації потрібне людське рішення, навіть якщо Copilot не знайшов проблем.

Lite чи Balanced

Поточне правило GitHub: з 28 вересня значення Default дорівнює Balanced для нових і наявних репозиторіїв та організацій. Ручний запит через блок Reviewers усе ще дозволяє разово вибрати інший рівень.

За поточними оцінками GitHub, одне рев’ю зазвичай споживає AI credits орієнтовною вартістю від $0.05 до $1 у Lite і від $0.25 до $5 у Balanced. Сума залежить від розміру pull request та інструкцій репозиторію й може змінюватися; хвилини GitHub Actions рахуються окремо.

Дайте Copilot правила вашого проєкту

Без контексту AI бачить загальні практики. З контекстом він може перевіряти саме ваші правила: допустимі залежності, формат помилок, обов’язкові тести та межі безпеки. Для правил усього репозиторію додайте файл .github/copilot-instructions.md.

# Правила рев’ю

- Не приймай секрети або API-ключі з клієнтського коду.
- Для кожного нового API-маршруту перевіряй авторизацію і валідацію вводу.
- Не додавай нові залежності без пояснення в pull request.
- Для виправлення бага вимагай тест, який відтворює проблему.
- Відповідай коротко: ризик, сценарій відтворення, мінімальна правка.

Для окремих директорій можна використовувати файли .github/instructions/*.instructions.md, а спільні правила для різних AI-агентів — зберігати в AGENTS.md. Важливий нюанс: під час рев’ю Copilot читає інструкції з гілки зі змінами. Отже, нове правило можна перевірити в тому самому pull request, але й ненавмисно послаблене правило теж потрапить у контекст.

Шаблон опису pull request

Скопіюйте цей каркас у опис PR. Він корисний і для Copilot, і для людського рецензента:

Що Copilot не перевірить замість вас

• Повну правильність продукту. Функція може бути технічно акуратною, але вирішувати не ту проблему.
• Усі типи файлів. GitHub зазначає, що з рев’ю виключаються, зокрема, файли керування залежностями, журнали та SVG. Для них потрібні окремі перевірки.
• Реальну поведінку середовища. Рев’ю коду не замінює запуск тестів, перевірку мобільної версії, доступності чи production-конфігурації.
• Кожну вразливість. GitHub прямо попереджає, що Copilot може пропускати проблеми й помилятися.

Якщо рев’ю використовує GitHub Actions, агентні навички або MCP-сервери, перевіряйте, який зовнішній контекст був залучений. Не давайте інструменту доступу до систем, які не потрібні для цієї перевірки. А перед публікацією переконайтеся, що у змінах немає секретів — для цього скористайтеся нашим чеклістом безпеки API-ключів.

Як перевірити зауваження Copilot

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

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

Короткий чекліст перед Merge

• Зміни зроблені в окремій гілці, а не прямо в main.
• Pull request має конкретну мету й не змішує кілька незалежних задач.
• Збірка, тести й лінтер пройшли після останніх правок.
• Для складного або чутливого коду обрано Balanced, для простого — Lite.
• Перевірено персональний або репозиторний default: для дрібних рев’ю свідомо обрано Lite або підтверджено потребу в Balanced.
• Кожна пропозиція Copilot перевірена, а не прийнята автоматично.
• Після виправлень виконано повторне рев’ю актуального коміту.
• Секрети, журнали, залежності й виключені типи файлів перевірені окремо.
• Критичні зміни переглянула відповідальна людина.

Поширені запитання

Чи доступний Code Review безкоштовно?

Copilot Code Review входить до платних планів Copilot. Учасники організації без окремої ліцензії можуть отримати доступ на GitHub.com, якщо адміністратор увімкнув потрібні політики та оплату AI credits. Безкоштовний план Copilot не містить власної місячної квоти для цієї функції.

Чи можна одразу застосувати виправлення?

Так. Доступні окремі та пакетні пропозиції, а також передача задачі Copilot cloud agent через Fix with Copilot. Але після будь-якої автоматичної правки потрібно перечитати diff і повторити тести.

Чи замінює це людське рев’ю?

Ні. Найкраща роль Copilot тут — перший фільтр, який знаходить очевидні й частину неочевидних проблем до того, як код перегляне людина.