Перейти до основного вмісту

Частина 5: Рев'ю та випуск

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

Нехай агент зробить перший прохід​

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

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

Переглядайте кожен рядок, що іде в продакшн — з належним скептицизмом​

Рефлекс довіряти коду, бо він виконується, — це саме неправильний рефлекс для генерованого коду. Переглядайте кожен рядок, що іде в продакшн, і спрямовуйте скептицизм на конкретні способи збоїв AI-результату:

  • Ставтеся скептично до хитромудрого коду. Генеровані рішення іноді вдаються до витонченої абстракції там, де правильною була б нудна. Хитрість — це сигнал, а не комплімент.
  • Перевіряйте, що імпорти реальні. Моделі галюцинують правдоподібно звучащі пакети. Імпорт, який виглядає правильно, може бути пакетом, якого не існує — або, що гірше, шкідливим сквотом на ім'я, яке модель часто вигадує.
  • Перевіряйте обробку помилок для реалістичних збоїв. Генерований код добре покриває щасливий шлях і погано — шляхи збоїв. Запитайте, що трапиться, коли мережевий виклик перевищить час очікування, вхід буде порожнім, рядка не буде.

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

Хуки: нехай машина виконує правила, які вона забуває​

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

Хук pre-commit, що відмовляється комітити жорстко закодований секрет:

#!/usr/bin/env bash
# .git/hooks/pre-commit
if git diff --cached | grep -E -i '(api[_-]?key|secret|password|token)\s*=\s*["'\''"][^"'\'']+'; then
  echo "Blocked: looks like a hard-coded secret. Remove it before committing."
  exit 1
fi

Хуки — це місце для речей, які агент (або людина) «ніколи не повинен забувати, але часто забуває». На відміну від правила у файлі, хук не можна обійти словами.

Спостережуваність: бачте, що агент реально зробив​

Не можна керувати тим, чого не бачиш. Коли агенти беруть на себе більше роботи, налаштуйте спостережуваність, щоб мати змогу відповісти «що він зробив і чому?» Відстежуйте:

  • Трейси кожного запуску — повну послідовність кроків і викликів інструментів.
  • Результати евалів у часі, щоб регресії якості виявлялися рано.
  • Вартість токенів і затримки, щоб робочий процес, що тихо подорожчав, ставав помітним.
  • Дрейф — поведінку, що змінюється з часом без очевидної причини.

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

Недооцінена перемога: підтримка​

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

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

Налаштуйте власний робочий процес​

  • Додайте крок рев'ю першого проходу (агент переглядає diff) перед рев'ю людиною.
  • Напишіть контрольний список рев'ю для генерованого коду: хитрі абстракції, галюциновані імпорти, слабка обробка помилок.
  • Додайте хоча б один хук — почніть із блокувальника секретів вище.
  • Увімкніть трасування для запусків агента і стежте за вартістю токенів і результатами евалів у часі.
  • Оберіть один «надто ризикований, щоб торкатися» фрагмент легасі-коду і дайте його агенту як обмежене завдання з можливістю перегляду.