Недавно я наблюдал, как Claude Code работает в проекте, где, конечно же, был CLAUDE.md еще и с инструкциями по использованию Haft. Сам Haft при инициализации добавляет туда необходимые правила, Haft skills и MCP-ядро служат дополнительным harness, помогая агенту не перескакивать через проблематизацию, проверку вариантов и другие части инженерного процесса.
Короче говоря – инфраструктура была на месте.
Но агент всё равно начал использовать неправильные инструменты и не вовремя. Вместо того чтобы сначала разобраться в проблеме, выдвинуть несколько гипотез и сравнить варианты, он почти сразу бросился решать задачу.
Я быстро это заметил только потому, что находился буквально в сессии. Моё внимание было там: я видел действия агента, остановил его и скорректировал.
Ничего страшного не произошло. Harness работает, но в этом треде последним уровнем защиты оказался человек.
Если бы это был неудачный goal loop, моего внимания внутри процесса уже не было бы. Я не могу утверждать, что агент обязательно пришёл бы к плохому результату: чаще всё-таки результаты хорошие, но, похоже, что в основном благодаря тщательной предварительной подготовке и моделированию.
Очевидно другое – если инженерный процесс в обычной агентской работе начал разрушаться, то, вероятно, адекватно исправить его может только белковый инженер.
Инструкция лишь описывает желаемое поведение
И вот мне на глаза попадается работа Google — From Correctness to Collaboration: A Human-Centered Taxonomy of AI Agent Behavior in Software Engineering.
В ней авторы собрали 91 проектный рул-файл, созданный ранними пользователями кодинг-агентов внутри компании, и построили таксономию “ожидаемого поведения”: там следование стандартам, качество кода, решение проблем, взаимодействие с разработчиком, и всё важное интуитивное.
Здорово. Как словарь для проектирования инструкций работа полезна. В ней хорошо видно, чего разработчики хотят от агентов и какие свои ожидания пытаются закрепить в правилах.
По мне так здесь важно приглядеться к объекту исследования чуть лучше.
Рул-файл просто говорит, как агенту следует себя вести. Просто – говорит. Он не показывает, как агент действительно вёл себя в конкретной сессии, соблюдал ли правила, какие решения отбросил и что в итоге изменилось в реальном проекте. Авторы и сами относят поведенческие проверки к необходимой дальнейшей работе))
Этот момент очевиден, но слишком важен, чтобы не задумываться о нём: файл — носитель инструкции, а фактическое поведение нашей системы — другой объект. Нужно предельно чётко понимать это и никогда не забывать.
AGENTS.md, CLAUDE.md или skills могут содержать отличный, условно лучший инженерный метод. Из этого ещё не следует, что агент применит его вовремя (или применит вообще), что не выберет “удобную” интерпретацию или не перескочит к первому правдоподобному решению.
В конце концов модели учат быть “полезными”, что бы это ни значило.
В моей практике Haft помогает ловить многие такие отклонения. Но даже этот опыт не даёт мне оснований утверждать, что какой-то конкретный harness ловит их все, больше или меньше. Но я точно знаю – с моими требованиями к формальности и онтологической точности Haft чаще полезен, чем нет, и голый рул-файл или эвритические инструкции эти требования удовлетворяют очень ограниченно.
Быстрые решения уничтожают важную часть инженерной работы
Самое тревожное в упомянутой Claude Code сессии — это то, что агент легко пропустил процесс, необходимый для серьёзного технического решения:
- сформулировать проблему;
- выдвинуть разные варианты и гипотезы;
- сравнить их по нескольким характеристикам;
- сохранить не только выбранный вариант, но и достойные альтернативы.
У технической проблемы редко существует одно безусловно лучшее решение (никогда). Один вариант проще внедрить. Другой легче откатить. Третий лучше масштабируется, но создаёт дополнительную операционную нагрузку. Некоторые варианты образуют Парето-фронт, но отдельные выигрывают по одним интересующим нас характеристикам и проигрывают по другим.
Подходящий выбор зависит от актуальных ограничений. А ничто не постоянно, и обстоятельства скоротечно меняются.
Поэтому для меня важна не только возможность найти хороший вариант, но и сохранение пространства вариантов, так как ранее отвергнутые идеи, если и не оказываются автоматически более подходящими в новых условиях, то могут быть отличными stepping stones к хорошему-новому!
Весь контекст инженерного исследования не надо восстанавливать, мы просто делаем небольшой шаг назад.
И вот, если агент слишком быстро/рано превращает одну гипотезу в условное “решение”, мы теряем не только альтернативы, но возможность пересмотреть выбор.
Human in the loop – это не просто оператор-надзиратель
Я затрудняюсь провести “границу мышления” между человеком и ИИ-агентом. Мне очень откликается тезис “расширенного разума”
Я вижу совместную с ИИ работу как симбиоз, и у нас есть абстрактный “ползунок” инвестирования человеческого внимания. Его положение следует выбирать в зависимости от сложности проекта, размера системы, количества участников, обратимости решения, цены ошибки.
Для совсем мелкой задачи достаточно посмотреть на результат и зеленые тесты (ну и на сами тесты… правда?), не осуждается)))
Для архитектурного решения нужен минимальный инженерный процесс рассмотренный выше – варианты, основания выбора, сохраненный анализ ограничений.
В серьёзном продакшене человек, на мой взгляд, вообще не должен полностью покидать контур. Везде где я видел “software фабрики” в которые человек не смотрит несколько дней, всегда оказывалось что потом несколько дней разгребали созданный код. Где выигрыш? Особенно если на второй день самостоятельной работы ИИ неправильно интерпретировал шаг плана, и выхлоп от следующего миллиарда токенов откатывается и выбрасывается в утиль?
Речь, конечно же, не о том, что инженер обязан читать каждую строку сгенерированного кода: с новыми скоростями итераций в разработке для большинства проектов такого требовать уже попросту глупо.
В статье ACM Queue Where to Draw the Line Крейг Соулз пишет, что по мере развития агентов построчное человеческое ревью может перестать быть центральной формой контроля. При этом за человеком остаются выбор проблемы, проверка соответствия результата цели и ответственность за последствия. База.
Я не вижу в обозримом будущем сценария, в котором из этого “инженерного контура ответственности” исчезнут живые инженеры. Кто-то заинтересованный всё равно должен корректно этот интерес выражать, нести ответственность.
Заинтересованный в чём? В обретении благ в реальности, изменении реальности каким-то “выгодным способом”. И как с таким интересом у ИИ? Или вы думаете, что можно просто наши интересы выразить в rule-file в размере 1-2 тысячи символов? А как дела с ответственностью?
Collaboration – свойство всей системы разработки
А теперь давайте вернемся к исследованию Google.
Как я уже сказал, нас интересует не только поведение агента и не только качество рул-файлов.
Нас интересует вся система совместной работы человека и AI:
- Живые проектные инструкции, которые поддерживаются вместе с проектом и не успевают слишком сильно устареть.
- Исполняемый harness, который проверяет порядок действий, допустимые инструменты и необходимые инженерные шаги.
- Память решений, где сохраняется не только финальный выбор, но и варианты, ограничения и причины отказа.
- Deliverables и улики для каждого существенного куска работы.
- Человек, который “двигает ползунок своего внимания” и остаётся ответственным за качество всей системы.
Ни один слой не заменяет остальные. Ни один не будет нормально работать без других:
- Инструкция без проверки может быть проигнорирована.
- Проверка без памяти не сохраняет пространство решений.
- Результат работы без улик подтверждающих что была сделана нужная работа лишь показывает, что некий объект (слоп-блоб!) появился, но не доказывает, что он решает нужную задачу (подумайте – достаточно ли тут в плане попросить агента просто “напиши на всё поведенческие тесты”).
- Никакие агенты и harness-процессы не способны адекватно принимать за нас проектные решения, особенно в долгосрочной перспективе.
Чувствуете, как внимание человека пронизывает все эти слои? Как сильно от человека зависит качество самого “harness”?
Простой код ничего не стоит. Инженерное мышление — бесценно
Я не вижу причины продолжать бояться AI и тем более пытаться любой ценой удержать старый способ работы. Избавьте себя от лишнего стресса.
В рамках экономики бизнеса навык написания простого кода полностью коммодитизирован. Это уже происходит, и в этом много пользы: хороший инженер может быстрее проверять гипотезы, исследовать варианты и создавать работающие системы.
Только следите за руками – хороший инженер обязан быть способным читать код, и думать не только императивно, но и декларативно. Как получать эти мыслительные навыки без написания кода своими конечностями – отдельная тема для размышления.
А еще важно не забывать про ценность способности элегантно, этично и системно проектировать – она никуда не исчезла, напротив – ценность этого навыка становится всё больше.
AI усиливает уже существующие в “белковых” мозгах способы мышления. Сильное инженерное мышление получает дополнительные рычаги. Если же медленное мышление заменяется “уверенностью модели”, вместе со скоростью получения результатов растёт и масштаб ошибки.
Поэтому самый главный harness – не AGENTS.md, не skill и не набор скриптов вокруг ваших агентов.
Самый главный harness – это ВЫ – человек вместе с вашими AI-агентами.
Этот harness нельзя один раз настроить и забыть. Его приходится развивать, проверять и адаптировать к сложностям конкретной работы. В ответственной системе человек может делегировать всё больше исполнения, но не саму ответственность.
В этой системе человек эволюционирует и становится умнее, становится способным решать более сложные задачи, которые раньше ему было не под силу решать, и решать их быстрее.
Вопрос лишь один – заинтересованы ли люди в этой open-ended эволюции?