Ключові висновки

Обсяг перемагає ємність. Коли агент закриває три задачі за годину, а рев'юер — одну за той самий час, з'являється борг перевірки: черга росте, стандарти падають, «зелений CI» підміняє осмислений погляд.

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

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

Процес важливіший за героїзм рев'юера. Малі запити на злиття, обов'язкові людські шлюзи на небезпечних шляхах, ШІ як незалежний критик і явні правила «легке / глибоке рев'ю» масштабуються краще, ніж «нехай старший усе читає».

Швидкість генерації без економіки перевірки — прискорення інцидентів. Зв'язка з тестуванням, агентною інженерією і безпекою ШІ визначає, чи стане агент прискорювачем, чи джерелом прихованого боргу.

Чому рев'ю зламалося від обсягу агентних змін

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

Агенти порушили баланс. Cursor, Copilot, фонові виконавці та CLI-агенти за один цикл змінюють десятки файлів, дописують тести «під зелений статус» і оформлюють запит на злиття з упевненим описом. Рев'юер отримує не «невеликий патч колеги», а пачку змін, яку машина зібрала швидше, ніж людина встигає відновити намір.

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

Важливий нюанс: проблема не в тому, що модель «погано пише». Часто пише прийнятно. Проблема в тому, що пропускна здатність генерації зросла швидше за пропускну здатність відповідальності. Команда оптимізувала введення, залишивши вузьке місце на виході.

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

Що ШІ вміє перевіряти — і що лишається за людиною

Корисно розділити ролі явно. Інакше команда або забороняє ШІ-рев'ю (і тоне в черзі), або довіряє йому все (і отримує впевнені, але сліпі злиття).

Сильні сторони моделі як першого проходу

Модель ефективна там, де є локальний сигнал і повторюваний шаблон:

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

Це економить час людини на шум. Але це не доказ безпеки зміни.

Зона відповідальності людини

Людина зобов'язана володіти класами ризику, де помилка дорожча за час рев'ю:

Архітектура і межі модулів. Агент любить «зручний» імпорт через нутрощі сусіднього сервісу, спільний утилітний модуль «про всяк випадок» і приховану зв'язність. Рев'юер перевіряє: зміна поважає межі чи розмиває їх.

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

Ізоляція орендарів і дані. Витік tenant_id, спільний кеш без ключа орендаря, запит без фільтра власника — класика агентних патчів у багатоорендних продуктах. Виглядає як дрібний дефект; коштує як інцидент рівня компанії.

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

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

Прийняття ризику. Злиття — рішення, а не кнопка. Хтось уповноважений сказати: «у такому вигляді в прод не можна».

Контрольний список після різниці змін агента

Нижче — робочий порядок для рев'юера. Його можна скорочувати для низького ризику, але не можна пропускати пункти на високому.

1. Збіг із наміром

Відкрийте задачу й опис запиту на злиття до коду. Потім запитайте: чи ця зміна розв'язує заявлену проблему — чи сусідню, яку модель вважала «схожою»?

Типовий збій: задача «полагодити пагінацію», агент «заодно» переписав кеш і перейменував API. Різниця змін велика й «красива», але намір розмито. Або відкотіть зайве, або розбийте на два запити.

Перевірте виключене: що задача явно не просила. Агенти схильні розширювати обсяг під виглядом «покращень».

2. Витоки меж

Дивіться імпорти, нові залежності, прямі звернення до чужих таблиць і внутрішніх API. Шукайте:

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

Пов'язаний контекст щодо безпечної розробки — у гайді з безпечної розробки ШІ.

3. Тести, які стверджують потрібне

«Зелений CI» після агента — слабкий сигнал. Модель часто пише тести, що підтверджують її ж реалізацію: моки надто широкі, твердження на деталі реалізації, немає негативних сценаріїв.

Рев'юер перевіряє:

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

Економіку хибного спокою розібрано в статті про економіку тестування і ціну відмови.

4. Секрети, журнали й витік даних

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

Окремо: чи не потрапили внутрішні інструкції, правила репозиторію або фрагменти чужих тікетів у користувацький вивід чи публічні артефакти.

5. Промпт і дані в системах із LLM

Якщо зміна стосується RAG, агентів чи чату: перевірте ізоляцію контексту, фільтри на вході, заборону на виконання інструментам без авторизації. Ін'єкція інструкцій у промпт у проді — не екзотика; див. розбір ін'єкцій у промисловому середовищі і обмежувачі ШІ.

6. «Виглядає зеленим», але крихко

Ознаки крихкого пакета зміни:

• нестабільні тести, перезапуски CI «поки не пройде»;
• тести лише на щасливий шлях;
• відсутність перевірки міграції «вгору/вниз»;
• зміни в генерації коду без перевірки споживачів;
• оновлення залежностей «заодно» без оцінки ризику зі списку змін.

Як перебудувати процес рев'ю під агентів

Контрольний список без процесу не масштабується. Потрібна системна перебудова.

Менший обсяг на один запит на злиття

Правило: агент може генерувати швидко, але зливати потрібно малими інкрементами. Один запит — одна перевірювана гіпотеза. Міграція окремо від можливості. Рефакторинг окремо від поведінки. Так рев'юер зберігає робочу пам'ять, а відкат лишається дешевим.

Практика: у правилах агента (AGENTS.md, навички) явно обмежувати число файлів і забороняти «заодно почисти репозиторій».

Обов'язкові людські шлюзи на небезпечних шляхах

Не все потребує однакової глибини. Але деякі шляхи — завжди людина:

• авторизація, білінг, платежі, персональні дані;
• міграції схеми й скрипти видалення;
• політики доступу й мультитенантність;
• інфраструктура й секрети;
• публічні API зі зворотною сумісністю.

Технічно це CODEOWNERS, обов'язкові рев'юери, окрема мітка високого ризику, блокування автозлиття.

ШІ як скептик, людина як фінал

Корисний контур:

1. Автор (людина або агент) готує пакет зміни з доказами.
2. ШІ-рев'юер проходить як незалежний критик з іншим промптом і, за можливості, іншою моделлю: шукає ризики, діри в тестах, розходження із задачею.
3. Людина читає зведення ризиків + критичні файли й приймає рішення про злиття.

Помилка антипатерну: та сама модель, що писала код, «рев'ює» свій патч у тому ж чаті. Спільні припущення проходять обидва шари. Незалежність важливіша за «розумність».

Черга і метрики боргу перевірки

Вимірюйте не лише час до злиття, а:

• вік відкритих запитів на злиття;
• частку схвалень без коментарів на шляхах високого ризику;
• число відкатів і гарячих виправлень після агентних змін;
• середнє число файлів на запит.

Якщо генерація прискорилася, а ці метрики погіршилися — ви купили швидкість ціною боргу.

Окремо варто зафіксувати культуру опису запиту на злиття. Шаблон «що зроблено / як перевірено / що не перевірено / як відкотити» знижує когнітивне навантаження рев'юера сильніше за будь-якого «розумного» бота. Агент може заповнити чернетку шаблону; людина зобов'язана підтвердити правду в полях «не перевірено» і «відкат».

Зв'язок із моделлю агентної розробки — в агентній інженерії 2026 і в тексті де генерація коду закінчується і починається інженерія.

Правила команди: легке і глибоке рев'ю

Команді потрібна явна домовленість, інакше кожен рев'юер вигадує свій стандарт під тиском черги.

Коли достатньо легкого рев'ю

Умови (усі разом):

• зміна локальна (1–3 файли, один модуль);
• немає авторизації, даних орендарів, міграцій, секретів, публічних контрактів;
• є цілеспрямований тест на поведінку;
• ШІ-скептик не підняв знахідок високої тяжкості;
• автор — людина, яка розуміє ділянку, або агент під жорстким шаблоном задачі.

Легке рев'ю: прочитати опис і різницю змін цілком, пробігти контрольний список «намір / межі / тести», злити. Мета — не героїзм, а не витрачати старший ресурс на низький ризик.

Коли обов'язкове глибоке рев'ю

Будь-який із тригерів:

• понад N файлів або торкання кількох підсистем;
• шляхи, чутливі до безпеки;
• зміна контрактів, схем, черг;
• агент працював без жорстких меж каталогів;
• тести згенеровані тим самим агентом без негативних сценаріїв;
• терміновість («треба вчора») — навпаки привід поглибити, а не прискорити злиття.

Глибоке рев'ю: критичні шляхи рядок за рядком, модель загроз на зміну, перевірка тверджень тестів, план відкату, друга людина на високому ризику за потреби.

Ролі

Автор відповідає за пакет: намір, межі, докази, список відомих прогалин. «Агент зробив» — не зняття відповідальності.

ШІ-критик відповідає за повноту першого проходу і явну ескалацію.

Рев'юер-людина відповідає за вердикт і за те, що небезпечні класи не пропущені.

Тімлід / власник зони відповідає за правила маршрутизації легкого/глибокого і за CODEOWNERS.

Зв'язок із тестуванням, агентною інженерією і безпекою

Рев'ю в епоху ШІ не можна ізолювати від сусідніх контурів.

Тестування. Якщо тести дешеві й кажуть правду про ризик, рев'юеру легше довіряти «зеленому». Якщо тести дорогі, рідкісні або підтверджують реалізацію агента, рев'ю стає єдиною лінією оборони і ламається під обсягом. Див. економіку тестування.

Агентна інженерія. Якість рев'ю починається до різниці змін: постановка задачі, межі каталогів, критерії готовності, мінімальні права. Погана задача народжує патч, який неможливо чесно перевірити. Див. агентну інженерію.

Генерація vs інженерія. Швидкість набору тексту не дорівнює готовності до проду. Рев'ю — момент, де ця різниця стає явною. Див. де закінчується генерація.

Безпека ШІ. Нові поверхні — промпти, інструменти, RAG, журнали моделі — потребують тих самих людських шлюзів, що й класична авторизація. Див. безпечну розробку ШІ, ін'єкції в промпт, обмежувачі.

Чистота коду. Агент часто пише «читабельно», але порушує зв'язність і абстракції. Класичні принципи досі допомагають рев'юеру бачити запахи — див. вижимку «Чистий код».

Типові помилки команд

Вважати «зелений CI» рев'ю. CI відповідає на питання «чи зламали ми відомі перевірки». Рев'ю відповідає на «чи потрібно це зливати».

Просити ту саму модель схвалити свій патч. Немає незалежності — немає другої думки.

Рев'ювати лише стиль. Після агента стиль часто вже вирівняно правилами. Справжній ризик — у межах і даних.

Заборонити агентів через інцидент. Тіньове використання лишиться без правил. Краще шлюзи й маршрутизація ризику.

Однаковий норматив часу рев'ю на все. Або черга вб'є швидкість, або високий ризик проскочить. Розділяйте легке і глибоке.

Не вимагати від автора списку ризиків. Агент не залишає записку «що не перевірено». Людина-автор зобов'язана.

Зливати гігантський рефакторинг «тому що агент впорався». Впорався з генерацією, не з відповідальністю за систему.

Плутати швидкість прийняття патча зі швидкістю поставки цінності. Злитий код, який через день відкочують, — від'ємна швидкість. Рев'ю, яке запобігло інциденту, прискорює продукт, навіть якщо «затримало» один запит на злиття.

Що зробити сьогодні

Практичний мінімум на один-два тижні:

1. Увести два маршрути рев'ю в команді: легкий і глибокий — із письмовими тригерами.
2. Додати CODEOWNERS / обов'язкових рев'юерів на авторизацію, білінг, міграції, ізоляцію орендарів.
3. Обмежити агента в правилах: максимум файлів, заборона «заодно», обов'язковий список доказів в описі запиту на злиття.
4. Підключити ШІ-критика окремим кроком (інша модель або інший промпт), не в тому ж чаті генерації.
5. Вставити контрольний список із цієї статті в шаблон опису запиту на злиття (список автора + список рев'юера).
6. Виміряти борг перевірки: вік запитів, частка без коментарів на високому ризику, відкати після агентних злиттів.
7. Провести одне розбірне рев'ю великої різниці змін агента всією командою — як калібрування стандарту.

Не потрібно чекати ідеального процесу. Потрібно закрити найдорожчий клас помилок наступного тижня.

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

Чи замінює ШІ рев'ю коду?

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

Чи можна зливати агентний патч без людини, якщо CI зелений?

Лише у вузькому контурі з жорсткими межами, низьким ризиком і заздалегідь узгодженою політикою автозлиття. Для авторизації, даних, міграцій і публічних контрактів — ні.

Чому тести від агента часто брешуть?

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

Що дивитися насамперед у великій різниці змін?

Спочатку намір і межі, потім критичні шляхи (авторизація, дані, міграції), потім якість тверджень тестів. Стиль — наприкінці, якщо взагалі.

Чи потрібен окремий промпт для ШІ-рев'юера?

Так. Критик має шукати діри, а не підтверджувати красу. Інакше ви отримуєте ввічливе відлуння автора.

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

Метриками інцидентів і явними правилами: за хвилинне схвалення на високому ризику — ескалація процесу, не героїзм швидкості.

Що робити з чергою рев'ю при зростанні агентної генерації?

Зменшувати розмір запитів, маршрутизувати легке/глибоке, підсилювати автоперевірки на низькому ризику, а не вимагати від людей читати все однаково глибоко.

Чи пов'язане рев'ю коду з ін'єкцією в промпт?

Так, якщо зміна зачіпає контур LLM: інструменти, RAG, журнали, системні промпти. Тоді рев'ю — частина моделі загроз, не лише стилю коду.

Скільки часу має займати глибоке рев'ю?

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

Чим відрізняється рев'ю агентного коду від рев'ю людини?

Обсяг і впевнений тон вищі, а «знання чому» нижчі. Тому сильніший акцент на доказах, межах і незалежному критику.

Подальше читання

• Як Cursor та інші IDE працюють із кодом
• Агентна інженерія у 2026 році
• Де закінчується генерація коду і починається інженерія
• Економіка тестування і ціна відмови
• Обмежувачі ШІ у 2026
• Ін'єкція в промпт у промисловому середовищі
• Безпечна розробка корпоративного ШІ
• «Чистий код»: ключові ідеї

Висновок

В епоху агентів рев'ю коду — не ритуал ввічливості і не суперечка про дужки. Це система обмеження шкоди за різко зрослої швидкості генерації. Людина не зобов'язана читати кожен рядок однаково уважно — вона зобов'язана не віддавати машині класи ризику, де ціна помилки системна.

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

Коротко про підхід лабораторії: перевірюваний результат важливіший за впевнений патч — див. Хімія коду.