Як робити рев'ю коду через агента

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

1. Як код перевіряють у команді

У невеликій команді розробник отримав завдання: зробити список покупок, куди можна додавати записи і видаляти їх по одному. Він написав код, спробував додати хліб і молоко, видалив хліб. Усе вийшло. Перш ніж передати роботу далі, розробник ще раз перечитав свої зміни: прибрав забутий шматок, виправив незрозумілу назву. Це самоперевірка.

Потім він попросив колегу подивитися код. Колега знає мову програмування і читає, як влаштоване додавання, як програма обирає запис для видалення, що відбувається з рештою списку. Такий перегляд називають рев'ю коду, або code review, а того, хто перевіряє, називають рев'юером.

Колега помічає: програма обирає покупку для видалення за назвою. Якщо у списку опиняться два записи "Молоко", натискання на один може видалити обидва. Автор перевіряв хліб і молоко, тому на такий випадок просто не натрапив.

Рев'юер лишає коментар поряд з відповідною ділянкою коду: "Зараз видаляються всі покупки з цією назвою. Ми дозволяємо однакові записи? Якщо так, видаляти треба лише обраний". Автор уточнює вимогу: однакові записи дозволені, адже їх могли додати для різних людей. Після обговорення він змінює спосіб вибору запису. Колега дивиться виправлення ще раз і переконується, що зауваження враховано.

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

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

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

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

2. Як доручити рев'ю агенту

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

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

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

У рекомендаціях Claude Code щодо рев'ю пропонують окремого рев'юера і явні критерії. Там само радять зосередитися на зауваженнях, які впливають на правильність роботи і на вимоги. Застосуємо це до невеликої ділянки проєкту.

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

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

У результаті у вас буде зрозуміле пояснення проблеми, результат її повторної перевірки і звіт про виправлення. А якщо зауваження виявилося помилковим, корисний результат теж є: ви уникли зайвої правки.

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

Запит 1. Перевірити написаний код

Запустіть Claude Code у теці проєкту. Наступні три запити надсилайте в основну сесію: головний агент сам передає роботу помічникам. Тут і далі використовуємо навчальний список покупок; для свого проєкту замініть опис поведінки.

Доручи окремому субагенту рев'ю коду списку покупок
у поточному проєкті. Перевір додавання і видалення записів.
Вимоги: однакові назви дозволені; видаляється лише
обраний запис; порожню покупку додати не можна.

Прочитай поточний код і пов'язані з ним частини проєкту.
Шукай помилки, які порушують ці вимоги.
Код не змінюй. Не додавай нові можливості.
Для кожного зауваження поясни простими словами:
що може піти не так, за якої дії і чому ти так вирішив.
Вкажи місце в коді для подальшої перевірки іншим агентом.
Якщо проблем не знайдено, так і напиши. Перелічи, що перевірено
і що лишилося невідомим. Збережи звіт у REVIEW_REPORT.md.
Я не знаю мови програмування: поясни підсумок без вимоги читати код.

Файл REVIEW_REPORT.md буде звичайним текстовим звітом. Його назву ми вибрали самі: вона потрібна, щоб у наступному запиті було зрозуміло, які зауваження перевіряти повторно. Вимога "код не змінюй" відділяє перегляд від виправлення; а запис звіту дозволено.

Корисна відповідь у нашому прикладі могла б звучати так: "Якщо додати дві покупки з однаковою назвою, видалення однієї прибере обидві. Код обирає записи за назвою, тому зачіпає обидва збіги". Це навчальний приклад відповіді, а не результат перевірки вашого проєкту.

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

3. Як перевірити зауваження повторно

В агента-рев'юера теж бувають помилки. Наприклад, він пише: "У список можна додати порожню покупку". Звучить переконливо. Але перевірка порожнього вводу вже є в іншій частині програми, яку він не прочитав. Зауваження описує проблему, якої не існує.

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

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

Запит 2. Перевірити звіт рев'юера

Доручи іншому субагенту перевірити REVIEW_REPORT.md
за поточним кодом проєкту і вимогами з попереднього запиту.
Передай йому ці вимоги явно.

Щодо кожного зауваження з'ясуй, чи існує описана проблема.
Перевір пов'язані частини коду: можливо, потрібна обробка вже є.
Не вважай перший звіт доказом. Якщо для висновку потрібна
перевірка запуском, виконай її доступними засобами.
Код проєкту не змінюй.

Для кожного пункту вкажи: підтверджено, спростовано
чи поки не вдалося встановити. Поясни підставу зрозумілою мовою.
Розділи висновки з читання коду і результати виконаних перевірок.
Не видавай невиконану перевірку за виконану.
Збережи результат у REVIEW_CHECK.md і коротко поясни його мені.

Після цього у вас буде REVIEW_CHECK.md з результатом повторної перевірки. У нашому навчальному випадку другий агент може підтвердити проблему однакових назв, а зауваження про порожній ввід спростувати: "Порожній рядок відхиляється до додавання запису. Перший рев'юер пропустив цю перевірку".

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

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

4. Виправлення і повторне рев'ю

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

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

Запит 3. Виправити і перевірити результат

Виправ підтверджену проблему з REVIEW_CHECK.md:
під час видалення однієї покупки зникають усі записи з такою самою назвою.
Треба видаляти лише обраний запис. Однакові назви дозволені.
Решту пропозицій з рев'ю зараз не впроваджуй.

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

Поясни мені простими словами, що змінилося, які перевірки
виконано і що показало повторне рев'ю.
Якщо щось перевірити не вдалося, назви це окремо.
Не розширюй завдання новими поліпшеннями.

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

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

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

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