Харнес рятує лише дешеві моделі агентів
Martin Fowler порівняв кодових агентів, які будували однаковий backend-сервіс (178 автотестів) з «поведінковим харнесом» (специфікації OpenAPI/AsyncAPI, приклади, тестові сенсори) і без нього. Фронтир-модель GPT-6 Sol проходила всі тести у 10 з 10 запусків і з харнесом, і без — харнес лише підняв токени у ~10.5 раза, час у ~3 рази, вартість у ~7 разів без приросту якості. Дешевша GPT-6 Luna без харнесу впоралась лише у 3 з 10 запусків, з харнесом — у всіх 10, дешевше за Sol на 33% ($0,273 проти $0,406 за запуск).
Де саме ламаються моделі без харнеса
Бріф на сервіс був не абстрактним CRUD: BFF мав обробляти пошук товарів, викликати downstream Order API, публікувати в Kafka лише перший знайдений товар (а не всі) і коректно мапити помилки — `429` для тимчасового збою пошуку, `503` для недоступних залежностей чи провалу публікації, `502` якщо відповідь не відповідала фільтрам запиту. Окремо — асинхронний flow: таймаут створення товару мав повертати `202` з лінком на моніторинг, а не одну з готових помилок.
Саме тут і сипались неузгоджені запуски без харнеса. З тих, що впали, 4 застосунки на таймауті повертали `503`, 2 — `400`, 1 — `429` замість `202`; ще один створював моніторинг, але retry ніколи не доходив до фінального `201`. У 7 запусках це тягнуло другу поламку: відсутній лінк на моніторинг — відсутня можливість його опитати. Окремо 3 запуски доставляли повідомлення в Kafka технічно справно, але контракт не проходив: два застосунки через серіалізатор Spring додавали зайвий заголовок `__TypeId__`, ще один писав `"categories": null` замість масиву чи пропуску поля. В одному випадку звичайне створення товару падало в `503` через банальну розбіжність імені змінної — клієнт читав `ORDER_API_API_KEY`, а в конфігурації запуску був `ORDER_API_KEY`. Важливо: навіть ці невдалі запуски проходили щонайменше 144 з 178 перевірок — це не провал розуміння задачі, а випадання окремих деталей під час реалізації.
З чого складається харнес покроково
Guides (специфікації OpenAPI/AsyncAPI, приклади запитів-відповідей на таймаути, некоректні payload'и, порушення фільтрів, retry-послідовності та підтвердження Kafka, плюс skill із практиками реалізації API) агент читає ще до написання коду і зіставляє кожну поведінку з перевіркою. Sensors — тести контрактів, перевірки значень HTTP-відповідей і сайд-ефектів (виклики до mock-залежностей, публікація в Kafka) — повертають фідбек через тестові звіти, CTRF-звіти та звіти покриття API.
Послідовність фіксована: `examples validate` звіряє приклади зі специфікаціями, тестова команда проєкту піднімає downstream mock'и, запускає застосунок проти них і прогонятиме перевірки; звіт вказує конкретні розбіжності контракту чи значень, агент виправляє реалізацію (не тест!) і перезапускає саме цей сценарій, а повний набір — як фінальний гейт перед завершенням. Цикл не автоматичний: він працює лише тоді, коли агент сам викликає тестову команду під час роботи, а не після кожного edit. У експерименті інструментом для цього був Specmatic — автор зазначає, що подібні можливості дають й інші інструменти контрактного тестування та service virtualization.
Де харнес не вартий своїх токенів
Для флагманської GPT-6 Sol харнес не підняв жоден результат — лише додав витрати (токени, час, вартість зросли, якість залишилась 10 з 10 в обох умовах). У побічних запусках Claude Sonnet 4.6, Claude Opus 4.6 і Gemini 3.8 Flash (теж із низьким reasoning effort) також впорались без харнеса з першої спроби — тобто для моделей такого рівня додаткова інфраструктура виглядає зайвою.
Автор окремо застерігає: бріф був незвично повним — функціональні вимоги, архітектурні обмеження, точні формати зовнішніх інтерфейсів і поведінка при збоях описані в деталях. Як зміняться результати з менш повним брифом — невідомо, це прямо не перевірялось.
Що перевірити, перш ніж довіряти результату
Контракти й приклади мають походити не від агента, який пише і реалізацію, і тести до неї — інакше одна й та сама помилка прочитання вимог потрапить в обидва місця. Агенту варто явно заборонити послаблювати очікувані результати тестів при падінні: виправляти має реалізацію чи налаштування запуску, а не контракт.
Той самий сенсор відіграє дві різні ролі залежно від моменту: під час розробки — це фідбек для самокорекції, а по завершенні — незалежна перевірка того, що зробив агент, проти людських очікувань, і це, за словами автора, важливо для будь-якої моделі, включно з флагманською. Варто також вимагати від агента перевірні артефакти взаємодій з downstream-залежностями та фінального результату верифікації, а не покладатись на його власне твердження про успіх. Наведені оцінки вартості — це API-еквівалентні розрахунки на основі використаних токенів і цін моделей, а не реальні виставлені рахунки.