Есть паттерн, который я всё чаще замечаю в сообществе. Человек начинает плотно работать с LLM - и постепенно уходит куда-то не туда. Строит себе сложную систему агентов с ролями, slash-командами, свормами, оркестраторами, поэтапными воркфлоу, “режимом плана” и т.д. Пётр Стайнбергер метко назвал это “Claude-pilled” - человек настолько погружается в тулинг вокруг Клода, что начинает верить: чем сложнее система, тем лучше результат.
Я так не думаю. И чем дальше, тем больше убеждаюсь в обратном.
Что такое “Claude-pilled” воркфлоу
Один из популярных примеров - “gstack” Гарри Тана, CEO YCombinator, активно высмеиваемый в твиттере.
Куча slash-команд. Агенты с ролями. Промпты для этих агентов, судя по всему, сгенерированы автоматически Клодом несколько месяцев назад и с тех пор не особо пересматривались. В инструкциях - много лишнего, много противоречий, много очевидного, что только мешает модели нормально работать. Задачи декомпозированы до уровня “в какой пакетик положить функцию” и “на какой строчке прописать интерфейс”.
Понимаю, откуда это берётся. Claude со своими плагинами, агентами и структурированными воркфлоу буквально подталкивает к этому. И в какой-то момент человек думает: раз уж я всё равно настроил агента - пусть он делает всё строго по правилам. Поэтапно. С чёткими инструкциями на каждый шаг.
Проблема в том, что модели это не помогает. Это мешает.
Почему микроменеджмент агентов - это шаг назад
Frontier-модели - Opus, GPT-5.5, и т.д. - умеют принимать решения самостоятельно. Они могут писать 8000 строк кода залпом, в моменте решить, в какой пакет что положить, исходя из спеков и контекста проекта. Им не нужно, чтобы вы разжёвывали каждый шаг.
Когда вы создаёте жёсткий воркфлоу правилами, которые применяются ко всем задачам одинаково - вы отнимаете у модели гибкость, которая и делает её полезной. Реальные задачи всегда содержат что-то незапланированное. Что-то, что выясняется в процессе. Что пользователь не договорил, например. Жёсткая система агентов на это не реагирует - она выполнит строго по инструкции. И вот у вас некомпилирующийся код в репо, пять циклов QA после этого, задача откатывается назад - и вы тратите гораздо больше времени, чем если бы дали модели чуть больше свободы с самого начала.
Агентам нужно не разделение ответственности. Им нужно убрать неизвестные переменные.
Как делаю я
Мой подход выглядит намного скромнее на бумаге, но работает лучше на практике.
Я общаюсь с моделью как с синьор-инженером, представляя себя в роли продакт-овнера. Не прописываю каждый шаг - вместо этого за 5 - 7 минут обсуждаю задачу, формулирую один текстовый документ (для удобства агента и чтобы не потерять контекст), и после этого агент работает 2 - 8 часов и делает то, что нужно.
Без триллионов slash-команд, трех агентов-специалистов по написанию джаваскрипта и “роев агентов”. Без декомпозиции до уровня строчки кода. Не с “режимом плана”, а с планом.
Да, первый блин иногда комом - прототип может быть неидеальным. Но проблемы мои в 4 из 5 случаев в том что спецификация была плохая, а не “не понял в какой пакет положить интерфейс”, т.е. проблема во мне. Те, кто работает с чётким воркфлоу, получают более предсказуемый первый результат, но тратят на планирование не 5 минут, а полчаса и больше.
Про токены - потому что это важно
Сложные воркфлоу потребляют огромное количество токенов. Claude Code с его планированием в Markdown, тикетами в GitHub, субагентами, чтением одних и тех же файлов по 10 раз при каждом выполнении - это всё токены, и их немало.
У меня в Builder контекст хранится в одной сессии. Компакт настроен так, что переносит продуктовую информацию - решения, намерения, контекст задачи - а не техническую детализацию по коду. Это в разы эффективнее по токенам.
Теоретически при чётком воркфлоу с несколькими агентами простые фазы могут закрывать более дешёвые модели. Но проблема в том, что перенос контекста из сессии в сессию и его правильное сжатие - это вопрос, который в мире AI-агентов до сих пор нормально не решён - смысла воевать с моделью не вижу.
Почему всё это - пережиток 2025 года
Все стратегии менеджмента контекста, которые сейчас используют в харнесах типа Claude Code, появились по конкретной причине: старые версии Opus теряли около 40 очков IQ просто потому, что контекст заполнялся. Отсюда и компакты, и тикеты, и поэтапное планирование - попытки обойти ограничение модели на уровне тулинга. Моделям начиная с gpt-5.5 это не нужно.
Я считаю, что это должно решаться на уровне модели: нормальный контекст в 300K - 1M токенов, хорошие нативные компакты, меньшая чувствительность к “протуханию” контекста. А не слой за слоем костылей в харнесе.
Жалко людей, которые платят приличные деньги, страдают от багов с кэшированием и строят всё более сложные системы поверх фундаментальных ограничений модели, а вся проблема в том что в подходе к работе до сих пор пережитки прошлого возрастом в год.
Что дальше
Я сейчас буду пробовать кодифицировать более структурированный подход в Builder - попытаться взять лучшее из обоих миров: скорость и простоту моего текущего подхода плюс часть предсказуемости более чёткого воркфлоу. Получится или нет - посмотрим.
Главное, что хочу донести: если вы строите сложную систему агентов, остановитесь и спросите себя - это реально нужно задаче, или вы просто увлеклись тулингом? Frontier-модели в 2026 году умнее, чем системы, в которые их пытаются упаковать.