"🧩 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"