Когда возможностей модели не хватает
1/2

🧐 В общении пару раз сталкивался с таким кейсом при обсуждении AI SWE - Spec-driven development. Все соглашаются, что БЕЗ подготовки проекта к работе с AI SWE, использование ИИ для работы с проектом возможно только в режиме ИИ-ассистента программиста.

Но сложности случаются и в, казалось бы, грамотно подготовленном к AI SWE проекте, с детальными спецификациями и хорошо проработанными процессами. Мы можем получить ситуацию, когда ИИ-агент генерирует код откровенно низкого уровня.

❓ В чем может быть дело?

Конечно, в каждом случае надо разбираться отдельно. Но я разберу не самые очевидные причины, которые возникают даже при, казалось бы, идеальной подготовке.

Допустим, у нас есть всё:

- действительно подробные инструкции;
- грамотно прописанные спецификации;
- процесс, разбитый на «правильные» этапы;
- код, структурированный на понятные модули;
- ясная и прописанная структура проекта;
- подробные JSDoc с перекрестными ссылками.

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

Часто слышу: «Мы же говорили, ИИ не может!». И да, и нет. Когда модель сталкивается с задачей, сложность которой превышает её «емкость», она действительно может не справиться. Разберём, что происходит под капотом.

Например, нам известны параметры модели DeepSeek: 128 голов внимания, 61 слой. При обработке контекста 128 голов первого слоя ищут свои паттерны, затем 128 голов второго слоя обрабатывают контекст с учетом результатов первого, и так далее. Взаимосвязи простраиваются вглубь на протяжении всех 61 слоев. В итоге на стадии prefill создается KV Cache — «конспект» контекста. Далее начинается процесс декодирования, где для генерации каждого нового токена модель обращается к этому кэшу, чтобы понять, на что обратить внимание.

Вернёмся к нашим проблемам. В чем возникла сложность?

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

... (продолжение - https://t.me/deksden_notes/12)

#post

Когда возможностей модели не хватает
2/2 (начало - https://t.me/deksden_notes/11)

Что можно сделать?

1️⃣ Упростить контекст. Первое и самое прямолинейное решение — снизить когнитивную нагрузку. Уберите из контекста лишние файлы или нерелевантную информацию. Чем меньше в контексте «смысловых групп», тем проще модели выстроить между ними правильные связи. Если это практически возможно — сделайте это в первую очередь.

2️⃣ Повысить «читаемость» контекста для ИИ. Вы считаете, что у вас хорошо прописанные спецификации? Проверьте, реализованы ли в них эти техники:

- Жесткая структура: XML-теги для разметки семантических блоков, а внутри — Markdown с четкой иерархией и использованием разных маркеров списков для разных уровней.

- «Якоря» для внимания: Уникальные идентификаторы после каждого требования (так называемая «китайская запись», создающая сильную локальную ассоциацию и учитывающая казуальность трансформеров): "Функция должна быть асинхронной. ::ID-SPEC-FUNC-ASYNC-01::".

- Few-shot примеры: 1-2 коротких примера кода, который уже следует вашим спецификациям.

- Группировка: Раздельные блоки для требований к логике, стилю, тестам и т. д.


Часто именно эти детали отличают просто «хороший» промпт от стабильно «работающего».

3️⃣ Гранулировать задачу. Ваш процесс уже разбит на этапы? Проверьте, достаточно ли они мелкие. Часто решение кроется в том, чтобы разбить «большой» этап на несколько «микро-задач»:

- Сначала план, потом код: Первым шагом заставьте модель сгенерировать детальный implementation plan (список файлов, классов, функций).

- Генерация по плану: Следующими шагами давайте модели по одному пункту из её же плана.


4️⃣ Использовать итеративное «фокусное ревью». Если после генерации все равно остались ошибки, переходите к режиму исправления. Возьмите сгенерированный код и узкую подгруппу требований (например, только требования к безопасности) и дайте агенту команду проверить и исправить код только по этим пунктам. Так мы принудительно фокусируем всю «емкость» модели на очень маленьком срезе задачи.

⁉️ А если даже это не помогло?

Вероятность такого исхода крайне мала. Если модель не справляется с четкой, сфокусированной задачей, это почти всегда означает проблему в самом контексте. Вспоминаем главное правило: «Мусор на входе — мусор на выходе». Значит, нужно вернуться и проанализировать, не содержит ли промпт противоречивых инструкций или скрытой двусмысленности.

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

␄
#post

🌲Запускаем VS Coding Agents в JetBrains

IDE от JetBrains мною исторически любимы, я к ним привык - основной инструмент это шарм (PyCharm). Но с ассортиментом ai extensions для джетов всегда было хуже чем для VS Code-based IDEs.

Но вот какой проект нашелся: https://github.com/wecode-ai/RunVSAgent

В настоящее время поддерживают как минимум RooCode, что уже неплохо.

Я, конечно, за автономного агента без встраивания в IDE, и за 100% ai swe flow, но вдруг кому надо ассистента в IDE?) Можно пробовать

#link
@deksden_notes

⚡️Статья на хабре: AI Software Engineering: От хаоса Vibe Coding к системной разработке с AI-агентами (введение в меморибанк)

Я - соавтор, с Дмитрием @filippov_dm

https://habr.com/ru/articles/934806/

#link
@deksden_notes

🔥 Субагенты в Claude Code
1/5

Решил написать обзор фишки субагентов в Claude Code (далее - сокращаем до общепринятого СС).

⏳ История вопроса уходит к первому публичному релизу СС. В ту пору субагенты были "обычным" инструментом Task - так он указывался в интерфейсе, но в исходном коде они сразу были названы AgentTool. Давайте для ясности далее будем называть его задачей (именно так, не субагентом или агентом, - почему объясню далее).

Это был простой инструмент: основной агент (будем дальше для ясности называть его **оркестратором**), это тот, с которым вы непосредственно общаетесь интерактивным чатом, вызывает инструмент Task, передаёт ему "задание" (промпт). Далее задача работает в отдельном контексте самостоятельно и возвращет результат оркестратору. В ходе работы задачи в интерфейсе СС мы видим некие сообщения о происходящих действиях, и все это пишется в json в сессию. Если есть желание почитать подробнее - можно использовать инструменты типа Claudia.

#post

(продолжение: https://t.me/deksden_notes/17)

🔥 Субагенты в Claude Code
3/5
Продолжим.

Что нам дал инструмент "задача"? Уже стало неплохо за счёт важного свойства - самостоятельного контекста задачи. Можно было делать длинные сессии работы оркестратора, промптом заставляя вести основную работу внутри задач. В результате последовательные линейные воркфлоу даже из значительного количества шагов выполнялис в челом неплохо. Можно было довести длительность сессии работы оркестратора до десятков минут, а самые талантливые умудрялись "выжимать" часы! Это важно, потому что время отражает количество сделанной полезной работы.

Какие были подводные камни? Их было несколько:

- управление работой инструмента "задача" осуществлялось оркестратором, и полностью зависело от него; когда у оркестратора в контексте было много информации, происходила деградация внимания, и он уже не мог внимательно и с требуемыми деталями прописывать задачи.
- задача наследовала от родительского процесса инструменты, и нельзя было настроить инструменты, доступные отдельной "задаче", в результате чего аналитические или поисковые задачи работали в контексте с им абсолютно не нужным условным менеджером БД postgres.
- работа всей системы (оркестратора и задач) велась с выбранной моделью

☑️ Резюмируем проблемы: точность промпта, контекст инструментов, модель.

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


#post

🔥 Субагенты в Claude Code
4/5

🤖 Субагенты

Так мы жили до версии 1.0.60, в которой появились "Sub-Agents" - субагенты. В этой версии добавлены принципиально важные дополнения к функциональности субагентов:
- теперь мы можем объявлять разные типы субагентов в специальной папке "agents" конфигурации (для проекта или на уровне системного пользователя);
- указываем модель, которая будет использована для субагента: opus/sonnet/haiku
- указываем набор инструментов, доступный субагенту
- для визуальной индикации запуска субагента в UI можно указать цвет

‼️ Чем принципиально важны нововведения? ☝️
Отдельный системный промпт кардинально решает проблему качества работы субагента: он получает свои собственные, чётко определённые и с гарантией попадающие ему инструкции. Больше нет необходимости требовать от оркестратора прописывать какие то детали задания субагенту - эти детали можно просто внести в промпт субагента. Теперь можно с высокой точностью собрать контекст под задачу! Это решает проблему "забывания" и игнорирования инструкций, генерации кода с ошибками, и подобное.

Далее - указание модели. Теперь стало возможным задачи планирования и анализа проводить "более умной" моделью opus, а непосредственное написание кода - дефолтным Sonnet. А простые задачи делегировать быстрому haiku. Удобно, и дополнительно повышает качество работы!

Определения инструментов позволяют дополнительно настроить контекст субагента, выключив ненужные ему инструменты, или, наоборот, подключив нужные MCP.

В результате мы получили возможность очень точной настройки процессов, построенных на субагентах. Качество работы звсей системы аметно повысилось, особенно при выполнении сложных workflow с многими этапами.

▶️ Как происходит выбор агента? Когда СС необходимо запустить субагента, система смотрит список доступных ей агентов. В зависимости от контекста команды запуска, по описаниям субагентов выбирается нужный. Стартуется субагент с указанием нужной модели и инструментов, ему загружается его системный промпт, а также задание оркестратора, и субагент приступает к работе.

▶️ Чем "субагент" отличается от "задачи"? Задача не кастомизируется - нет отдельного промпта, только промпт от оркестратора. Нет выбора модели или инструментов. Технически "под капотом" это один и тот же инструмент agentTool, но возможности кастомизации субагентов выводят их на новый уровень, делая заметной инновацией.

#post

🔥 Субагенты в Claude Code
5/5
🏁 ИТОГИ

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

Какие остались ограничения? Пока "глубина" вызова субагентов - два элемента. То есть работает схема "оркестратор" - "субагент", но нельзя делать вызов "Оркестратор" - "субагент" - "субагент". То есть, если вы в вашем воркфлоу вызовете другой воркфлоу на субагентах, это не заработает, потому что субагенты другого воркфлоу не смогут запуститься.

В итоге, построить процессы классическим функциональным подходом не выходит. Однако "вызов" процесса можно сделать в inline стиле, когда мы инструктируем агента перейти к указанному процессу, а по завершении - продолжить с места вызова. Для "надёжности" можно прописать "возврат" к месту вызова как задачу в TodoWrite. В итоге работают и "подпрограммы", хотя и способ немного хлопотный, требует внимательного промптинга и отладки при первых запусках.

Ограничения вложенных вызовов - оно в дизайне, а не техническое. Можно предположить что ограничение вызвано желанием предотвратить рекурсивные вызовы неясной глубины, которые могут случиться из за неполной детерминированности агентского процесса. Все таки - это не код, который выполняется всегда одинаково, в агентских процессах возможны варианты. Однако в будущем возможно изменение этого подхода и/или появление механизмов контроля. Думаю, необходима практика - давайте её получать!

#post
␄

Google Jules : фонтан новостей августа 2025

Буквально за короткое время у нас фонтан новостей от jules.

Первая, и самая важная: julse теперь не бэта! У нас релиз!
из хорошего: бесплатные задачи не отменили, они остаются. Коммерческие планы привязаны к AI подписке (Pro/Ultra). Higher access to the latest model (starting with Gemini 2.5 Pro)

* Jules (free): 15 daily tasks, 3 concurrent
* Jules (pro subs): 100 daily, 15 concurrent
* Jules (ultra subs): 300 daily, 60 concurrent

Из интересного: для pro/ultra туманно сказано что Higher access to the latest model (starting with Gemini 2.5 Pro). Намёк на 3.0?))

И технические улучшения:

* bun runtime добавлен
* теперь можно делать не просто branch с результатами работы, а сразу PR
* для старта задач позволяют делать снэпшоты окружения после скрипта инициализации - старт задач более быстрый
* интегрировали playwright в стандартный образ VM (!!!) и теперь можно обсуждать скриншоты и в целом проводить полноценные e2e тесты
* добавлен агент-критик (!!!) и теперь весь сгенерированный код проходит такое вот ревью; значит когда я добавляю в каждый процесс этап ревью, это вполне принятый подход;
* интерактивное планирование: задачу можно запустить в режиме обсуждения плана - важно когда план может быть не совсем очевидным для агента, и он готов его с вами обсудить в чате до утверждения;
добавили поиск к агенту: он ищет документацию, сниппеты кода и подходы к решению каких то задач! реально усиливает работу с последними версями библиотек, которые могут быть не знакомы модели;

Мощное развитие технологии! Jules радует значительно сильнее Gemini CLI. Когда же api для встраивания его в свой pipeline?

https://jules.google/docs/changelog

#news

Grok 4 в доступе

Что конкуренция животворящая делает! Теперь Grok4 доступен без подписки

https://grok.com/

#news
@deksden_notes

⚡️ Агентные процессы (Agentic Workflows) в Claude Code
1/2

Давайте поговорим о такой интересной штуке, как агентные процессы (workflows).

⚙️ Что такое агентные процессы (agentic workflows)?

Их важно отличать от обычных алгоритмических процессов:

· агентные процессы - это промпты для ИИ агентов, которые описывают некую последовательность действий
· исполняет эти процессы ИИ агент, мы используем Claude Code
· агентные процессы по своей структуре могут быть очень похожи на обычные алгоритмы - шаги, условные ветвления, циклы, "вызовы" других процессов, вызовы внешних команд
· суть агентского процесса - в возможности использования логики ИИ модели в процессе непосредственно;
· нечеткая логика ИИ является и самым сильным преимуществом, и важной особенностью процессов, с которой надо работать

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

❓ Как это сделать? Четких правил нет, я могу лишь обобщить практику, которую я использую. Уверен, что можно и нужно что то делать иначе, лучше, правильнее - но расскажу как я понимаю на сейчас.

⚠️ Важно: это мое субъективное мнение, которое совсем не претендует на правду, лишь резюмирует практику.

Паттерны и приемы для работы с агентными процессами

Я храню описание процессов в memory bank проекта в отдельной папке (wfs/) в виде md файлов. Чтобы запустить процесс, есть кастомная слеш команда, которая инструктирует агента прочитать некий файл и следовать инструкциям в нем.

1️⃣ Концепция "файлы-роутеры". Это такой md файл, инструкции в котором направляют агента для чтения других файлов, там буквально написано так: "Если (некое условие), то нужно прочитать файл (ссылка на файл) и выполнить инструкции в нем".

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

Поэтому цепочка "центральный роутер -> роутер группы процессов -> процесс" это стандарт в моем мемори банке. Пример: "index.md -> wf-dev -> wf-dev-1" запускает мой процесс "проработка эпика/фичи".

2️⃣ Концепция "mermaid схемы процесса".
Интересный факт: модели лучше понимают "язык" диаграмм mermaid для описания последовательности действий, чем текстовое описание. Впрочем, если подумать, - это логично: диаграмма короче, нагляднее, структурно построена, следует определенному синтаксису. Видимо, обучающие выборки моделей включали изрядное количество диаграмм в md файлах - а это преимущественно mermaid.

Мы можем использовать диаграммы для описания процесса: просто попросите агента вам ее сделать по тексту. Может быть вы удивитесь что она "не такая" - а на самом деле я пару раз так отлавливал недостаточно ясные формулировки в процессах (дело касалось циклов).

Идеальный вариант, если агент проставит вам для каждого шага процесса уникальный идентификатор (для wf-dev-1 у меня шаги это DEV1-1, DEV1-2, и так далее). Идентифкация шага вносит дополнительную ясность модели.

3️⃣ Вызов субагента

Самая важная часть вашего процесса. Я ВСЕГДА сейчас строю даже несложные процессы как взаимодействие центрального агента (всегда называю его оркестратором) и субагента. Почему? Экономия контекста, изоляция от спама результатами тулколов в центральный контекст. Задача оркестратора - только следить за выполнением основного процесса, а шаги мы все выполняем в субагентах.

Если для шага требуется формировать специфический контекст - то делается специальный агент под такую задачу, для которого прописываем специфический промпт. Задача оркестратора - только передать то, с чем работаем. А "КАК" работать - специализированный агент уже знает сам.

... (продолжение: https://t.me/deksden_notes/28)

#post
@deksden_notes

⚡️ Агентные процессы (Agentic Workflows) в Claude Code
2/2
( ... начало тут: https://t.me/deksden_notes/27 )

4️⃣ "Вызовы" процессов

Если нам нужно сделать "вызов" какого либо процесса в Claude Code, то я уже писал - сейчас существуют ограничения. Возможен только вариант "Оркестратор" - "Субагент", вариант "Оркестратор" - "Субагент" - "Субагент" уже не поддерживается. Поэтому попытка использовать субагента как "подпрограмму" не работает, потому что субагент лишается возможности вызова инструментов.

Зато "goto" к какому то процессу можно сделать легко, просто сказав "А теперь продолжай с процесса Х".

Что, если нам нужно не "goto", а имитация "вызова" процесса с возвратом в исходную точку? тут надо имитировать "стек", путем дополнительного инструктирования. В простых ситуациях, когда мы не очень ожидаем что оркестратор "забудет" наши инструкции, можно просто сказать "выполни процесс Х и после его завершения вернись и продолжай с этого места". Но есть нюанс: контекст. После выполнения процесса из за длительности и загрузки контекста, инструкция "возврата" может быть забыта.

Можно попробовать имитировать "стек" путем создания специального файла md с текущим контекстом - куда мы попросим оркестратора записать где мы сейчас находимся, какая текущая задача, какой процесс мы выполняем, что важное для нее надо помнить, что нужно делать следом. И инструктируем "выполни процесс Х и после его завершения прочитай файл Y и следуй инструкциям в нем".

В общем, с "вызовами" процессов - это исключительно творчество, в ожидании снятия ограничений на более надежные способы организации flow.

5️⃣ Внешние скрипты

Важно понимать - у моделей есть свои ограничения. Им сложно выполнять детерминированную работу (прочитать 300 файлов, из них убрать 5 файлов по некоему критерию, остальные переместить в другую папку). Но иногда в процессах есть необходимость такие активности делать.

Тут не нужно забывать о возможности легко вызвать любой внешний скрипт. Например, typescript-программу через tsx. Модель мало того, что может вызвать скрипт. Она вполне разумно и гибко может отреагировать на результаты его выполнения. А если вспомнить, что модель предварительно может написать код - то возможности и гибкость такого сетапа сложно недооценить.


✨ Что можно делать агентными процессами

"Много чего" (ц)

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

Например, у меня недавно задача создания ETL системы импорта пачками docx, pdf, xlsx, xls, img (всех видов), с OCR, извлечения из них сущностей (смыслов), промежуточное накопление этих сущностей, презентация их пользователю, трансформация в иную логику структурирования с презентацией этой логики пользователю и наконец сохранение "в другом формате" итоговой документации, но со ссылками на "источники" - все это заняло у меня чуть больше полдня. А теперь оцените сколько нужно времени чтобы написать код, решающий такие задачи. Фактически, просто за счет формирования чистой логики этого процесса с минимальным ее структурированием уже получена система, которая делает работу.

🏅 Мораль: агентные процессы - прикольная и мощная штука

Upd:

- Нюансы загрузки списка агентов: https://t.me/deksden_notes/29

␄

#post
@deksden_notes

⏳ Обновление списка агентов Claude Code

Небольшое, но важное уточнение. Если дорабатываете систему, и делаете новых агентов, то СПИСОК агентов загружается claude code ПРИ СТАРТЕ. То есть папка "agents/" обрабатывается и читается frontmatter у агентов ПРИ СТАРТЕ. Далее, похоже, эта информация НЕ обновляется, даже если вы обновили файлы на диске.

Например, вы добавили нового агента, и ждете чтобы workflows его подхватили. Нет, СС не "увидит" нового агента до перезапуска ("/clear" не помогает). Видимо, изменения модели или описания агента (вы можете яснее немного его обозвать) тоже подгружаются на старте.

Если вы меняете промпт агента, тут, вроде бы, попроще: он будет подгружаться при запуске нужного агента - изменения в промпте агент подхватит.

Общий вывод - чтобы не запутаться, перезапускайте сам СС при обновлении агентов! Благо флаг "--resume" вернет вас ровно в точку остановки предыдущей сессии.

П.с. Надо будет обновит пост про агентов

#post
@deksden_notes

☝️Agentic WFs vs традиционные алгоритмы

Прекрасный кейс родился у Дениса @ataden

У него совершенно гениальная способность встречать баги! В СС ему встретилось уже 2, и оба подтвердились на github. Очередной был вскрыт накануне, но оказался не багом, а фичей.

Исследуя траффик как СС "в потрохах" общается со своей штаб-квартирой, Денис обратил внимание, что файл CLAUDE.md совсем не упоминался в контексте, хотя документация говорит что он читается регулярно, как минимум - в начале сессии. То есть в контексте он быть должен, но его нету.

Ларчик открылся просто: имя файла на его машине было CLAUDE.MD (расширение написано крупными буквами). А ожидался файл CLAUDE.md (маленькие буквы в расшиении). Так как в СС файл грузится обычным ts кодом, а не промптом агента, то код не находил требуемого файла (с расширением ".md") и тихонько продолжал работу без каких либо жалоб.

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

Когда в чате CC попросили прочитать AGENTS.md, агент попытался, не нашёл файл, прочитал каталог, увидел похожий и молча загрузил его. Агентный код грузит файл.

То есть степень гибкости агентного процесса - она агентная! Вот какой интересный опыт 🔥

#post
@deksden_notes