🧩 Memory bank для существующих проектов :: Реверс-проектирование и реверс-документирование в brownfield
1/2

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

Но что делать, если хочется использовать меморибанк с существующим проектом, для которого нет меморибанка? Это - территория brownfield, и она значительно сложнее greenfiled.

Ситуация внедрения меморибанка в существующий проект требует творческого подхода. О чем необходимо подумать при старте такого начинания:

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

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

- документирование кода: jsdoc/docstrings в проекте уже составляют неплохую базу для ИИ агента;

- степень понимания проекта участниками: иногда есть реально работающие системы, которые НИКТО из сотрудников/подрядчиков не понимает полностью, потому что они долго эволюционно развивались, пережили ротации разработчиков, эволюцию бизнеса, меняющиеся требования, интеграцию с внешними системами - и все это в реальной жизни, без особой документации (которой иногда и не делали), со схемой работы в головах сотрудников (которые потом увольнялись без полной качественной передачи знаний). Такое и приводит к ситуации: система работает, но ПОЧЕМУ ИМЕННО ТАК - не известно достоверно никому; 

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

Совсем готовых рецептов нет, но я поделюсь практическими подходами, которые использовал сам в ряде проектов.

▶️ Базовый принцип: мы "строим" в меморибанке усровень абстракции "выше" кода, потому что именно этих уровней не хватает агентам для эффективной работы

▶️ Что за уровни? Тут на помощь приходят классические архитектурные паттерны (да, теперь мы говорим о ренессансе традиционного SWE, прости, agile!) - например, простым и практически удобным для применения будет паттерн C4, подробнее - https://t.me/deksden_notes/55

▶️ Верхний уровень L1 документировать просто - описываем что у нас за система, кто и зачем ей пользуется; концептуальная информация скорее, пректически - задаёт домент рассуждениям агентов;

▶️ L2 уровень очень важен: тут мы описываем крупные блоки вашей системы - назовём их подсистемами: databse, ui, api server, processing engine, - все что имеем; важно правильно выбрать "нарезку", чтобы это имело практический смысл. Например, если у вас огромный Api сервер, имеет смысл выделять в нем свои структурные блоки вроде аутентификации/авторизации, CRUD по модулям. "Крупность" нарезки блоков определяется так: фиче приложения желательно взаимодействовать с одним блоком - то есть, если "пользователь вносит заказ", то он взаимодействует с одним блоком базы данных. Так мы сможем в контекст агента положить всего один документ про подсистему БД "Заказы".

▶️ L3 Уровень - это фичи приложения, это "элементарные" блоки функциональности вашей системы. Делятся аналогично, по автономии: например, вы можете реализовать фичу "пользователь создаёт заказ в системе" отдельно от "пользователь редактирует заказ в системе". Самый многочисленный уровень для документирования. Про его сбор чуть далее.

▶️ L4: у вас уже есть, мы как раз строили мостик между L1 -> L4.

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

#post
@deksden_notes

🧩 Memory bank для существующих проектов :: Реверс-проектирование и реверс-документирование в brownfield
2/2

(.. начало тут: https://t.me/deksden_notes/66)

Немного практики:

🔵 Нет смысла документировать очевидные из кода вещи: агент может прочитать и воспринять что написано в коде. Делать дублирование логики функций в документации особенной ценности не имеет и будет забивать контекст - агент будет читать и документацию, и код.

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

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

🔵 Используем агентов:
- собраем полную карту апи-роутов сервера;
- исследовать и документировать схему из БД и связанных файлов кода, "вытаскиваем" максимум мета-информации;
- описать существующий UI: перечень экранов, их структурных элементов; data test id атрибуты для тестирования; идентифицировать основные actions в интерфейсе;
- call graph: агент может составить схему взаимодействия модулей - какие функции/методы вызывают другие модули/функции; конечно, специализированные системы (типа qoder) сделают это лучше, но и простыми способами зафиксировать "соседние ветки" дерева зависимостей несложно и весьма полезно.

🔵 Самое сложное - это вытащить нормальную структуру фич из кода. Тут может помочь фиксация типовых сценариев использования системы - как пользователи с ней работают. Элементы системы, которые участвуют в сценарии и могут стать отправными точками для фич. Пример: "Пользователь входит в систему: на экране логина он вводит имя пользователя и пароль. Система валидирует пароль и загружает главный экран с доступными пользвоателю разделами." (фича аутентификации, фича авторизации).

🔵 Используйте методологии CRUD анализа: еси в системе зафиксирована работа с некоей сущностью "заказ" - типа, "пользователь создал заказ", то для сущности "заказ" должны быть описаны все CRUD методы: как создавать, просматривать, менять и удалять такие сущности (бывает, что удаление часто выпадает при документирвовании).

🔵 Используйте методики Use Case Analysis: сценарии часто описывают только "happy path". Но что будет если пользователь ввёл неправильный пароль? 10 раз подряд? если при регистрации пользователь с таким паролем уже существует? Если api станет недоступно посередине регистрации? Такие сценарии называются "exception flows" и "alternative paths".

🔵 Анализ Перехода Состояний (State Transition Analysis) : если в системе есть сущности с состоянием, надо разобраться со схемой переходов состояний. Составляем агентами список состояний и карту возможных переходов между ними, и смотрим - документировали ли мы все, что касается доступных переходов. Как именно заказ из состояния on-hold переводится обратно в processing. Документировали ли мы как заказ из "paid" становится "shipped"? Такая карта здорово помогает найти пробелы в документировании.

🔵 В целом - практики "классического" "enterprise" моделирования процессов, проектирования, бизнес-инжиниринга будут работать на пользу процессу и тут - ведь мы решаем похожие задачи: если раньше эти практики использовались чтобы люди понимали как работает система в бизнесе, то теперь у нас даже более практичное применения - мы должны растолковать все то же самое ИИ агентам!

Надеюсь, дал какие то намётки подхода! И помните - задача творческая, жёстких методик пока не сформировано, все познается на практике.

🙇‍♂️ Пробуем, анализируем, делимся, улучшаем!


␄
#post
@deksden_notes

🖼️ Claude Code: Paste Images

Неужели починили старый баг?


Version 1.0.93:
• Windows: Add alt + v shortcut for pasting images from clipboard



ℹ️ Ну и кто не в курсе, в CC, да прям в терминал, "всегда" (когда это работало) можно было вставлять картинки (скриншоты например). Только на маке это работало через Control+V (а не привчынй Command+V), а на windows нынче сделали alt+V (тоже нестандартный). Ну - хоть так!

Кстати, drag and drop картинок работал давно и понадёжнее.


#news
@deksden_notes

ℹ️ Claude Code: подумать глубже


☝️ Тоже могут не все знать: в CC есть возможность для Соннета / Опуса включать режим thinking - для этого пишем "think hard" / "ultrathink".

▶️ У меня почему то не в каждом промпте это срабатывает, поэтому я останавливаю CC через нажатие Esc, и пишу отдельно в интерактивном режиме: think hard. После этого можно будет увидеть немного другим оформлением "мысли" модели. Соответственно, - например, поиск бага получает инъекцию сообразительности!

"Хозяйке на заметку" (ц)

#post
@deksden_notes

🔃 Claude Code: очередное обновление 1.0.94

На самом деле уже 1.0.95, но про .95 ничего не рассказали, а вот что у нас в 1.0.94:

• Vertex: add support for global endpoints for supported models
• /memory command now allows direct editing of all imported memory files
• SDK: Add custom tools as callbacks
• Added /todos command to list current todo items


Помимо того что можно быстро и удобно открыть CLAUDE.md уровня проекта/системы (/memory командой), появилась возможность посмотреть текущий список задач через /todos, что удобно - теперь не надо скроллить чат в поисках где там СС последний раз его трогала.

А вот что такое "Add custom tools as callbacks" - это надо разбираться, интересно. Пока из документации особо не понятно, будем искать)


https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md

#news
@deksden_notes

🔃 Claude Code: очередное обновление 1.0.97


Version 1.0.97:
• Settings: /doctor now validates permission rule syntax and suggests corrections


⚠️ Да, уже .0.98, но в 97 включили поддержку линтинга правил в настройках - и если у вас перестал работать ccstatusline, время проверить что за ошибки в settings. Если выявлены ошибки - то возможны всякие "спецэффекты" в виде отключения части прописанных в настройках штук, имейте ввиду!

#post
@deksden_notes

↔️ XML-like теги


Поговорим немного о конекст - инжиниринге. Хотел напомнить про простую, но крайне эффективную технику, которую можно применять в промптах, меморибанке, агентах.

Это XML-like теги. Рекомендации от "лучших собаководов" прилагаются!

https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/use-xml-tags

❓ Почему я пришу XML-like, а не XML? Потому что это не "классический" XML со схемой, атрибутами тэгов, нет - без этих усложнений. Усложнения в виде схемы путают модель без очевидной необходимости. Атрибуты - по желанию, если семантика подходит.

▶️ Мы просто используем тэги в угловых скобках для разметки структуры промптов. Какие задачи наиболее эффективно решаются:

- явная разметка начала и конца некоего семантического блока
- явное и однозначное указание вложенности блоков друг в друга

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

❓Какие теги применять? Конечно, семантические, что даёт дополнительный плюс. Пример:

<инструкции>
...

<некий_блок>
...
<вложенный_блок>
...
</вложенный_блок>
...
<и_еще_один>
...
</и_еще_один>>
</некий_блок>
...
</инструкции>

Думаю, идея понятна. В сложных случаях: <элемент_списка порядковый_номер="1" важность="обычная">


❓ Зачем такие сложности? Чтобы явно показать структуру, когда она не тривиальная. С тривиальной и маркдаун вполне подходит, а вот вложденные многоуровневые списки модель иногда "парсит" с ошибками: проверка может быть очень простая - попросите модель составить структуру вашего промпта с многоуровневыми нумерованными элементами структуры, можно иногда удивится!

❓ А как же маркдаун? Такие теги с ним вполне совместимы. Я пишу обычные md файлы и добавляю xml-like теги в "сложные места", где модель можнт неоднозначно определить логическое начало и конец блоков.

❓Можешь пояснить "за фрактальный промптинг"? Конечно, и, как ни странно - сабж и xml теги вполне себе имеют место быть: для авторегрессионных казуальных моделей (а это почти все современные трансформеры, с треуголными масками внимания на всех этапах обработки, включая prefill) - они "условно" читают текст слева направо, поэтому наличие уникального закрывающего тега для них "удобно".

ℹ️ Удобно в кастомной слеш команде делать так:

some_command.md:

Вот команда пользователя:
<команда_пользователя>
$ARGUMENTS
</команда_пользователя>

И дополнительно делай так: ...

❓ Что именно улучшают тэги? Только восприятие моделью
структуры промпта - содержательно тэги сами по себе не будут какой то магической «пилюлей».


#post
@deksden_notes

🥳 🎁 🎉 Маленький юбилей Claude Code: круглая версия v1.0.100

Жаль, что без release notes, багфикс релиз или какие то скрытые пока функции.

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

Пожелаем дальнейших успехов!


#news
@deksden_notes

☎ Сегодня я буду на звонке в канале у Алмаза

@aiclubsweggs - ИИчница

поговорим о меморибанках в частности и памяти для агентов в общем! Welcome!

18:30 msk

#news
@deksden_notes

📝 Агентская память - немного теории

Начнем шарить контент с созвона. Поговорим немного о памяти для агентов - чего это такое в целом. Довольно глобальная тема! 

▶️ При работе LLM все что есть в распоряжении модели - это контекст. Наверное, можно считать это текущей операционной памятью модели, где содержатся все сведения для выполнения текущей задачи. Создание "правильного" контекста - самое главное дело для обеспечения качественной работы модели и агентской системы. Но вот живёт контекст на время сессии работы с моделью, и он не бесконечен: кончился контекст, надо начинать новую сессию. Но новая сессия - все как в первый раз.

Когда мы помещаем модель в окружение, поддерживающее инструменты (tools, через functional calling), такая система становится агентом и получает возможность выполнения некоторых действий. Например, сохранения и извлечения необходимой информации, что даёт нам возможность создания системы памяти агента.

▶️ Название "память агента" довольно условное, потому что модель также владеет огромным объёмом информации "внутри" своих весов, но это "неизменная" память, она не меняется от задачи к задаче.

Для текущей задачи модель всегда использует свой контекст.

Роль памяти - помогать в формировании контекста. Безусловно, контекст можно сформировать и "руками", для каждой задачи промпты вводить, и все нужные сведения в контекст положить. Но память как раз и помогает избавится от необходимости каждый раз растолковывать агенту все заново - "каждый раз - как в первый раз!". Память позволяет сохранить сведения для бьудущего использования, и извлекать нужную для текущей задачи информацию.

🟢 Осознание роли памяти важно, когда решаешь - чего бы в этой памяти сохранить. Нужно ли агенту сведения об истории изменения файла? Для работы было бы полезно, но зачем они именно в памяти - ведь эти сведения у нас и так сохранены в истории коммитов git репозитория, и модель про это знает. Получается, хранение информации в памяти агента- дублирование, эти сведения несложно будет получить и без запоминания. Единственный момент: если эти сведения сохранены "заодно", например, в jsdoc шапке файла - экономим время/запрос модели с тулюзом.

🟢 Применяем фокусирование: память призвана обеспечить выполнение будущих задач. Например, сведения о легаси коде, который образовался в ходе рефакторинга. В будущих задачах он не участвует, поэтому из памяти все связанное с ним убираем: у нас не летопись, за летописью идём в git, вестимо! У нас своя фокусная задача.

☝️ Итак, важно понимать домен термина "память":
- память - это про контекст инжиниринг
- память = механизм сохранения + загрузки сведений
- фокусная цель: обеспечить выполнение будущих задач
- способ: предоставить необходимые сведения в контекст для выполнения задач моделью

#post
@deksden_notes

🔧 Агентская память : реализации

Давайте поговорим как все устроено в этой агентской памяти. Запоминать и извлекать сведения определённо можно совершенно по-разному.

Принципиальные варианты реализации:
- 👈 контекст сохраняет/извлекает система ИИ агента - "обвязка" модели, не сама модель;
- 👉 агент "самостоятельно" рулит сохранением/извлечением информации из памяти

Посмотрим - какие готовые механизмы памяти есть в существующих ИИ системах.

1️⃣ Модули памяти общего профиля для чатов

До всего движения с агентами мы работали с LLM в чатах. Для чатов и были сделаны первые варианты "памяти". Сведения были довольно простые: блокнотик с фактами о пользователе. Механизм сохранения: тулюз инструмента записи в память. Механизм извлечения: помещаем "блокнотик" в системпромпт.

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

⊖ все чаты чанкаем, чанки контекстно обогащаем, делаем саммари чатов - и генерим эмбеддинги всего этого богатства

⊖ эмбеддинги укладываем в любую базу с векторным поиском расстояний - нынче это может быть даже Postgres/SQLite, но классикой будет Chroma/Qdrant/FAISS и товарищи

⊖ эмбеддингами обрабатываем запрос пользователя

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

⊖ итоги реранкаем быстрой моделью и отдаём в контекст модели

⊖ модель формирует ответ пользователю

У chatgpt не все чаты сохранены, а только "полезная" на взгляд какой то модели выжимка - https://help.openai.com/en/articles/8590148-memory-faq


Что то в этом духе работает сейчас у антропиков.
https://support.anthropic.com/en/articles/10185728-understanding-claude-s-personalization-features#h_4afb5dcf4b

Известны сторонние реализации: mem0, zep - они, конечно, предлагают дополнительные фичи.

▶️ zep (https://getzep.com/)

Интересно, что продукт называется Agent Memory (https://www.getzep.com/product/agent-memory/ ), но его фичи ясно указывают что это память скорее для чат бота, причём с поддержкой специфических бизнес-данных.

Штука работает на их же open source проекте Graphiti (https://www.getzep.com/product/open-source/), предлагает RAG на графовой базе (neo4j) + специальную поддержку темпоральных тэгов. То есть поиск учитывает временной аспект, и если пользователь летом любил кроссовки адидас, а осенью полюбил кроссовки puma, то поиск вернёт разные данные в зависимости от указанного временного периода.

Есть возможность подключения сервиса через MCP сервер.

▶️ mem0 (https://mem0.ai/)

Продукт также очень похож на zep, тоже скорее предназначен для чатботов, с сохранением фактов и поиском по перепискам. Тоже есть MCP сервер, всё как полагается (https://mem0.ai/openmemory-mcp).

Фичи для такого класса продуктов стандартные - https://docs.mem0.ai/platform/features/platform-overview

Эмбеддинги, гибридный поиск, реранкинг, фильтры, граф.

#post
@deksden_notes

📝 Память AI SWE Tools

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

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

Давайте рассмотрим механизмы Cursor, Claude Code, ...

1️⃣ Cursor

Наверное, первым стоит упомянуть один из самых популярных инструментов - Cursor. Система памяти (в Cursor это называется rules) основана на добавлении в контекст файлов из папки .cursor/rules/. Это - единственный инструмент, который «придумал» добавлять целыми папками.

▶️ Схема «скоупов» (на что распространяются правила из папки .cursor/rules) зависит от того, где размещена эта папка. Если в корне проекта - то распространяется на все файлы проекта. Можно разместить папку «выше» по иерархии папок, тогда она будет «действовать» на все проекты, расположенные внутри этой папки. Если разместить в домашней папке пользователя, то правила будут применяться для всех проектов пользователя в этой системе.

Соответственно, правила, размещенные внутри папки «ниже» по иерархии «действуют» по работе с файлами из этих папок и «глубже» по иерархии.

☝️ Таким образом, можно назвать это «иерархическим» скоупом правил, на базе иерархии папок.

Правила у Cursor описываются в файлах mdс (это обычный md + yaml frontmatter). Дополнительно к "иерархическому" скоупу на папках, во frontmatter конкретного файла можно установить индивидуальные правила скоупа:
* Always: всегда применять это правило
* Auto Attached: применять при совпадении glob паттерна с файлом, с коротым работает ИИ агент
* Agent Requested : позволить агенту определить - следует ли включать это правило; но в этос случает требуется предоставить описание правила
* Manual : правило добавляется только "вручную" пользователем через @file упоминание файла с правилом в чате

Да, правила поддерживают схему "упоминания" какого то файла через указание его пути в конструкции вида @file_name. В этом случае содержимое файла будет обязательно добавлено в контекст системой, и не потребует использования тулюза через ИИ - что экономично по времени/токенам.

Cursor поддерживает спецификацию AGENTS.ms (https://agents.md/), но с некоторыми ограничениями: скоуп - только проекта, файл должен быть в корне проекта.

ℹ️ Вот ссылка на полную документацию: https://docs.cursor.com/en/context/rules

Также стоит упомянуть довольно интересный отдельный механизм Memories (https://docs.cursor.com/en/context/memories). Это когда ИИ агент извлекает из чата с пользователем правила, и самостоятельно формирует иp них файл правил со скоупом проекта.


2️⃣ Claude Code

Claude Code предоставляет, пожалуй, самые развитые средства работы с памятью. Используется файл с именем (внезапно!) CLAUDE.md, стандарт AGENTS.md не поддерживается.

- файл уровня проекта (стандартно, в корне)
- файлы выше уровня - на любой цепочке иерархии вплоть до папки пользователя "~", где может "жить" файл в "~/.claude/CLAUDE.md"; благодаря этому при старте в проекте монорепо в папке вложенного проекта - подтянется в том числе файл CLAUDE.md для всего проекта
- Organization-level memory management - что то на энтерпрайзном (возможность указывать правила уровня всей организации, управляется devOps компании);
- поддерживаются файлы CLAUDE.md вложенные в текущую папку: они аналогично будут обладать "иерархическим" скоупом, то есть распространяться при работае с файлами из нужной папки
- важно обращать внимание на расширение файла - ".md", если использовать ".MD", то не сработает
- поддерживается императивный @file импорт файлов (экономия тулюза)
- просматривать текущую память можно слеш-коммандой "/memory"
- есть команда чата "# {инструкция}" для быстрого добавления инструкции в текущий CLAUDE.md файл
- нет тонких настроек скоупов: glob - скоупов, по решению агента

Почитать подробнее тут: https://docs.anthropic.com/en/docs/claude-code/memory


#post
@deksden_notes

📝 Память AI SWE Tools

Продолжаем дальше: ..., Gemini, Codex, Kiro, ...

3️⃣ Gemini CLI

Гугл использовал отличную тактику - просто скопировать все фичи у лидера - Claude Code, потому система памяти практически идентична, но используем, конечно, файлы GEMINI.md. Правда, есть возможность (конфиг context.fileName) указать имя файла памяти любое, а AGENTS.md поддерживается по-умолчанию. То есть можно настроить gemini на чтение CLAUDE.md файлов

* все возможности "иерархического" скоупа на месте (папки выше/ниже корня проекта поддерживаются);
* поддержка @file импортов
* поддержка команды /memory
* индикатор в чате какие файлы памяти "подтянуты" в контекст;
* есть инструмент работы с памятью для ИИ агента: https://github.com/google-gemini/gemini-cli/blob/main/docs/tools/memory.md

ℹ️ Подробнее: https://github.com/google-gemini/gemini-cli/blob/main/docs/core/memport.md

С документацией заментно хуже чем у Claude Code.

4️⃣ Codex CLI:

В последнее время Codex CLI очень динамично развивается. Новая реализация на rust работает шустро и сделана довольно удобно. Фич пока категорически не хватает по сравнению с лидерами, но развитие довольно активное, поэтому даже несколько недель меняет картину. Из критического на сентябрь 2025 - мне не хватает сессий.

Память в Codex выполнена аналогичным образом:
* стандарт AGENTS.md поддерживается
* поддерживаются иерархические AGENTS.md файлы.
* глобальный файл в ~/.codex/AGENTS.md
* файл проекта - в корне проекта
* файлы "ниже" в иерархии - специфические для файлов из этих папок;
* просмотр памяти - только упоминание загруженных файлов в /status

ℹ️ С документацией тоже не особо густо: https://github.com/openai/codex/blob/main/docs/getting-started.md#memory-with-agentsmd


5️⃣ Kiro

Первая IDE с явной поддержкой режима SDD (spec-driven development) в противовес vibe coding: https://kiro.dev/docs/chat/vibe/

В части организации памяти - принципы похожие, но сделано все немного самобытно: если для девелопмента фич используется процесс requirements -> design -> implementation, то для организации памяти используется концепция Steering файлов (steering - "подруливающие" файлы, интересный и довольно точный термин). Это почти полный аналог rules/.md Файлов других агентов, которые подмешиваются в контекст.

* живут в проекте в выделенной папке .kiro/steering/
* немного в изначальной концепции похоже на концепцию меморибанка, просто, но "по науке":
* product.md : описание продукта, аудитория, топовые фичи, деловые цели;
* tech.md : техстек - зависимости, инструменты разработки, тех ограничения;
* structure.md : организация файлов, схема именования, импортов и архитектурные решения;
* дополнительные файлы: описывают какие-то аспекты системы;
* скоуп файла, как у cursor rules: always (включать всегда), fileMatch (по глоб паттерну в fileMatchPattern), manual (добавлять этот файл вручную через `#имя_файла`)
* можно добавить линк на файл, чтобы поддерживать steering айл в текущем состоянии через #[[file:{relative_file_name}]]

ℹ️ Доп документация тут: https://kiro.dev/docs/steering/

#post
@deksden_notes

📝 Память AI SWE Tools

Закончим обзор китайскими инструментами - там тоже есть достойные варианты!

... Trae и Quoder.



6️⃣ Trae

Интересен инновационным режимом SOLO, но сегодня мы про систему памяти, которая очень базовая:

* скоуп - правила пользователя (settings - rules - user rules)
* правила проекта: .trae/rules/, пользовательские md файлы
* frontmatter не применяется, настройки скоупа нет;

в целом - это все что можно сказать. Довольно скудно! прочитать тут: https://docs.trae.ai/ide/rules-for-ai?_lang=en


6️⃣ Qoder


‼️ Один из самых интересных релизов последнего времени. Релиз упакован рядом иновационных и интересных фишек:
- repoWiki : огромный подробный автоматически создаваемый/обновляемый wiki по проекту,
- quest mode : их тейк про spec-driven development,
- быстрый code search : graph + векторный поиск (возможно, задействуют и repowiki)
- несколько моментов про long-term memory, про что мы и поговорим подробнее

Система памяти похожа на Cursor:
* .qoder/rules папки для правил
* скоуп - проект
* есть тюнинг скоупа правил: manual / agent decides / glob pattern matching files / always
* есть система памяти: memory


▶️ Агент автоматически хранит структурированную информацию о проекте:
* персональные предпочтения (Personal Preferences): стиль кода, подходы к разработке (test-forst development), пользовательские правила;
* извлечённый опыт (!!!): решения для повторяющихся ошибок, общие шаги для решения проблем, инстуркции по сборке и развёртыванию проекта (build/deploy), извлечённые уроки из проведённых рефакторингов и исправления багов (lessons learned)
* база знаний проекта : архитектура/структура, техстек, api/subsystems integration

▶️ Агент использует следующие источники для информации:
- чаты с пользователем: извлекаем явные указания и неявные паттерны
- логи работы агента: анализируем итоги работы для понимания что работает и что не работает;
- структура проекта и документация: извлечение семантической карты проекта

▶️ Для поддержания памяти в актуальном состоянии, агент производит оценку всех записанных фактов по следующим критериям (критерии весьма интересны, кмк):
- насколько релевантны записи для будущих задач
- точность и актуальность информации
- влияние на выполнение задач

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

▶️ Помимо этого, агент регулярно производит "ревизию" системы памяти:
- дедупликация: объединение дублирующейся/пересекающейся информации
- устранение конфликтов: устраняются выявленные противоречия в записях
- механизм "забывания": убираем нерелевантную или устаревшую информацию, основываясь на частоте использования и актуальности

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

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

Почитать подробнее:
* блог - https://qoder.com/blog
* документация, rules: https://docs.qoder.com/user-guide/rules
* memory: https://docs.qoder.com/user-guide/chat/memory

#post
@deksden_notes

⚒️ Codex : небольшие ремарки


На данный момент мой основной рабочий инструмент, который работает 24/7 (ну - не совсем, но все таки), и в пару потоков - это СС.

Но я всегда смотрю альтернативные инструмены.

🟢 После выхода GPT-5 таким инструментом стал Codex CLI. Мало того, что он довольно бодро развивается, так ещё и модель, которая работает в нем - очень умная. GPT-5-Medium / High Thinking отлично справляется с вопросам, на мой взгляд, заметно превосходя Opus 4.1.

Но тулинг вокруг модели пока довольно сырой! Мало того что не хватает почти всего, что есть в СС: сессии - да, продолжить чат нельзя, нет субагентов, нет /memory команды, нет /context, нет statusline / ccusage. В общем - как жить - хз.

⚠️ Неожиданно возникли определённые вопросы с агентским поведением модели: упорно "тупит" при запуске моего оркестратора, запуская его в синхронном режиме, и ожидая ответа. Где то - умная, но тут - почему не в фоне? Как вы понимаете, "переключить" как в СС в фоновый режим через Ctrl+B в кодексе нельзя, такой фишки нету! Проблемы, как мне кажется, в недостаточно отладенных системных промптах кодекса и описании тулов. Клод тут с начала года "полирует" тему регулярно. Например, чтобы избежать подобных кейсов в СС запуск bash сопровождается таймаутом в 2 минуты, так что через 2 минуты процесс продолжится. Сколько процесс может висеть в кодексе - я не проверял, но точно больше 2 минут!

▶️ На мой взгляд - кодекс штука интересная, но в данный момент выглядит как нишевая, для решения "сложных" задач или отдельных тем. Например, пускать кодекс как MCP сервер с Cc, для генерации "второго мнения". Я её попробую к ещё к фронтэнду подпустить - посмотрим как там оно, ещё и с playwright MCP работать будет.

В общем, текущая премиум подписка остаётся за клодом.

#post
@deksden_notes

🎁 Jules опять немного обновился

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

Полезная мелочь, но не могу не отметить уверенный темп развития продукта

https://jules.google/docs/changelog/

#news
@deksden_notes

☝️ ХоЗАЯке на заметку

простите за каламбур, просто пост про ЗАЮ: z.ai

Как подключить модель GLM в Клод Код и получить (по бенчам) модель на уровне Соннет 4 с ценой $3/$15 в месяц с приличными лимитами! Даже без акции это будет $30. Весьма интересно, чтобы попробовать - я вот собираюсь затестить попозже.

* про модельки тут: https://z.ai/model-api

* про подписку тут: https://docs.z.ai/devpack/overview

* про использование с СС тут: https://docs.z.ai/devpack/tool/claude


Пишите в чат, кто попробует - любопытно же!

#post
@deksden_notes

Хабр: Claude Code - субагенты


Не прошло и недели, как хабр расчехлился с модерацией статьи!

Сабж тут:

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

Примерно то же самое что было в канале, но немножко причесано

#post
@deksden_notes