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

Це не технічне обмеження. Це проблема видимості.

Коли агент пише три рядки робочого коду, він міг прочитати три файли та запустити тести. Або ж він міг зачепити сорок непов'язаних файлів, виконати десяток невдалих команд, пропустити ваш набір тестів через помилку при встановленні залежностей і виставити вам рахунок за цю «привілейовану» послугу. У будь-якому разі diff виглядатиме однаково. Без запису шляху ви залишаєтеся лише здогадуватися про якість результату.

Чому логи чату — це не чеки

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

Людська увага обмежена. Суть агента полягає в економії когнітивних зусиль, а не в створенні додаткового домашнього завдання. Транскрипт змушує рев'юера ставати детективом. Чек дає відповідь з першого погляду.

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

Як виглядає хороший чек

Чек, придатний для рев'ю, має відповідати на конкретні запитання без зайвого занурення:

  • Яким було завдання? Чіткий опис запланованої зміни, а не розмите відлуння промпту.
  • Які файли були прочитані? Щоб ви могли оцінити, чи побудував агент контекст на основі правильних джерел.
  • Які файли були змінені? Кінцевий «слід» зміни.
  • Які команди були запущені? Кроки збірки, лінтери, форматировники або кастомні скрипти, які викликав агент.
  • Які команди завершилися невдачею? Не лише успішні. Помилки показують, де агенту довелося імпровізувати або де він здався.
  • Які тести пройшли або були пропущені? Пропущені тести — це тривожний сигнал. Чек має пояснювати, чому вони були пропущені.
  • Якою була загальна вартість? Токени, виклики API та час обчислень. Це включає вартість вашої архітектури, а не лише моделі.

Такий формат перетворює рев'ю з археологічних розкопок на швидку перевірку на адекватність. Senior-інженер має мати змогу проглянути чек і сказати «це має сенс» або «це виглядає підозріло» менш ніж за хвилину.

Читайте «слід», а не лише історію

«Слід» виконання агента показує форму виконаної роботи. Чи залишився агент у межах тікета? Чи він забрела у непов'язані модулі та змінив те, про що ніхто не просив? Чек, у якому «Змінені файли» наведені поруч із «Прочитані файли», робить це очевидним.

«Слід» також виявляє повторення. Агент, який постійно заходить у глухий кут — тричі читає один і той самий конфігураційний файл або знову і знову запускає невдалий тест — марнує обчислювальні ресурси та контекстне вікно. Ця закономірність має бути помітною. Якщо агенту знадобилося дев'ять спроб, щоб запустити скрипт міграції, чек має про це повідомити. Ця інформація змінює те, як ви оцінюєте результат. «Правильний» diff, отриманий шляхом хаосу методом грубої сили, — це не те саме, що правильний diff, отриманий чисто.

Прихована вартість поганого дизайну

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

Якщо генерація стає дешевшою, а рев'ю — складнішим, ви нічого не виграли. Ви просто перенесли вузьке місце. Час інженерів зазвичай є найдефіцитнішим ресурсом у команді. Заощадження п'яти доларів на витратах API ціною додавання тридцяти хвилин на рев'ю кожного pull request — це жахлива угода. Чек допомагає вам безпосередньо аудитувати цю угоду.

Чесність — це функція

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

Приклади мають значення:

  • "Прочитано 37 файлів заради зміни в один рядок."
  • "Тести пропущено, оскільки npm install завершився помилкою через конфлікт peer-залежностей."
  • "Відредаговано utils.py поза межами запиту, щоб виправити імпорт, доданий агентом."
  • "Запущено лінтер 4 рази; перші три завершилися невдало через неправильну конфігурацію шляхів."

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

Менші цикли виконання, чітший контроль

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

Краще робити невеликі цикли, які можна перевірити. Визначайте чіткі межі завдання. Відокремлюйте список файлів, які агент може читати, від списку тих, у які він може записувати. Зберігайте історію невдалих команд, щоб заходи в глухий кут були помітними. Явно позначайте пропущені перевірки. Фіксуйте використання кожного зовнішнього інструменту — від пошукових API до тест-раннерів.

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

Тест для будь-якого кодинг-агента

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

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

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

Вимагайте звітів. Проєктуйте з урахуванням можливості перевірки. Довіра — це не стратегія. Докази — це стратегія.

Для більш практичного обговорення інструментів ШІ та робочих процесів розробників ви можете приєднатися до спільноти GyaanSetu в Telegram.