Привет, читатели! Я давно наблюдаю за тем, как coding-агенты меняют разработку, и решил собрать свои наблюдения в серию постов. Тема горячая, спорная и очень практичная — harness engineering, то есть проектирование среды, в которой работает агент. Не промпты, не выбор модели, а именно инженерная обвязка: права, тесты, логи, точки остановки.

Начнём с боли, которая проявляется раньше всего. Ещё недавно спор про coding-агентов сводился к тому, какая модель лучше пишет код. Сейчас интереснее другой вопрос: почему команда, у которой агент генерирует в разы больше diff'ов, не получает пропорционального роста поставленной ценности?

Ответ всё чаще звучит не про модель, а про среду вокруг неё. Агент создаёт изменения быстрее, чем команда успевает их понять, проверить и принять ответственность за merge. Это не «медленное ревью» в старом смысле. Это долг: изменения приняты, но не поняты; тесты зелёные, но не доказывают поведение; ответственность формально есть, а фактического понимания нет. Назовём это verification debt.

Цифры из разных срезов 2026 года показывают одну и ту же картину. В опросе Qodo (500 разработчиков и 300 engineering-лидеров) и разработчики, и руководители назвали review/validation AI-кода главной проблемой delivery pipeline — по 26% в обеих группах. Sonar фиксирует, что 96% разработчиков не полностью доверяют функциональной корректности AI-кода, при этом 58% используют AI для business-critical сервисов. Temporal: 85,5% хотя бы частично доверяют выводам агентов, но лишь 24,7% доверяют полностью; безопасность — главный барьер полной автономии для 39,5%.

Дальше — телеметрия, которая объясняет цену. Faros AI при высокой AI-адопции наблюдал churn +861%, incidents-to-PR +242,7%, рост дефектов на разработчика с 9% до 54%, median review time +441,5%, PR без ревью +31,3%. Harvard working paper на данных 718 компаний: LOC на работника +30%, но разрешение issues/epics статистически не выросло; время PR→merge +49%, доля PR на доработку почти удвоилась. Bain: разработчики выполняют на 21% больше задач, но время на ревью AI-вывода выросло примерно на 91%.

Это опросы и телеметрия, а не лабораторный эксперимент. Но причинно-следственная связь читается: генерация масштабируется вычислениями, а ревью — людьми, контекстом и вниманием. Если насос стал мощнее, а труба та же, давление растёт не там, где ждали. Verification debt накапливается не в момент генерации, а в момент merge: команда принимает изменение, которое не может уверенно проверить.

Граница применимости: в маленьких командах с коротким циклом обратной связи и сильными тестами эффект может быть мягче. В legacy-системах с неявными инвариантами — жёстче. Проверять стоит не по одному числу, а по набору: review time, revert rate, incident rate, доля PR на доработку, churn. Если генерация растёт, а merge latency и incidents растут быстрее — вы уже платите verification debt.

Главный тезис серии: узкое место сместилось с генерации на доверие, проверку и сопровождение агентных изменений. В следующих постах разберём, из чего состоит harness, где он ломается и что проверять в первую очередь.

А вам знакомо это чувство, когда PR зелёный, но вы не уверены, что понимаете, что именно смержили? Напишите в комментариях — обсудим.