Перевірка коду, написаного AI: чому ми тестуємо його в чистому клоні

🎲 Ризик у коді, якого ви не писали

Vibe coding означає приймати згенерований код, бо він начебто працює. Це швидко, і для одноразового скрипта цілком годиться. Проблеми починаються, коли та сама звичка переходить у спільний код. Агент працює у вашому робочому дереві, де лежать змінені й незакомічені файли, локальні налаштування та закешовані результати. Тести, які він запускає, усе це бачать. Колега, який зробить checkout цього коміту, не побачить нічого з цього.

🧾 Один інцидент у числах

14 жовтня 2026 року агент переніс у git модуль аналітики на 1 123 рядки зі знімка живого сервера. У робочому дереві модуль пройшов 56 тестів із 56. У чистому клоні того самого коміту він провалив 10 із 56, бо залежав від незакомічених правок у сусідньому файлі. Коміт відкотили того ж дня. Далі сталася друга похибка: команда відкату не має тихого прапорця, перша спроба не вдалася, а потім amend переписав чужий коміт.

У діфі нічого не виглядало неправильно. Збій був у тому, чого діф не містив.

🔍 Процедура рев’ю

Прочитати діф необхідно, і цього недостатньо. У нашій процедурі п’ять брам.

1. Обсяг. Чи торкається діф лише тих файлів, які названі в завданні? Неочікувані шляхи, видалені файли та змінені режими — перше, на що варто дивитися.
2. Читання. Чи може рев’юер пояснити, що робить кожна нова функція і що вона повертає на некоректних даних? Якщо ні, код ще не прийнято.
3. Чистий клон. Створіть свіже робоче дерево від цільової гілки, застосуйте лише цей коміт і запустіть там тести. Успіх у робочому дереві не зараховується.
4. Коди виходу. Запускайте команду тестів без конвеєра. pytest | tail -1 && git commit закомітить на червоному, бо код виходу належить tail.
5. Готовність до відкату. Знайте команду, яка скасовує зміну, ще до мерджу, і перевірте її на одноразовій гілці.

🛠️ Практика: налаштуйте браму чистого клону

1. Виберіть один репозиторій, у який пишуть агенти.
2. Напишіть короткий скрипт, який створює тимчасове робоче дерево від цільової гілки, застосовує коміт-кандидат, запускає набір тестів і прибирає робоче дерево.
3. Зробіть так, щоб скрипт завершувався з ненульовим кодом у разі будь-якого провалу тестів і в разі неочікуваного файлу у виводі статусу.
4. Запустіть його на останніх п’яти комітах агента. Запишіть, скільки з них провалюються.
5. Зробіть скрипт обов’язковим кроком перед мерджем. Успіх у дереві автора — це інформація, а не схвалення.
6. Додайте правило в інструкції для вашого агента: «покажи результат чистого клону, а не локальний».

✅ Перевірте себе

• Візьміть коміт, який залежить від незакоміченого файлу. Скрипт падає й називає відсутній імпорт або файл.
• Внесіть тест, що провалюється, і запустіть браму через конвеєр. Брама все одно падає, бо ви читаєте код виходу самої команди тестів.
• Нова людина може запустити браму з README менш ніж за п’ять хвилин.
• Ви можете сказати, який з останніх десяти комітів агента торкався шляху, не названого в завданні.

🚧 Коли це не працює

• Тести, які не перевіряють поведінку. Чистий клон зі слабкими тестами дає чистий успіх для зламаного коду. Агенти також пишуть ті тести, які проходять.
• Залежності від середовища. Тест, якому потрібна база даних, ключ чи хост, не пройде в свіжому робочому дереві. Позначте його явно і запускайте там, де це є, і не «виправляйте» це підробленими даними.
• Великі діфи. Після кількох сотень рядків людське рев’ю перетворюється на перегляд по діагоналі. Просіть менші зміни.
• Згенерований код, до якого ви більше ніколи не повернетеся. Одноразовий скрипт може й не заслуговувати на браму. Вирішіть це свідомо.
• Рев’ю тією самою моделлю. Модель, яка написала код, часто з ним погоджується. Спершу використайте детерміновану перевірку, потім — іншого рев’юера.

📊 Докази

➡️ Далі

Запишіть критерії приймання до початку роботи в Розробка за специфікацією з наявними пакетами завдань, а про те, чому заява про успіх не є доказом, читайте в Суддівство AI.

Джерела

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