Чи варто все ще переглядати код вашого AI-агента?

Аргумент починається однаково в кожній команді. Одна сторона каже, що агенти тепер відправляють чистіший код, ніж половина pull-запитів, які ми раніше схвалювали без зайвих питань, тож чому ми все ще читаємо кожен рядок? Інша сторона каже, що ми ті, хто підписує.

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

Аргументи за відправку без читання кожного рядка

Почніть з найсильнішої версії оптимістичного аргументу, тому що він сильніший, ніж визнають більшість рецензентів.

На завданні з чіткою специфікацією та тестовим набором сучасний агент кодування створює більш послідовний код, ніж середній розробник, що працює під тиском дедлайну. Він не нудьгує на шляху помилки. Він пише перевірку на null о 18:00 в п'ятницю. Він дотримується проектних конвенцій, які йому дали, кожного разу, без тих маленьких тихих бунтів, які втомлений розробник дозволяє собі.

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

Потім є обсяг. Один розробник, що запускає п'ять агентів паралельно, генерує більше diff на годину, ніж будь-яка людина може уважно прочитати. Якщо ваше правило - "читати все", ви тихо встановили себе знову як вузьке місце, яке ви щойно автоматизували. Людина, що швидко переглядає 900-рядковий diff, створює підпис без створення знань, і це гірше, ніж не переглядати взагалі, тому що це створює впевненість там, де її немає.

Аргументи за збереження людини на diff

Тепер інша сторона, яка також сильніша, ніж визнають ентузіасти.

Відповідальність не передається. Модель не отримує виклик о 3 ранку. Вона не бере участь в огляді інциденту, не спілкується з клієнтом, чиї дані були розкриті, і не несе наслідків зміни в наступному кварталі. Той, хто зливає, несе відповідальність за результат, і перегляд - це спосіб здійснення власності, а не просто декларація.

Агенти-рецензенти помиляються в тому ж напрямку, що й агенти-автори. Це аргумент, який насправді вирішує пропозицію "просто дайте іншому агенту переглянути це". Два агенти з однієї сім'ї моделей, що отримали один і той же контекст, мають спільні пріоритети, спільні навчальні дані та спільні сліпі зони. Їхні помилки корелюють. Другий агент із задоволенням виявить відсутній тест або необроблену помилку, і із задоволенням схвалить тонке непорозуміння вашої доменної області, яке спричинило помилку в першу чергу, тому що він зробив те ж саме непорозуміння. Два рецензенти, які помиляються в одному напрямку, не складаються в огляд.

Вимірювання теж не лестять. Дані індустрії показують, що рецензенти обмінюються значно більше раундами на змінах, згенерованих AI, ніж на написаних людьми: код прибуває швидше і займає більше часу, щоб стати довіреним. Дослідження січня 2026 року пішло далі і виявило, що зміни, згенеровані агентами, несуть більше надлишковості та більше накопиченого технічного боргу на зміну, ніж написані людьми, в той час як рецензенти повідомляють, що почуваються краще про їх схвалення. Цей розрив, між тим, наскільки добре код відчувається і наскільки добре він є, є всім ризиком в одному реченні.

Дебати сформульовані неправильно

Ось переформулювання, яке закінчує зустріч.

Ви не переглядаєте код, тому що не довіряєте автору. Ви переглядаєте його, тому що ви той, хто підписує. Це абсолютно різні дії, і весь аргумент походить від їх плутанини.

Коли ви бачите це таким чином, "чи агент краще, ніж людина" перестає бути вирішальним питанням. Вирішальне питання: якщо ця зміна неправильна, наскільки дорого це виявити, і наскільки дорого це скасувати? Помилка в заголовку маркетингу виявляється за секунди і скасовується за секунди. Інверсія перевірки дозволів в проміжному програмному забезпеченні авторизації виявляється клієнтом або регулятором, і вона ніколи не скасовується насправді, тому що до того часу дані вже були прочитані.

Отже, відповідь не "переглядати все" і не "довіряти агенту". Це:

Ви припиняєте переглядати рядки. Ви починаєте переглядати ризик.

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

Як виглядає "агент помилився" насправді

Найкорисніше, що ви можете повернути своїй команді, це не думка, це список об'єктивних ознак. Не "код відчувається неправильним", а сигнали, які ви можете перевірити на diff за менше ніж хвилину. Ось ті, що заслужили своє місце.

1. Тести змінилися в тому ж коміті, що й код, який вони покривають. Зелений був створений, а не спостережений. Це найвищий сигнал у списку, і це те, що потрібно перевірити першим.
2. Твердження було ослаблено або тест був відключений. skip, only, твердження розширено, щоб прийняти те, що новий код випадково повертає, try/catch, що поглинає помилку, яку тест повинен був виявити.
3. Diff більший, ніж завдання. Файли, про які ніхто не просив, були змінені. Розширення обсягу в агенті - це не ентузіазм, це знак, що агент десь по дорозі переосмислив мету.
4. Вигадана поверхня. Метод API, опція конфігурації або шлях, якого не існує. Це компілюється в голові агента і ніде більше.
5. Середовище було виправлено замість коду. Жорстко закодований абсолютний шлях, значення, специфічне для машини, особистий токен, ім'я користувача. Симптом зник на машині агента і перемістився на всі інші.
6. Залежність з'явилася без запиту. Новий ланцюг постачання, нова ліцензія, нова поверхня обслуговування, вирішена чимось, що не буде її обслуговувати.
7. Дублювання замість повторного використання. Він повторно реалізував допоміжний засіб, який вже існував за двадцять рядків. Це механізм, що стоїть за виміряним боргом: кожна зміна виглядає локально розумною, і кодова база тихо набуває третього способу зробити те саме.
8. Резюме не відповідає diff. "Виправлено і протестовано", коли жоден тест не був запущений. Оповідання генерується з тією ж впевненістю, незалежно від того, чи була виконана робота, тому розглядайте його як претензію для перевірки, а не як звіт.
9. Інструкції перестали виконуватися. Маленькі конвенції, що тихо випали, це те, як сесія деградує, перш ніж вона починає галюцинувати відверто. Якщо ви використовуєте канарку у вашому контекстному файлі, це саме те, що вона повинна виявити.
10. Чутлива область була зачеплена мимохідь. Читання .env, новий вихідний мережевий виклик, новий рядок журналу, що містить дані користувача, міграція, включена в коміт функції.

Зверніть увагу, що не входить до списку: стиль, іменування, форматування, "я б зробив це по-іншому". Це завжди була найслабша частина людського огляду, і тепер вони дійсно є марною тратою людських ресурсів. Видаліть їх з вашого огляду, і ви повернете увагу, необхідну для десяти пунктів вище.

Скільки огляду заслуговує зміна?

Радіус вибуху, а не розмір diff, вирішує. Таблиця, яку ваша команда може прийняти сьогодні вдень:

Розмір diff говорить вам, скільки часу займає огляд. Радіус вибуху говорить вам, чи є він обов'язковим.

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

Якщо ваш продукт обробляє особисті дані в Європі, ще один рядок написаний для вас законом, а не смаком: що має поважати функція, створена AI, відповідно до GDPR - це не питання судження, і "агент це написав" ніколи не було захистом.

Що змінюється, коли п'ять агентів працюють одночасно

Все вище передбачає, що ви можете бачити зміну. З паралельними агентами це припущення ламається першим, і воно ламається в специфічний спосіб: diff перестає мати одного автора. Три агенти торкнулися робочого дерева з моменту вашого останнього коміту, і питання "хто змінив цей файл, і в рамках якого завдання" більше не має очевидної відповіді. Огляд без атрибуції - це не огляд, це археологія.

Це проблема інструментів, і це причина, чому AgentsRoom розміщує огляд там, де агенти, а не в кінці pull-запиту:

• Режим огляду показує кожну зміну, яку зробили ваші агенти, у вигляді читабельного diff, до того, як щось буде закомічено. Це крок "прочитайте diff пропорційно до радіусу вибуху", зроблений досить дешевим, щоб люди дійсно це робили.
• Огляд за агентом фільтрує цей diff за агентом і дозволяє вам комітити роботу кожного агента окремо. П'ять паралельних агентів стають п'ятьма оглядовими одиницями замість одного нечитаємого робочого дерева, і погана зміна залишається прив'язаною до завдання, яке її створило.
• Повідомлення коміту генерується з реального diff з кнопкою блиску на полі коміту, тому історія описує, що змінилося, а не те, що агент сказав, що робить. Це розрізнення має значення о 3 ранку, через шість місяців.

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

Змусьте машину володіти рядками

Якщо ви хочете перестати читати рядки, щось інше повинно їх читати. На практиці чотири речі несуть це навантаження:

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

Рецензент з іншою моделлю. Це практична відповідь на проблему корельованих помилок. Якщо другий агент переглядає, запустіть його на іншому провайдері або сім'ї моделей, ніж автор. Ви не декорелюєте помилки повністю, але рецензент сімейства Codex на коді, написаному Claude, виявляє вимірювано інший клас проблем, ніж рецензент тієї ж моделі, саме тому, що він не ділиться пріоритетами автора.

Ворота, які не втомлюються. Типи, лінт, сканування секретів, підлоги покриття, CI, що відмовляється від міграції, включеної в функцію. Кожне правило, яке ви можете виразити як ворота, це правило, яке ви ніколи не повинні помічати знову.

Цикл, що закривається сам на собі. Агент, який будує, запускає свою власну роботу проти плану і ітерує перед тим, як щось передати, видаляє всю категорію "навіть не запустив" з вашого огляду. Це самокоригуючий цикл агента, і це різниця між агентом, що створює diff, і тим, що створює результат. Це не відповідає на питання, чи повинен підписувати людина. Це просто означає, що людина підписує щось, що вже працює.

Отже, чи все ще ви переглядаєте?

Так, і менше, ніж ви робите сьогодні.

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

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

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

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

Чи варто все ще переглядати код, згенерований AI?

Так, але не рядок за рядком на всьому. Перегляньте план перед тим, як агент почне, потім перегляньте diff пропорційно до того, що зміна може зламати. Маркетинговий текст і CSS отримують швидкий перегляд. Аутентифікація, платежі, дозволи, особисті дані та міграції читаються рядок за рядком людиною, кожного разу.

Чи може AI-агент переглянути код іншого AI-агента?

Це допомагає, але це не заміна людини на ризикованому коді. Два агенти з однієї сім'ї моделей, отримавши один і той же контекст, мають тенденцію помилятися в одному напрямку. Їхні помилки корелюють, тому другий агент виявляє помилки і відсутні тести, але ділиться сліпими зонами, які спричинили помилку. Якщо ви використовуєте рецензента-агента, запустіть його на іншій моделі, ніж автор.

Як ви знаєте, чи AI-агент зробив помилку?

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

Чи замінять AI-агенти людських рецензентів коду?

Вони вже замінили більшість читання рядків. Вони не можуть замінити підпис. Відповідальність не передається моделі, тому людина все ще несе відповідальність за рішення про злиття на всьому, що важко скасувати.

Чи потрібно переглядати AI-код рядок за рядком?

Тільки там, де радіус вибуху це виправдовує. Рядок за рядком огляд не масштабується за межі кількох агентів, що працюють паралельно, і людина, що швидко переглядає 900-рядковий diff о 18:00, створює підпис без створення знань. Витратьте цю увагу на зміни, які дорого скасувати.

Що ніколи не слід зливати без людського огляду?

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