Агентам нужна не свобода. Им нужно окружение, в котором сложно ошибиться
Прочитал Harness engineering for coding agent users Мартина Фаулера.
Это не перевод статьи и не попытка пересказать её по абзацам. Скорее заметка после чтения: что я из неё забираю в работу, а где пока не готов соглашаться.
Агент в окружении правил, тестов и обратной связи
Фаулер предлагает смотреть на ИИ-агента не как на нового разработчика, которому нужно выдать задачу и ждать результат. Агент — это модель плюс всё, что вокруг неё: правила, доступ к коду, тесты, линтеры, проверки, шаблоны, инструкции.
Он называет это harness — упряжью. Мне слово не очень нравится: сразу представляется, что мы пытаемся привязать ИИ к телеге. Но мысль полезная.
Если агенту просто сказать: «сделай хорошо», он сделает что-то. Иногда даже хорошо. Но воспроизводимость такого «хорошо» — сомнительная.
Качество не появляется на ревью
Самая понятная часть статьи — про два типа контроля.
Первый — до действия: правила, примеры, архитектурные ограничения, нормальные инструкции. Они повышают шанс, что агент с первого раза пойдёт в нужную сторону.
Второй — после действия: тесты, типизация, линтеры, проверки границ модулей. Они говорят: сюда ты уже пришёл, но здесь ошибся.
По отдельности оба подхода выглядят неполными.
Если есть только проверки, агент будет быстро делать ошибки и так же быстро получать красные сообщения. Это лучше, чем ничего. Но похоже на работу с человеком, которому ничего не объяснили, зато поставили много контролёров.
Если есть только правила — получаем красивый набор документов, который никто не проверяет на реальной работе. Агент может прочитать AGENTS.md, кивнуть и всё равно положить бизнес-логику в контроллер. Не из вредности. Просто так вышло по вероятности следующего токена.
У нас и без ИИ это знакомая история. Архитектурные договорённости, которые живут только в головах у сильных разработчиков, не являются договорённостями. Это устная традиция. Она работает, пока эти люди рядом и у них есть время на ревью.
Здесь хочется немного притормозить
Легко прочитать статью и сделать вывод: «Надо срочно обложить агентов правилами, тестами и ещё одним агентом, который проверит первого».
Я бы не спешил.
Во-первых, хороший harness — это не папка из двадцати файлов с инструкциями. Если правила противоречат друг другу или не соответствуют коду, агенту от этого не становится понятнее. Человеку, кстати, тоже.
Во-вторых, мы можем начать измерять не то. Например, агент проходит все тесты, линтер доволен, coverage вырос. А пользовательский сценарий так и не работает — потому что задача была понята неверно. Или потому что тесты агент написал под собственную реализацию.
Зелёный пайплайн в этом месте не является доказательством качества. Это только сигнал, что система проверок не нашла проблему.
И ещё один неприятный вопрос: а готовы ли мы сами сформулировать, что считаем хорошим результатом?
Когда разработчик задаёт уточняющий вопрос, мы обычно воспринимаем это нормально. Когда агент задаёт вопрос или выбирает один из двух разумных вариантов, хочется получить готовый ответ без лишнего разговора. Но вторая ситуация не делает постановку задачи точнее.
Не уверен, что проблема автономности агентов сегодня главным образом в агентах. Возможно, часть проблемы — в нашем желании отдать им не просто кодирование, а необходимость думать о продукте, контексте и компромиссах.
Где у этого есть практическая цена
Фаулер отдельно пишет о том, что не все системы одинаково удобно «обуздывать».
Проект со строгой типизацией, понятными границами модулей и быстрыми тестами даёт агенту много опор. В нём проще проверить изменение, проще не выпустить случайную зависимость, проще заметить, что решение стало сложнее.
Старый монолит с неявными правилами — ровно обратная ситуация. Ирония в том, что именно там нам сильнее всего хочется отправить агента разбираться с накопившимся долгом.
Не думаю, что из этого следует «не использовать ИИ в legacy». Но, возможно, там нужно начинать не с больших задач.
Например:
- попросить агента собрать карту зависимостей и проверить её человеком;
- вынести повторяющуюся проверку в тест или линтер;
- дать ему маленькую понятную зону и посмотреть, где он ошибается регулярно;
- по этим ошибкам улучшать не промпт, а окружение.
Последний пункт для меня самый важный. Если одна и та же ошибка повторилась три раза, не хочется в четвёртый раз писать в задаче капслоком: «НЕ ТРОГАЙ ЭТОТ МОДУЛЬ».
Наверное, стоит спросить: почему в системе вообще возможно так легко его тронуть? Можно ли обозначить границу в коде, тесте, шаблоне сервиса или хотя бы в проверяемом правиле?
Повторяющаяся ошибка должна улучшать правило и окружение
Что бы я попробовал
Не строить «фабрику автономных агентов» с порога.
Я бы выбрал один тип повторяющихся изменений: например, новый API-метод, обработчик события или миграцию данных. И посмотрел бы на него как на процесс:
- Что агент должен знать до начала работы?
- Что можно проверить за секунды до коммита?
- Какие более дорогие проверки нужны уже в CI?
- Какие ошибки всё равно должен ловить человек — потому что это вопрос смысла, а не синтаксиса?
После нескольких итераций станет видно, где действительно появляется свобода. Не свобода агента делать что угодно, а свобода команды не тратить внимание на очевидное.
Это разница, которая для меня важна.
Человек в этой схеме не исчезает. Он перестаёт быть последней линией обороны для каждой пропущенной запятой и может остаться там, где нужны приоритет, продуктовый контекст и право сказать: «Технически верно, но нам сейчас не туда».
Пока это похоже не на замену разработки, а на взросление инженерной среды. Мы много лет строили CI, тесты и архитектурные ограничения для себя. Теперь выясняется, что они ещё и определяют, насколько безопасно можно работать с агентами.
Хорошая новость: начинать можно не с революции. Достаточно заметить повторяющуюся ошибку и один раз сделать так, чтобы её стало сложнее повторить.
Плохая: это всё равно работа. Волшебного промпта, который заменит ясные границы, пока не завезли.
Источник: Martin Fowler, Harness engineering for coding agent users, апрель 2026.