В эпоху, когда искусственный интеллект перестал быть просто инструментом для генерации текста и превратился в полноценных автономных агентов, способных писать код, тестировать его и деплоить, перед разработчиками встает новый, критически важный вопрос: как управлять этими цифровыми сотрудниками так, чтобы они не только были эффективны, но и не разорили нас своими запросами к API. Долгое время доминировала парадигма «жесткого контроля»: мы даем агенту детальные инструкции, ограничиваем его действия и требуем строгого соблюдения протоколов. Однако последние инсайты от ведущих экспертов в области LLM (Large Language Models) предлагают радикально иной подход. Оказывается, ключ к экономии и эффективности кроется не в микроменеджменте, а в доверии к собственному суждению самого ИИ.
Эта концепция, которую можно назвать «архитектурой доверия к суждению», была недавно озвучена в ходе дискуссии с командой разработчиков Claude Code. Идея заключается в том, чтобы позволить таким мощным агентам, как Fable (или Opus), самостоятельно принимать решения о том, как выполнять задачи, вместо того чтобы диктовать им каждый шаг. Это не просто вопрос удобства; это стратегический шаг к оптимизации вычислительных ресурсов. Когда мы позволяем ИИ самому решать, нужно ли писать тесты для маленького изменения в тексте или достаточно запустить легковесную модель для простой правки кода, мы экономим токены — а значит, и деньги — без потери качества результата.
В этой статье мы подробно разберем, как работает эта система, почему она эффективнее традиционных методов промпт-инжиниринга, и как вы можете внедрить подобные практики в свои рабочие процессы, даже если вы находитесь в России и используете локальные или доступные через прокси решения. Мы посмотрим на конкретные примеры из реальной разработки, разберем структуру памяти агентов и объясним, как настроить делегирование задач между моделями разной мощности.
01От микроменеджмента к автономии: смена парадигмы
Традиционный подход к работе с AI-агентами часто напоминает управление роботом-манипулятором на заводе. Оператор дает четкую команду: «Возьми деталь А, поверни на 90 градусов, прикрепи к детали Б». Если агент отклоняется от инструкции, результат считается ошибочным. В контексте LLM это выражается в создании огромных, детализированных системных промптов, которые предписывают агенту: «Никогда не запускай тесты для мелких изменений», «Всегда используй мощную модель для любого кода», «Сначала напиши план, потом код».
Проблема такого подхода в том, что он игнорирует контекст. Мир разработки программного обеспечения не черно-белый. Иногда изменение в одном месте требует перепроверки всей страницы, а иногда сложная логика бэкенда может быть реализована с помощью стандартных паттернов, не требующих глубокого анализа. Жесткие правила создают шум и заставляют агента тратить ресурсы на тривиальные действия, которые он мог бы пропустить, если бы обладал контекстным пониманием.
Новый подход, предложенный Саймоном Уиллисоном и командой Anthropic, предлагает делегировать это контекстное понимание самому агенту. Вместо того чтобы запрещать запуск тестов для мелких изменений, мы говорим агенту: «Используй свое суждение, чтобы решить, нужны ли тесты». Это звучит абстрактно, но на практике это означает, что модель анализирует масштаб изменений, их критичность и историю проекта, чтобы принять взвешенное решение. Это переход от «робота по инструкции» к «помощнику с опытом».
02Пример из практики: Тестирование как функция суждения
Давайте рассмотрим конкретный пример, который привел Саймон в ходе своего блога. Представьте, что вы вносите правку в текстовый файл: меняете заголовок на сайте. Традиционный агент, получивший инструкцию «всегда запускать тесты после каждого изменения», потратит значительное количество токенов на запуск интеграционных тестов, которые, скорее всего, пройдут успешно, но не добавят ценности.
Если же мы даем агенту Fable право на суждение, он анализирует тип файла (текст, а не код), масштаб изменения и потенциальный риск. На основе этого анализа агент принимает решение: тесты не нужны. Экономия токенов здесь может показаться незначительной в одном случае, но при сотнях таких операций в день она складывается в существенную сумму, особенно с учетом того, что тарифы на API постоянно растут.
Более того, это снижает «усталость от принятия решений» для разработчика. Вам не нужно вручную проверять, запустил ли агент тесты или нет. Вы доверяете его логике. Если агент ошибается и пропускает критический баг, это становится сигналом для корректировки его системы памяти или контекста, а не причиной для возврата к жестким правилам.
03Делегирование задач: Стратегия «Главный архитектор — Рабочие лошадки»
Самый мощный инструмент оптимизации, о котором идет речь, — это не просто разрешение агенту принимать решения, а архитектурное разделение труда между моделями разной мощности. Идея, подсказанная Джесси Винсентом, заключается в том, чтобы использовать мощные, дорогие модели (такие как Claude Opus или Fable) только для задач, требующих глубокого анализа, планирования и синтеза. Для же рутинных, механических задач следует использовать более легкие и дешевые модели (например, Haiku или аналоги в других экосистемах).
Представьте себе структуру команды. У вас есть старший архитектор (мощная модель), который понимает общую картину проекта, принимает стратегические решения и контролирует качество. И у вас есть команда младших разработчиков (легкие модели
Источник: Simon Willison ↗