Почему агентам для программирования, таким как Claude Code, нужен слой управления, а не просто лучшие promptы

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

Запрос формирует ход общения перед вами, но он не может контролировать всё, что связано с этим общением.

Codex и Claude Code уже содержат множество полезных компонентов. Однако отсутствует полная, портативная система, которая бы определяла, какие правила применимы, какой контекст важен, что может делать агент для программирования, как распределяется работа и что считается доказательством. Кто-то должен создать такой слой вокруг среды выполнения. Один из вариантов названия — ядро: слой управления, находящийся в вашем владении, который передаёт задачи от человеческих намерений до получения доказательств. В нём нет внутренних моделей, и оно само по себе ничего не выполняет.

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

Контекст был лишь симптомом

Первая заметная проблема — потеря контекста. Новая сессия часто не имеет представления об архитектуре, недавних изменениях или причинах выполнения задачи, поэтому перед возобновлением полезной работы необходимо провести ещё одну проверку. Такое повторение тратит время, ресурсы и терпение.

Больший объём контекста помогает, но не решает более глубоких проблем. Агент всё равно может следовать неверной процедуре, действовать с большей властью, чем следует, использовать нерелевантные данные или заявлять о успехе без доказательств.

Очевидным решением является добавление отсутствующих правил и информации о контексте в файлы AGENTS.md, CLAUDE.md или аналогичные файлы для инициализации. Это разумно, но недостаточно. Такие файлы действительно способствуют лучшему освоению, однако ожидать от них управления всем рабочим процессом — ошибка. Файлы для инициализации могут содержать стабильные правила и указывать на надежные источники информации. Они сами по себе не могут обновлять состояние проекта, выбирать подходящий контекст для каждой задачи, определять, что разрешено агенту делать, или проверять результаты.

В центре всего стоит один принцип: сначала определите, что означает «завершение» перед выполнением, а затем потребуйте доказательств его выполнения в конце.

Устранение повторений никогда не было главной целью. Искусственный интеллект превратился из эпизодического эксперимента в ежедневную неотъемлемую часть работы, и интересным вопросом стало, сколько ценности может дать среда, созданная с использованием обычных методов проектирования программного обеспечения. Искусственный интеллект появился одновременно через несколько каналов: в редакторах, в Xcode и VS Code, а также в таких инструментах, как Codex и Claude Code. Каждый из них облегчал вызов мощных моделей, но упрощенный доступ никак не способствовал организации процессов, происходящих вокруг такого вызова.

В хороший день агент может просмотреть код, объяснить незнакомую фреймворк-систему, предложить архитектуру или помочь с реализацией новой функции, и это может сильно напоминать совместную работу с другим разработчиком. Чем больше вы полагаетесь на это, тем важнее становятся сопутствующие вопросы. Когда два источника информации противоречат друг другу, что имеет приоритет? Какие правила применимы к данной задаче? Может ли агент принимать решение или только давать рекомендации? Если он говорит, что работа завершена, что именно вы должны увидеть?

Контекст отвечает на первую часть этого вопроса, поскольку предоставляет агенту соответствующие знания. Остальное касается того, как эти знания используются. Термин «управление» подходит для обозначения всего этого комплекса: практической связи между намерением, надежными знаниями, правилами, полномочиями, выполнением и подтверждением. Он остается практичным, когда ключевые этапы рабочего процесса достаточно ясны, чтобы их можно было проверить, исправить и повторно использовать.

Для инженера, которому нравится проектировать системы, в которых компоненты эффективно взаимодействуют, импровизированный подход к рабочему процессу с использованием агентов кажется расточительным. Это становится объектом проектирования, а не просто серией чатов, требующих постоянного контроля. Чтобы справиться с этим хорошо, необходимо долгое время наблюдать за собственными привычками: за тем, что вы проверяете перед началом работы над проектом, какие шаблоны вы повторно используете, когда замедляетесь и какие проверки действительно убеждают вас в завершении работы. Цель — превратить эти неявные привычки в действия, которые может выполнять агент, и в процедуры, которые может аудитировать человек.

Что может и чего не может сделать bootstrap

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

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

Размещение этого материала в файле AGENTS.md или CLAUDE.md значительно снижает затраты на адаптацию. Слово «bootstrap» служит разделителем и не является жалобой: хороший документ определяет минимальные условия работы и указывает агенту, где находится надежная информация. Документы Codex используют файлы AGENTS.md в виде слоев, общий размер которых ограничен, а Claude Code предлагает краткие инструкции к проектам, причем процедуры, используемые редко, выносятся в отдельные навыки. Оба аспекта описаны в документации поставщиков: руководство Claude Code по работе с памятью и руководство Codex к файлам AGENTS.md. Навык представляет собой повторяемую процедуру, которая может использоваться в разных проектах, а хуки позволяют задавать определенное поведение при каждом вызове. Тем не менее, какой-то другой механизм должен определять, когда применяется тот или иной инструмент и как проверяются его результаты.

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

Поэтому инструмент запуска должен предоставлять путь в систему, а не пытаться заменить саму систему.

От инструмента запуска к карте

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

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

Такое разделение также защищает смысловую структуру. Принятое решение определяет развитие проекта, отчет о статусе описывает конкретный момент, а результат теста фиксирует доказательства. Если объединить все три элемента в одну неразличимую память, старое наблюдение может начать выглядеть как текущая инструкция.

По мере совершенствования структуры она расширяется, охватывая политику управления памятью, сложность задач, объем необходимых усилий для размышлений и выбор подходящей модели, сокращения, преемственность между сессиями, а также проверку и координацию действий нескольких агентов. Полный список таких элементов скрыл бы суть архитектуры. Важно лишь то, что агент может постепенно открывать для себя эти аспекты в зависимости от требований работы. За этой структурой стоят четыре основные обязанности, которые не описывают все механизмы, но объясняют, почему они связаны между собой.

Некоторые знания должны сохраняться после окончания чата

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

Загружайте только то, что необходимо задаче

Агенту нужно достаточно информации, чтобы понять свою задачу, а не всё, что когда-либо хранилось в системе. Для небольшой правки кода могут потребоваться правила проекта и несколько файлов. Для сложной функции также могут понадобиться цели продукта, архитектурные решения, мнение специалистов и план проверки. Цель — минимально необходимый контекст, а не максимально возможный. Непрерывность означает возможность найти нужный материал в нужный момент, а не перенос всей истории в каждую задачу.

Наличие информации — это не разрешение на её использование

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

Для завершения требуется доказательство

Беглая речь не означает правильности, а правдоподобие — завершенности работы. Поэтому ядро системы определяет, что необходимо проверить, какие доказательства следует сохранить и где записать подтверждённое состояние. Если агент изменяет код и сообщает «готово», это означает лишь поступление заявления, и ничего больше. Проверка может включать прохождение тестов, успешную сборку, поведение приложения во время работы и зафиксированное состояние. Для других сфер требуются разные доказательства, но правило остаётся прежним: окончание диалога не означает завершения работы.

Организация как аналогия

Представьте компанию с зданием, компьютерами и отличным оборудованием, но без единого способа совместной работы. У неё есть потенциал, однако он не организован. Людям по-прежнему нужны общие знания, процедуры, право принятия решений, чёткие обязанности и контроль качества. Это сравнение довольно условное, ведь агент — это не сотрудник, а среда выполнения выполняет не просто функцию размещения людей за рабочими столами. Однако оно показывает, как взаимосвязаны компоненты: агенты выполняют определённые роли, инструменты — это оборудование, а среда выполнения — место, где происходит выполнение задач. Ядро представляет собой общий слой правил, знаний, методов и проверок, который позволяет им сотрудничать. Лучшие модели не обязательно приводят к лучшей системе.

Где находится этот слой

Ядро не конкурирует с Codex, Claude Code, Gemini или любым другим средством выполнения, появляющимся в будущем. Эти инструменты обеспечивают рабочую среду: модели, инструменты, сессии, настройки рассуждений, а также постоянно расширяющийся набор собственных подагентов, хуков и навыков. Слой управления работает внутри этой среды и регулирует три аспекта: что должно сохраняться, что разрешено агенту делать и какие доказательства считаются подтверждением выполнения задачи.

Ценность этого подхода растёт с каждым разом, когда новая версия среды выполнения включает функцию, похожую на уже реализованную вручную. Переписывание каждой функции среды выполнения отнимает время, которое лучше было бы потратить на проекты, которыми занимаются агенты. Более устойчивым решением является предоставление средам выполнения возможности управления выполнением, при этом слой управления остаётся портативным. Провайдеры различаются по моделям, инструментам, интерфейсам и стилю вывода, а портативность позволяет сохранять вашим правилам независимость от конкретного провайдера, не делая вид, что эти различия исчезли.

Управление не гарантирует надёжности

Запись правила не гарантирует, что агент его прочитает, поймёт или применит в нужное время. Документ с инструкциями может указывать на правильный протокол, но всё равно оставаться без внимания. Каноническое решение может быть сохранено идеально, в то время как его содержимое постепенно устаревает. Механизм выполнения правил может верно их соблюдать долгое время после того, как они уже перестали быть полезными.

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

Подобная система никогда не бывает завершенной или универсальной. Это личная настройка, которая тестируется, ломается и корректируется в течение месяцев. Она улучшает возможности для наблюдения за поведением агентов и его корректировки, однако ни одно правило, протокол, сокращение или механизм памяти не соблюдается идеально. Управление может облегчить проверку и исправление поведения, но оно не может сделать вероятностного агента детерминированным.

Три вопроса, которые следует задать в первую очередь

Потеря контекста — это то, что заставляет людей идти по этому пути. То, что удерживает их здесь, — это более серьезный инженерный вопрос: как следует спроектировать подход к работе с мощной моделью, уделяя столько же внимания любой другой важной архитектуре?

Так можно ли доказать, что работа завершена? Только тогда, когда критерии «завершения» были определены до начала выполнения, и результат содержит доказательства, соответствующие поставленной задаче. Без этого у вас есть лишь утверждение, а утверждение — это не доказательство.

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

1. Какие источники имеют право определять, что считается истиной?
2. Какие решения и действия требуют утверждения человека?
3. Какие доказательства покажут, что работа завершена?

Эти вопросы превращают отдельные функции ИИ в составляющие надежного рабочего процесса, а не просто в возможности, сосуществующие друг рядом. Не каждая незначительная просьба должна влекать за собой работу всей системы. Механизмы контроля должны соответствовать степени риска: быть более мягкими при низком риске и более строгими, когда ошибка может привести к серьезным последствиям. Модели обеспечивают необходимые возможности, а путь от поставленной цели до получения результата — это то, что создается на их основе.