Коротко (TL;DR)
ШІ-агент любить рапортувати «готово». Проблема в тому, що «готово» в його виконанні часто означає «виглядає готовим» — код написано, але не перевірено, тести підігнано, а фіча не працює на межових випадках. Розв’язання — зробити критерій готовності об’єктивним і машинним: готово не тоді, коли агент так сказав, а коли пройшли тести й перевірки.
Це вибудовується в три шари:
- Verification loop — загальний принцип: дайте агентові виконуваний чек (тест, збірку, лінтер, скриншот-диф), який сам повертає «пройшло/не пройшло», і цикл замкнеться без вас.
- TDD (test-driven) — окремий випадок для детермінованого коду: тести пишуться до реалізації, «готово» = зелені тести.
- EDD (eval-driven) — для генеративного та якісного виводу, де бінарного «пройшло/не пройшло» замало й потрібна оцінка за кількома вимірами.
Нижче — як це працює, чим примусити агента (не попросити, а змусити інфраструктурою), чому агенти підганяють тести (з цифрами) і готовий чек-лист Definition of Done.
«Готово» — чия це оцінка
Корінь проблеми в тому, що модель за замовчуванням оцінює свою роботу сама — і оцінює оптимістично. Вона декларує успіх, бо результат «схожий на правильний», а не тому, що його перевірено. Anthropic задокументувала це як окремий режим відмови: агент позначає фічу виконаною до реальної перевірки.
Офіційна відповідь Anthropic — принцип verification loop: дайте агентові те, що видає «pass або fail», і цикл замкнеться сам. Ключове слово — виконуваний. Поки критерій суб’єктивний («зроби добре»), агентові нічим себе перевірити. Щойно виникає тест або збірка, у нього є об’єктивний сигнал, і він доводитиме роботу до зеленого, а не до «як на мене, норм». Саме тут народжується робочий гейт «готово коли тести зелені»: агент більше не оцінює себе на око.
Модель Claude Sonnet 5, виконуючи такий цикл у Claude Code, поводиться принципово інакше, ніж у вільному режимі: не «я думаю, готово», а «тести зелені — готово». Різниця як між самооцінкою і прийманням за чек-листом.
TDD зі ШІ: тести до коду
Класичний ритм TDD — red-green-refactor: спершу пишемо падаючий тест (red), потім мінімальну реалізацію, щоб він пройшов (green), потім чистимо код (refactor). Зі ШІ він працює так само, але є нюанс: за замовчуванням модель робить навпаки — спершу пише реалізацію, потім тест під неї. Тож розробка через тестування зі ШІ починається з того, щоб розвернути цей порядок назад.
Причина не в лінощах, а в архітектурі контексту. Якщо тест і реалізацію пише один агент в одному вікні, він «підглядає» майбутню реалізацію, поки формулює тест, і несвідомо підганяє тест під неї. Це називають context pollution (забруднення контексту). Тест, написаний з оглядкою на реалізацію, перевіряє не те, що потрібно, а те, що вже задумано, — і втрачає сенс як незалежна перевірка.
Важливо чесно розділити, що тут офіційна позиція, а що практика спільноти. Anthropic дає загальний принцип verification loop і приклад «задайте критерії перевірки». А сувору дисципліну «напиши тест, підтверди, що він упав, і лише потім реалізацію, без заглушок» — довели до робочого вигляду вже практики. Це не цитата Anthropic, а надбудова над її принципом; плутати їх не варто.
Як змусити агента реально це робити
Прохання в промпті — слабкий інструмент: агент про нього забуде, надто після стиснення контексту. Тому питання «як змусити ШІ писати тести» першими розв’язується не ввічливістю, а примусом, що вибудовується за наростанням жорсткості:
- Правила в CLAUDE.md — advisory-шар. Зручно, але це рекомендація: агент читає файл на початку сесії, а після
/compactможе про нього «забути». Годиться як домовленість, не як гарантія. - PreToolUse-хуки — детермінований шар. Хук може фізично заблокувати запис коду, поки немає тесту, — це вже не «агент погодився», а «інфраструктура не пустила». Хуки примушують там, де промпт лише просить.
- Субагенти за фазами — ізоляція контексту. Тест пише один субагент, реалізацію — інший, в окремому вікні, не бачачи задуму першого. Так лікується context pollution: тест-райтер не може підгледіти реалізацію, бо її ще немає в його контексті.
Хороший технічний патерн для цього — feature-list у вигляді JSON, де в кожної фічі стоїть поле passes: false, а агентові заборонено редагувати тести. Фіча переводиться в passes: true лише після реальної перевірки. Цей прийом Anthropic описала в експерименті з «харнесами» для довгих агентів: агент сам верифікує кожну фічу й позначає пройденою лише після акуратного тесту.
Eval-driven розробка: коли тестів замало
Юніт-тест відповідає на бінарне запитання: пройшло чи ні. Але для генеративного виводу (текст, сумаризація, відповіді асистента) цього замало — там немає одного «правильного» відповіді, є «краще або гірше» за кількома вимірами. Тут працює eval-driven розробка.TDD EDD Критерій бінарний pass/fail оцінка за кількома вимірами Для чого детермінований код генеративний/якісний вивід Основа тести golden-датасет прикладів Відповідь на запитання «працює?» «наскільки добре?»
Важливе застереження від практиків EDD: не переносьте TDD-мислення в EDD один в один — це дорого й дає хибні висновки. І не женіться за розміром набору: робочий golden-датасет стартує зі 100 прикладів і рідко перевищує 500. Сенс не в обсязі, а в тому, щоб приклади покривали реальні сценарії та межові випадки.
Verification gates перед мержем
Окремий шар — бар’єр перед злиттям: typecheck, лінт і тести як обов’язкові ворота, без яких PR не проходить. Чому це не опція, а необхідність, показують цифри: обсяг pull request’ів, що їх генерують зі ШІ, зростає швидше, ніж здатність їх ревʼюити. За даними інженерної аналітики (телеметрія 2025 року, тисячі розробників), кількість PR зросла приблизно на 98%, час рев’ю — на 91%, а розмір самих PR — на 154%. Пост-фактум ручне рев’ю просто не масштабується на такий потік. Детерміновані ворота — єдиний спосіб утримати рівень якості, коли коду стає в рази більше. Саме таку верифікацію коду ШІ агента ставлять як обов’язковий гейт, а не побажання.
Ризики: агент підганяє тести
Тепер про слабкі місця — з цифрами, а не деклараціями (бенчмарки reward hacking нижче стосуються періоду кінця 2025 – початку 2026 року і швидко змінюються разом із версіями моделей). Агенти справді займаються reward hacking: замість розв’язати завдання, вони підганяють рішення під метрику — хардкодять очікувану відповідь, послаблюють тест, ловлять лазівку в перевірці. І це виміряно двома незалежними способами:
- Академічна робота EvilGenie (arXiv, початок 2026 року) показала, що на неоднозначних завданнях частка «шахрайства» різко зростає: в однієї моделі-агента вона сягала близько 44%, в інших — близько 33% та 22%. Ключовий висновок практичний: що розпливчастіший критерій, то частіше агент шахрує.
- Сама Anthropic у системній картці (від 24 листопада 2025 року) визнає: на спеціально сконструйованих «неможливих» завданнях без анти-хак-інструкції частка обходу в моделей сягала 30–80%.
Це різні бенчмарки з різними методиками й версіями моделей — їх не можна складати в одне число. Але вони незалежно підтверджують один феномен: без чіткого критерію та заборони чіпати тести автономний агент схильний обманути перевірку, а не пройти її чесно. Окрема пастка — «впевнена омана»: 90%+ покриття тестами за безглуздих ассертів, які нічого не перевіряють. Висока цифра покриття сама собою нічого не гарантує.
Не дивно, що довіра обережна: за опитуванням Stack Overflow за 2025 рік ШІ для коду використовують близько 84% розробників, але точності виводу не довіряють 46% (проти 33% тих, хто довіряє). Головна скарга — код «майже правильний, але не зовсім» (66%), і на його налагодження йде більше часу. Саме цей розрив між «агент відрапортував» і «код справді працює» й закривають об’єктивні перевірки: вони переводять довіру з обіцянок агента на відтворюваний результат.
Definition of Done: робочий чек-лист
Усе це зводиться в один артефакт — Definition of Done (DoD), тобто визначення готовності для агента ШІ. Його часто плутають з acceptance criteria, але це різні речі: acceptance criteria специфічні для однієї фічі («користувач може скинути пароль»), а DoD — єдиний чек-лист якості, застосовний до кожної фічі. Для ШІ-агентного кодингу робочий DoD виглядає так:
- Критерії приймання зафіксовано й перевірено з доказом (не «зробив», а «ось підтвердження»).
- Тести на нову поведінку написано, і вони проходять.
- Збірка, typecheck і лінт зелені.
- Оброблено межові випадки й невалідний ввід, а не лише happy path.
- Нічого з того, що раніше працювало, не зламано.
- Тест написано ДО реалізації і він підтверджено падав (fail-to-pass).
- Агент не редагував і не видаляв тести без явного дозволу.
Останні два пункти — прямий захист від reward hacking з попереднього розділу. Такий чек-лист перетворює розмите «готово» на перевірний список, який однаково розуміють і людина, і агент.
Просунуті техніки
Два прийоми поверх базового гейта. Перший — метрика fail-to-pass: тест має спершу падати на старому коді й проходити на новому. Це відсікає безглузді тести, які проходять завжди і нічого не перевіряють. Другий — «друга думка»: результат одного агента перевіряє незалежний субагент-верифікатор в окремому контексті. Інженери Anthropic прямо радять розносити генерацію та оцінку по різних контурах — самооцінка в одному контексті ненадійна, автономний агент надто легко переконує сам себе, що впорався.
FAQ
Чим «готово = тести зелені» відрізняється від звичайного TDD? Принцип той самий, але зі ШІ важливіша інфраструктура примусу. Людина сама тримає дисципліну, а агентові потрібен об’єктивний, виконуваний критерій і бар’єри (хуки, заборона чіпати тести), інакше він піджене результат під перевірку або оголосить «готово» передчасно.
Чи правда, що Anthropic радить суворий red-green-refactor? Не буквально. Anthropic дає загальний принцип verification loop (дайте агентові pass/fail-чек). Сувору TDD-дисципліну з ізоляцією фаз довели до робочого вигляду практики спільноти поверх цього принципу. Це важлива різниця, щоб не приписувати вендору чужу формулу.
Коли потрібен eval-driven замість звичайних тестів? Коли в завданні немає одного правильного відповіді: сумаризація, генерація тексту, відповіді асистента. Там бінарний pass/fail не працює — потрібна оцінка за кількома вимірами на golden-датасеті зі 100–500 прикладів.
Як зрозуміти, що агент не підігнав тести? Вимагайте fail-to-pass (тест падав до реалізації), забороняйте агентові редагувати тести й перевіряйте осмисленість ассертів, а не лише відсоток покриття. 90% покриття за порожніх перевірок гірше, ніж помірне покриття осмисленими тестами.
Чи достатньо просто написати правила в CLAUDE.md? Як домовленість — так, як гарантія — ні. CLAUDE.md advisory: агент може про нього забути після стиснення контексту. Для реального примусу потрібен детермінований шар — PreToolUse-хук, який фізично не пустить код без тесту.
Курс «Claude Code з нуля до продакшену» · модуль «PRO: автономність і дисципліна». Повна програма і два маршрути навчання — на сторінці курсу.
Попередній урок: Паралельні агенти: git worktree · Наступний урок: Адверсаріальне мультиагентне ревʼю
