Ваш агент не тупой — ему просто неудобно

Agent Comfort: измеримое свойство среды, от которого зависит, справится кодинг агент сам или нет

В обсуждениях агентской разработки сейчас две повторяющиеся истории. Инженеры тонут в ревью сгенерированного кода: с ИИ мержится почти вдвое больше PR, а время ревью выросло на 91% ^[1]. Продакты и эффективные менеджеры тем временем хвастаются, что выкатывают фичи без программистов. Продакт из Meta ^[2], чья “суперспособность” от vibe coding разошлась по лентам, передает свой код разработчику на финальное ревью. Суперсила Формулы-1, где под капотом живые кочегары.

В этой статье я предлагаю подход – Agent Comfort: свойство среды разработки, которое можно измерить и целенаправленно поднимать, чтобы кочегаров под капотом заменила среда.

Сколько на самом деле стоит “автоматизация”

Типичная картина: агенту ставят задачу, он что-то пишет, тесты падают, он читает логи, интерпретирует их по-своему, пробует еще раз, снова мимо. Инженер в это время либо ждет, либо вмешивается и начинает разбираться, что происходит. Если ему хватает терпения докопаться, к третьей итерации выясняется, что агент неправильно понял структуру проекта: в контексте было три версии одного и того же модуля и закомментированный легаси-код пятилетней давности. У некоторых терпение кончается – тогда человек исправляет код сам. Токены сгорели, полдня инженера сгорело. На следующей задаче агент опять ошибается, доверие к нему падает, выгорание инженера растет. При этом формально “мы используем ИИ в разработке”.

Что такое Agent Comfort

Agent Comfort – свойство среды: насколько агенту удобно ориентироваться в контексте, применять доступные инструменты и проверять свою работу. Измеряется оно метрикой First-Prompt Success Rate:

FPSR = задачи, закрытые с первого промпта / всего задач

Если из 10 задач агент закрыл 8 с первого промпта – FPSR = 0.8, комфорт высокий. “Первый промпт” здесь – стартовый промпт сессии. Сколько итераций агент крутил внутри – значения не имеет. Важно, что человек в чате больше не участвовал в уточнении задачи и не отвечал на вопросы агента.

Комфорт держится на трех элементах среды.

Чистый контекст. Минимум шума: понятная структура, история изменений под рукой, отсутствие мешающего легаси. Агент не тратит токены на разбор хаоса и не строит ложных гипотез о том, как устроена система. Каждый лишний файл в контексте – это и расход токенов, и дополнительная возможность ошибиться в интерпретации.

Удобные инструменты. Агент не должен бороться с окружением: угадывать, как собрать проект, как запустить тесты, где лежат логи. Каждая такая борьба – это ложные ветки исследований и дополнительные вопросы. Все запускается одной командой, вывод читается без археологии, результат воспроизводим.

Датчики контура верификации. Способы посмотреть на промежуточное состояние работы, пока она еще идет. Написать сценарный тест и вывести промежуточные состояния выполнения – то, что сводится к оптимизируемым метрикам. В геометрической задаче, например, – построить профиль трехмерной поверхности и получить ее характеристики в точке. В веб-сервисе – получить число запросов к базе на операцию, посмотреть, на что уходит время запроса, обратиться к Zabbix за показателями нагрузки. Датчик – это осциллограф, а не ОТК. Он не выносит fail/pass вердикт, а показывает объективную картину в виде чисел и слов, по которым агент оптимизирует результат генерации под требования задачи. Требования должны быть непротиворечивыми и достижимыми – иначе датчики показывают прогресс к цели, которой не существует.

У высокого комфорта есть следствие, которое я проверял на практике: он частично заменяет интеллект ^[3] модели. В комфортной среде знание уже лежит в контексте и в контуре верификации – и Sonnet закрывает тикеты сам, без плана от Fable, дешево и быстро.

Человек не участвует во внутреннем цикле “изменение -> проверка -> исправление”. Он настраивает среду, задает цель и оценивает итог, а не код.

Матрица: Agent Comfort × Human Comfort

Введем парное понятие – Human Comfort: сколько инженерной экспертизы человек должен добавить к своему намерению, чтобы агент выполнил задачу. Меньше экспертизы – выше комфорт. Максимум комфорта – требование на языке продукта, без технических деталей реализации: “при потере связи лодка должна безопасно остановиться и сообщить оператору причину”. Агент будет искать ответ на вопрос “где хранить величину таймаута?” В некомфортной среде вопрос пойдет человеку – вместе с ним упадут и Human Comfort, и FPSR. В комфортной ответ уже лежит в среде: в конвенциях проекта, в истории решений, в конфиге. Если для успеха агента нужен человек, способный написать исчерпывающий инженерный промпт или ответить на все уточняющие вопросы – Human Comfort низкий.

Два понятия дают матрицу из четырех режимов:

Swamp of Despair – Low Agent / Low Human. Легаси, слабый контекст, бедные инструменты. Инженер должен досконально знать систему, подробно объяснять ее агенту и все равно регулярно вытаскивать его из трясины. Платим токенами и инженерной экспертизой.

Cheap Lottery – Low Agent / High Human. От человека почти ничего не требуется: сформулировал желание – получил результат. Иногда ожидаемый. Но агент работает в среде, где плохо ориентируется и плохо проверяет себя, поэтому результат – лотерея, а когда агент возвращается с вопросами, ответить на них человек без инженерной экспертизы не может. Здесь живет большая часть vibe coding: отложенный риск, который срабатывает на проде или вычищается кочегарами на code review.

Heroic Prompting – High Agent / Low Human. Агент способен выполнить сложную задачу, но инженер каждый раз вручную загружает в него недостающее знание: архитектуру, ограничения, инварианты, способы проверки, особенности легаси. Результат как правило ожидаемый – но потому, что инженер в каждой задаче толкает агента к цели заново своим промптом-бульдозером.

Paved Road – High Agent / High Human. Нужное знание уже находится в среде: структура проекта понятна, инструменты доступны, датчики дают обратную связь, гейты проверяют инварианты. Человек формулирует продуктовое намерение, а агент сам добирает инженерный контекст из репозитория, спецификаций и истории решений. Дорога вымощена и служит каждой следующей задаче.

Гейты

Отдельно от комфорта стоит слой, без которого агентская разработка невозможна. Гейты – это детерминированные проверки инвариантов (в CI-мире Quality Gates). Тесты (юнит, контрактные, регрессионные), линтеры, статические анализаторы, архитектурные чекеры – для C++ я написал такой сам, archcheck ^[4], – метрики с пороговыми значениями. Они работают в детерминированном pass/fail режиме.

Гейты защищают архитектуру, инфраструктуру и пользователей – а заодно среду от самого агента. Он оставляет за собой дубли, устаревшие комментарии, вторую версию правды, и все это становится контекстом следующей задачи. Низкий комфорт порождает код, который делает среду еще хуже. Гейты разрывают эту петлю.

Продакт из Meta, с которого начиналась статья, решает эту проблему по-старому: его код уходит разработчику на финальное ревью. Гейт из живого инженера. Он работает, но не масштабируется – чем больше кода генерят агенты, тем больше ревью ложится на людей. Автоматические гейты забирают повторяемую часть этой работы – то, что можно выразить инвариантом и проверить механически. Так делится труд на Paved Road: инженер строит среду – комфорт и гейты. Агент в этой среде работает с продактом напрямую. Инженер перестает быть ревьюером каждого коммита и становится строителем дороги.

Agent Comfort в loop engineering

Индустрия уже трижды пыталась закрыть некомфортную среду надстройкой поверх нее. Сначала подробный план писал человек, а агент исполнял. Потом план поручили сильной модели: Fable загружает все знание о системе в план, Sonnet идет по нему. Обе волны – мертворожденная технология: знание тратится заново на каждую задачу, а среда как была непонятной агенту, так и осталась. Третья волна – loop engineering: не промптить агента, а проектировать циклы. В мае 2026 в Claude Code появилась команда /goal: формулируешь условие завершения, агент крутит итерации сам, а после каждого хода маленькая модель читает переписку и решает, достигнута ли цель. Это работает: Борис Черни, создатель Claude Code, за 30 дней сделал 259 PR ^[8], написанных самим Claude Code. Работу с контекстом эти три волны прошли поверху. Цикл крутится – лавэха мутится.

Экономика цикла определяется скоростью сходимости, а сходимость – средой: в комфортной среде цикл доходит до цели за меньшее число итераций. Сломать цикл очень просто: непроверяемая цель, противоречивые требования, переполненный контекст, датчики, оторванные от продукта, отсутствие ограничения по итерациям.

/goal в некомфортной среде – это попытка забить гол в темноте.

Loop engineering в среде с низким Agent Comfort имеет смысл, только если вы осознанно занимаетесь токенмаксингом ^[13] – расход токенов некоторые компании успели вставить программистам в KPI. Сейчас некоторые одумались ^[14]: Meta и Amazon сняли внутренние токен-лидерборды, Duolingo отозвал план мерить сотрудников использованием ИИ.

Кейс Rumba

В проекте матмодели гусеничной машины Rumba агент написал 12 788 строк кода. Датчиком и гейтом там служил механизм сценарного плейера: он прогонял тесты, которые Клод генерил пачками по спекам и замечаниям экспертов, выдавал трассу промежуточных состояний и вердикт по ним. Я настраивал среду: придумывал метрики и замкнутые проверки, находил документацию, заполнял пробелы в контексте и вычищал противоречия, когда агент путался. Как появилась Rumba и почему я выбрал написание с нуля – в “Клоде в шестернях” ^[15].

Как поднять Agent Comfort у себя

Признаки низкого Agent Comfort:

• Агент задает вопросы, ответы на которые лежат в репозитории.

• Перечитывает одни и те же файлы по несколько раз за сессию.

• Меняет код так, что он противоречит соседнему коду или документации.

• “Чинит” упавшие тесты подгонкой ожидаемых значений под фактические.

• Каждая сессия начинается с археологии: агент заново восстанавливает картину, которую уже строил вчера.

• В ответах и коде множатся “честные оговорки”: for now, placeholder, simplified, not verified, one honest caveat – агент заранее тихо снимает с себя ответственность за непроверенное.

Большинство этих симптомов сводится к двум причинам – противоречиям и дырам в контексте. Противоречие – две версии правды в репозитории: документация расходится с кодом и с другой версией себя, комментарий с реализацией, CLAUDE.md с реальной структурой проекта. Классика жанра – комментарий, переживший изменение кода:

// try all 4 directions
for (int dir = 0; dir < 8; dir++)

Человек часто такие расхождения фильтрует не задумываясь, потому что знает, “как на самом деле”. Агент не знает – и выбирает не ту версию. Дыра – отсутствие нужного знания, которое агент молча заполняет правдоподобной выдумкой.

Подъем комфорта – это два направления работы. Первое – контекст: искать и закрывать противоречия и дыры. Попросите вашего агента в режиме максимального думания найти все противоречия в рабочем контексте и проанализировать, как они влияют на его генерации. Возьмите себе за правило – когда агент путается, не исправлять его ответ, а находить все источники, которые его запутали, и удалять/исправлять неверные. Правило (constraint), положенное в контекст, в сессии не вечно: агент соблюдает (почти всегда) ограничение, пока оно живет в его окне, а окно деградирует.

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

Стоит отметить сдвиг, который ломает привычную интуицию ^[16]: датчики по-прежнему супер-полезны, но их изготовление перестало что-либо стоить. Обвязка для наблюдаемости всегда была дорогой скучной инженерной работой, которую сдвигали в конец бэклога, поэтому ее делали редко. Теперь прибор по выбранному ракурсу агент изготавливает за минуты. Дорогим ресурсом остался только выбор ракурса, за который ответственен человек.

Пока я дописывал

Вышел Claude Opus 5, и Anthropic опубликовала официальный гайд ^[17] по работе с ним. Рекомендация для агентного кодинга: модель работает лучше всего, когда получает полную спецификацию задачи заранее и дальше работает сама. Узнаете квадрант? Полная спецификация заранее – это Heroic Prompting: все инженерное знание снова выгружается в промпт.

Вторая деталь: гайд отмечает, что Opus 5 проверяет свою работу сам, и просит убрать из промптов инструкции “перепроверь”: они не отменяются зашитым поведением ^[18], а пересекаются с ним и ведут к потреблению лишних токенов. Для новых моделей Anthropic удалила больше 80% системного промпта Claude Code без потери качества – правила, защищавшие от слабостей прошлых моделей, стали шумом, конкурирующим за внимание ^[19] с настоящими инструкциями. Это еще раз подтверждает критическую важность контекста.

Официальные гайды отправляют в Heroic Prompting: это лучший режим из тех, куда можно попасть, не работая над средой. Paved Road придется строить самим.

Пока вендоры призывают писать исчерпывающие промпты, с другого конца подъехал олдскул. Роберт Мартин, автор “Чистого кода”, написал на днях ^[20]: “моя текущая стратегия – не читать код, написанный моими агентами”. Вместо чтения он окружает агентов гейтами: юнит-тесты, gherkin-сценарии, метрики качества, мутационное тестирование, покрытие.

Вывод

Инженеры тонут в ревью, потому что сегодня они сами работают гейтами – живыми и не масштабируемыми вместе с генерацией. Подъем Agent Comfort и автоматика инвариантов снимают эту работу с людей: агент работает в чистой среде и приходит к цели за меньшее число итераций, проверки не пускают в прод сломанное, а человек смотрит на результат и выбирает ракурс автоматической верификации.

Если вы дочитали до этого места – попробуйте дать прочесть эту статью вашему агенту в конце длинного сложного чата, полного ошибок и разочарований. Вы удивитесь результату.