Що перевірити першим
Почніть не з рядків коду, а з питання: чи зміна робить рівно те, що обіцяє назва PR.
- Чи змінився тільки заявлений модуль або флоу.
- Чи немає зайвих файлів, масових форматувань або випадкових змін.
- Чи не підмінив AI бізнес-логіку “зручним” спрощенням.
Якщо scope розповзся, попросіть агента зупинитися і пояснити кожну позацільову зміну окремо.
Другий прохід: чи це взагалі працює
Тут не треба ловити всі стилістичні огріхи. Шукайте речі, які зламають користувача або тестовий pipeline.
- Чи є негативні сценарії, а не тільки happy path.
- Чи оновлені або додані тести під нову поведінку.
- Чи не покладається код на приховані значення, порядок виконання або локальний стан.
Одна з типових пасток AI-PR: код виглядає переконливо, але тестує тільки той шлях, який автор сам собі й придумав.
Третій прохід: maintainability і security
Коли функціональність начебто правильна, перевірте, чи PR не створює борг на наступний спринт.
- Чи назви змінних і функцій пояснюють намір.
- Чи немає дублювання, яке можна винести в невеликий helper.
- Чи не зʼявились секрети, токени, прямі URL або небезпечні припущення про вхідні дані.
- Чи не розширився доступ до даних або прав “на всякий випадок”.
Якщо AI зробив код, який важко буде змінювати через два тижні, це вже причина повернути PR назад, навіть якщо він проходить тести.
Коли відправляти назад без дискусії
Відправляйте PR на доопрацювання, якщо бачите хоча б один із цих сигналів:
- PR робить більше, ніж заявлено.
- Тести не покривають нову поведінку.
- Є приховане припущення про формат даних, час або порядок викликів.
- У коді зʼявився security short-cut: “потім закриємо”, “тут і так внутрішнє”, “це лише для деву”.
Коротко
AI-згенерований PR часто виглядає готовим швидше, ніж його встигають перевірити. Не намагайтеся “прочитати все”. Краще пройти три короткі питання: чи це потрібна зміна, чи вона працює, і чи не створює новий ризик.
Якщо відповідь хоча б на одне з них “ні”, поверніть PR назад і попросіть агента локалізувати правку та добити тести.
Короткий чеклист
- Перевірити, чи PR не вийшов за межі заявленої задачі.
- Знайти докази для correctness-ризиків прямо в diff.
- Переконатися, що є тест на нову поведінку.
- Перевірити хоча б один negative або edge-case сценарій.
- Окремо пройти maintainability і security припущення.
- Дати явне рішення: approve, request changes або block.
Prompt Pack: перевірити AI-згенерований pull request без сліпої довіри
Ти ревʼюїш pull request, який написав AI-агент. Контекст: - Мета зміни: [опиши одним реченням] - Змінені файли: [встав список файлів] - Тести: [встав релевантні тести або напиши "немає"] - Зона ризику: [scope / correctness / maintainability / security / інше] Зроби таке: 1. Знайди все, що виходить за межі заявленої мети. 2. Назви 3 головні correctness-ризики й покажи точні докази в diff. 3. Перевір, чи тести доводять нову поведінку, включно з негативним кейсом. 4. Вкажи maintainability або security проблеми. 5. Дай рішення: approve, request changes або block. Формат відповіді: - Scope issues - Correctness risks - Test gaps - Maintainability/security notes - Decision and why