«Запам’ятай і більше так не роби». Як створити ШІ-агента для перевірки коду і не помилитися

Що буде, якщо один AI-агент напише код, а інший візьме його на рев’ю? У засновника Kube-DC Володимира Цапа під час розробки core-компонента такий цикл повторився близько 140 разів за три доби: перша модель писала й тестувала код, друга шукала проблеми, після чого перша їх виправляла, а друга знов перевіряла результат.

Перевірка коду за допомогою AI давно вийшла за межі простого «попросити Claude подивитися код». Тепер один агент може перевіряти роботу іншого, третій — оцінювати їхні зауваження, а тести можна запускати ще до відкриття pull request. Розбираємося, як налаштувати AI-асистентів для code review, що їм потрібно знати про проєкт, як зрозуміти, чи слушні їхні зауваження, і де вони досі помиляються.

DOU поговорив про це з Іллею Климовим, Front-end Engineer у GitLab, Володимиром Цапом, засновником Shalb і Kube-DC, Ярославом Єрміловим, екс-Principal Software Engineer у Superhuman та Владиславом Левковським, Staff Engineer у Preply.

Навіщо AI в ревʼю

Причина в масштабі: коду стає більше, а перевіряти його по-старому дедалі складніше. У GitLab поставили ціль дійти до 500 мердж-реквестів на інженера на місяць до кінця року. За задумом компанії, це не метрика продуктивності, а показник того, наскільки мало тертя в процесі. Але за таких обсягів людське рев’ю стає одним із слабких місць: за словами Іллі Климова, один MR іноді перевіряють від двох до десяти людей. У Kube-DC проблема інша: над проєктом на 1,2 млн рядків коду працювали троє замість запланованих 15. А Ярослав Єрмілов у Superhuman, коли працював над прототипами сам, використовував AI хоча б як додаткову пару очей.

Є й дисбаланс: якщо автор генерує код з AI швидше, то рев’юер отримує більше роботи. AI може перебрати на себе механічні перевірки, а людина зосередиться на тому, чи потрібна зміна взагалі і чи правильна архітектура. Ярослав наводить приклад дизайн-системи: десятки чи сотні елементів на відповідність правилам агент перевірить, не втомившись. Натомість там, де потрібен компроміс, за словами Владислава Левковського, Staff Engineer у Preply, АІ працює гірше.

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

Владислав Левковський

Збирати самому чи брати готове рішення

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

Ілля Климов у GitLab взяв готове і докрутив: користується вбудованим AI-агентом для код-рев’ю, а поверх нього побудував дві власні стадії перевірки. Вони запускаються локально, ще до стандартного серверного процесу.

Володимир Цап із Shalb окремого рев’ю-інструмента не робив. Його команда спершу вручну, без AI, написала фундамент Kube-DC: 50-60 тисяч рядків базових рішень, які мали спиратися на людський досвід. Моделі й інструменти підключили вже до цього кістяка.

Ярослав Єрмілов розповідає, що «ХакерМанго» починався як дуже простий прототип. Першу версію фактично побудували навколо одного короткого промпту: «Зроби рев’ю цього pull request». За його словами, цього вже вистачило приблизно на 80% результату. Він радить спробувати готові рішення, якщо ж сильної внутрішньої команди для такого проєкту немає.

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

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

Ярослав Єрмілов

У Preply рев’юер спершу був частиною бота, що автономно допомагав розробляти задачі. Готові рішення, як-от Codex чи Cursor, добре знаходили edge cases і баги, але, за словами Владислава Левковського, не враховували внутрішні правила компанії, складність рішень і головне питання: чи потрібна ця зміна взагалі. Тож команда паралельно прогнала власний рев’юер і готові інструменти на однакових тестових pull request. В одному з них навмисно заклали сім порушень внутрішніх DDD-правил. Власний рев’юер знайшов усі сім. CodeRabbit показав у звичайних коментарях лише три, а ще чотири позначив як мінорні. Після цього, а також після фідбеку розробників на реальних PR, команда вирішила розвивати власного рев’юера.

Скільки агентів використовувати

Ревʼюер для ревʼюера: два етапи в GitLab

У GitLab є власний AI-рев’юер, але Ілля Климов додав перед ним ще два етапи, які запускаються локально.

Перший рев’юер працює на моделі іншого сімейства, ніж та, що писала код. За словами Іллі, моделі схильні краще оцінювати код, створений ними самими або моделями того ж сімейства. Тому якщо код він пише з моделями Anthropic, рев’ю робить модель OpenAI. Її завдання не лише шукати помилки, а й перевірити, чи реалізація відповідає задачі. Наприклад, для виправлення таблиці на малих екранах модель спершу дивиться відео з результатом, а потім читає код. Так вона оцінює те, що складно перевірити звичайними інструментами: чи адекватно поводиться інтерфейс і чи це те, що просили. Механічні перевірки Ілля свідомо залишає лінтерам та іншим детермінованим інструментам.

Другий етап — рев’юер першого рев’юера. Ця модель перевіряє не код, а зауваження: чи справді вони потрібні й чи не суперечать вимогам проєкту. Перша модель, наприклад, пропонує обробити дуже довгий текст у таблиці. Друга з’ясовує, що така ситуація вже неможлива завдяки перевіркам на сервері й фронтенді, і зайві 20 рядків відпадають. В іншому випадку перша радить старий CSS-клас Bootstrap, хоча проєкт мігрує на нову систему. Друга відхиляє пораду й нагадує про нові атомарні класи.

Ілля Климов

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

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

140 ревʼю за три доби

Схожу схему використовує Володимир Цап: код пише Fable від Anthropic, а перевіряє Codex Astra від OpenAI. Він описує задачу на високому рівні, розбиває її на етапи, і після кожного етапу одна модель шукає проблеми, а інша їх виправляє. Далі код іде на повторне рев’ю.

«Ця комбінація пише Claude, Fable, код, а перевіряє Codex — займає приблизно три-чотири ітерації мінімум, коли Fable щось написав, а Codex знайшов критичні проблеми. Якщо робимо навпаки, результат приблизно той самий. Тобто моделі завжди знаходять якісь проблеми».

Володимир Цап

Особливо показовий випадок стався під час розробки складного core-компонента: близько 140 повторних рев’ю за три доби.

«Fable програмував, він тестував, виглядало наче непогано, він кидав Codex зробити рев’ю на те, що той щойно виправив. І він каже: „Отут проблема, треба знову фіксити, я подивився на це з іншого боку“. Він отримував цей результат і фіксив. Далі знову каже: „Тепер я пофіксив“, відсилає йому назад. Це зайняло три доби. Три доби агенти працювали нон-стоп, щоб виправити і пройти цей сценарій».

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

Агенти перевіряють не лише код. Вони запускають тести, збирають проєкт і проходять реальні сценарії. Для складних систем Володимир використовує end-to-end тести, а для інтерфейсів Playwright: агент відкриває браузер, проходить сценарій, натискає потрібні елементи й перевіряє результат.

Щоб ці перевірки однаково й швидко працювали і локально, і на CI, він користується опенсорсним інструментом Dagger. Ідея називається local parity: агент, CI і людина перевіряють код в одному ізольованому середовищі. Тому агент ще до відкриття pull request може зробити білд, прогнати перевірку локально й отримати результат за хвилини, а не чекати, поки підніметься оточення в GitHub Actions.

Коли агентів стає 10–15

«Ми починали з одного агента, який отримував інструкцію „зроби рев’ю“, а далі перейшли до того, що є головний агент, який запускає цілий набір інших: від двох-трьох до десяти-п’ятнадцяти окремих агентів», — розповідає Ярослав Єрмілов.

Кожен підагент дивиться на свій аспект змін: один оцінює обробку помилок, другий використання дизайн-системи, третій ефективність інфраструктури. «Ці агенти можуть сфокусуватися на конкретніших проблемах і глибше в них розібратися», — пояснює він.

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

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

Який контекст давати агенту

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

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

«Як показала практика, це кардинально покращує якість код-рев’ю», — розповідає він.

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

Ілля пробував давати моделі більше контексту через Graphify, Serena та MCP, зокрема зв’язки між файлами. Відмовився: у деяких випадках точність навіть падала. Тепер рев’юер сам ходить кодовою базою й читає лише те, що йому потрібно.

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

«Запам’ятай і більше так не роби», — каже Владислав Левковський.

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

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

Історія фічі поруч із кодом. Володимир Цап зберігає в репозиторії PRD, markdown-файл із описом того, як має працювати фіча, і окремий трекер із прогресом, ризиками й проблемами:

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

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

Де AI помиляється і як це перевіряти

Мати агента-рев’юера — лише половина справи. Друга — переконатися, що він знаходить реальні помилки, а не вигадує їх, і розуміти, де він може помилятись.

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

Ілля Климов побудував для цього окремий контур перевірки — набір мердж-реквестів із заздалегідь відомими проблемами, який проганяється після кожної зміни промпту:

«У мене вже накопичено 30–40 мердж-реквестів, які мають відомі мені проблеми. І кожен раз, коли я змінюю промпт, я проганяю і автоматично порівнюю результат із новим. Тому що прогнозувати, як найменша зміна в промпті вплине на якість рев’ю, абсолютно неможливо», — каже Ілля.

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

Водночас модель знаходить проблеми, які легко пропустити людині. Один із найяскравіших прикладів — система дозволів у GitLab. За словами Іллі, приблизно у 70% випадків, коли він працює з нею, рев’юер знаходить неочевидні проблеми.

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

А от де модель систематично слабша — це кібербезпека і продуктивність, каже Ілля. Наприклад, моделі можуть не подумати про те, що важкий запит без обмеження частоти можна багато разів викликати й перевантажити систему.

У Володимира перевірка якості вбудована прямо в архітектуру процесу: рев’ю не може обмежуватися одним проходом.

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

Після кожного виправлення модель перевіряє код повністю з нуля, а не лише останню зміну. Це, за словами Володимира, принципова відмінність від людини.

Людина все одно контролює результат

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

Довіра при цьому нарощується поступово.

«У Preply ми поступово розширюємо використання автоапрувів у міру того, як зростає довіра до AI-рев’юерів. Водночас зараз у більшості випадків фінальне рішення все ще потребує людського апруву», — розповідає Владислав.

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

Ілля Климов пояснює, чому перелік рішень моделі став другим входом для ревʼю:

«Оскільки ми всі рухаємося в бік Dark Software Factory, коли людина якомога менше втручається в процес виконання і тільки контролює фінальні результати, модель ухвалює доволі велику кількість рішень самостійно. І перелік тих рішень, які вона прийняла, є другим входом для ревʼю».

Змінилося й те, як він читає вердикт рев’юера. Спочатку Ілля перевіряв кожен, а потім перестав питати «чи ідеальний цей код?» і почав питати себе, як на звичайному рев’ю: «чи заблокував би я цей PR на звичайному ревʼю?».

Наступний крок, за словами Ярослава та Володимира, — не чекати на pull request. Моделі перевіряють код ще під час написання, і цикл «пише, перевіряє, виправляє» може повторюватися скільки потрібно, перш ніж зміна потрапить до команди. У Preply рухаються в тому ж напрямку: після тріалу готових інструментів команда хоче залишити один рев’юер, вбудований у процес. Код пушиться, AI залишає коментарі, а інший агент перевіряє, чи вони валідні й чи потребують дії. Людина долучається вже до відфільтрованого.