Технології 6 хв читання Автор: Єва Семенюк
Як налаштувати ШІ-агента для перевірки коду: досвід GitLab, Kube-DC та Preply
Розробники дедалі частіше доручають перевірку коду ШІ-агентам. Експерти з GitLab, Kube-DC та Preply розповіли, як організувати цикл «агент перевіряє агента», які моделі обирати та де ШІ досі помиляється.
Перевірка коду за допомогою штучного інтелекту вже давно вийшла за межі простого запиту до чат-бота. Тепер один агент може перевіряти роботу іншого, третій — оцінювати їхні зауваження, а тести запускаються ще до відкриття pull request. Про те, як налаштувати таких асистентів і де вони досі помиляються, розповіли інженери з GitLab, Kube-DC, Superhuman та Preply.
Причина популярності ШІ-рев’ю — масштаб. Коду стає більше, і перевіряти його вручну дедалі складніше. У GitLab поставили за мету досягти 500 мердж-реквестів на інженера на місяць до кінця року. За словами Іллі Климова, Front-end Engineer у GitLab, це не метрика продуктивності, а показник низького тертя в процесі. Однак за таких обсягів людське рев’ю стає слабким місцем: один MR іноді перевіряють від двох до десяти людей.
У Kube-DC проблема інша: над проєктом на 1,2 млн рядків коду працювали троє замість запланованих 15. Засновник компанії Володимир Цап розповів, що під час розробки core-компонента цикл «модель пише код — інша модель перевіряє — перша виправляє» повторився близько 140 разів за три доби. Ярослав Єрмілов, екс-Principal Software Engineer у Superhuman, використовував ШІ як додаткову пару очей, коли працював над прототипами сам.
Водночас є дисбаланс: якщо автор генерує код з ШІ швидше, рев’юер отримує більше роботи. ШІ може перебрати на себе механічні перевірки, а людина зосередиться на тому, чи потрібна зміна взагалі і чи правильна архітектура. Ярослав наводить приклад дизайн-системи: десятки чи сотні елементів на відповідність правилам агент перевірить, не втомившись. Натомість там, де потрібен компроміс, за словами Владислава Левковського, Staff Engineer у Preply, ШІ працює гірше. «Цінність людини полягає в тому, що ми можемо знаходити такий компроміс», — пояснює він.
Підходи до створення інструментів різняться. Ілля Климов у GitLab взяв готовий вбудований AI-агент для код-рев’ю і побудував поверх нього дві власні стадії перевірки, які запускаються локально ще до стандартного серверного процесу. Володимир Цап із Shalb окремого рев’ю-інструмента не робив: його команда спершу вручну, без ШІ, написала фундамент Kube-DC — 50–60 тисяч рядків базових рішень, які мали спиратися на людський досвід. Моделі підключили вже до цього кістяка.
Ярослав Єрмілов розповідає, що «ХакерМанго» починався як дуже простий прототип. Першу версію фактично побудували навколо одного короткого промпту: «Зроби рев’ю цього pull request». За його словами, цього вистачило приблизно на 80% результату. Він радить спробувати готові рішення, якщо немає сильної внутрішньої команди для такого проєкту. Спершу його агент навчився не лише аналізувати код, а й взаємодіяти з розробником: міг опублікувати зауваження в GitHub, прочитати відповіді, оцінити аргументи й погодитися або не погодитися з ними. Наступним кроком стало розділення завдань між кількома агентами. «Ми починали з одного агента, який отримував інструкцію „зроби рев’ю“, а далі перейшли до того, що є головний агент, який запускає цілий набір інших — від трьох до п’ятнадцяти окремих агентів», — каже Ярослав Єрмілов.
У Preply рев’юер спершу був частиною бота, що автономно допомагав розробляти задачі. Готові рішення, як-от Codex чи Cursor, добре знаходили edge cases і баги, але, за словами Владислава Левковського, не враховували внутрішні правила компанії, складність рішень і головне питання: чи потрібна ця зміна взагалі. Тож команда паралельно прогнала власний рев’юер і готові інструменти на однакових тестових pull request. В одному з них навмисно заклали сім порушень внутрішніх DDD-правил. Власний рев’юер знайшов усі сім. CodeRabbit показав у звичайних коментарях лише три, а ще чотири позначив як мінорні. Після цього, а також після фідбеку розробників на реальних PR, команда вирішила розвивати власного рев’юера.
Окрема тема — скільки агентів використовувати. У GitLab Ілля Климов додав перед вбудованим AI-рев’юером ще два етапи, які запускаються локально. Перший рев’юер працює на моделі іншого сімейства, ніж та, що писала код. За словами Іллі, моделі схильні краще оцінювати код, створений ними самими або моделями того ж сімейства. Тому якщо код він пише з моделями Anthropic, рев’ю робить модель OpenAI. Її завдання не лише шукати помилки, а й перевірити, чи реалізація відповідає задачі. Наприклад, для виправлення таблиці на малих екранах модель спершу дивиться відео з результатом, а потім читає код. Так вона оцінює те, що складно перевірити звичайними інструментами: чи адекватно поводиться інтерфейс і чи це те, що просили. Механічні перевірки Ілля свідомо залишає лінтерам та іншим детермінованим інструментам.
Другий етап — рев’юер першого рев’юера. Ця модель перевіряє не код, а зауваження: чи справді вони потрібні й чи не суперечать вимогам проєкту. Перша модель, наприклад, пропонує обробити дуже довгий текст у таблиці. Друга з’ясовує, що така ситуація вже неможлива завдяки перевіркам на сервері й фронтенді, і зайві 20 рядків відпадають. В іншому випадку перша радить старий CSS-клас Bootstrap, хоча проєкт мігрує на нову систему. Друга відхиляє пораду й нагадує про нові атомарні класи. Але відхилені зауваження не завжди закривають питання: якщо моделі не погоджують...
3
