Это развитие концепции Мемори банка довольно известное и популярное. В репозитории есть отдельный очень полезный раздел, как автор оптимизировал процессы - очень полезное чтение.
Хотелось бы отметить, что сам меморибанк довольно базовый по функциям именно как меморибанк: структура хранения информации в нем без наворотов.
Мощным эту реализацию делают очень хорошо проработанные процессы на базе custom modes курсора. Тут ничего не скажу - действительно хорошая реализация реального SDD (Spec driven development). Интересно смотреть над развитием проекта но уже для СС.
Разбивка промпта на группы (желательно семантические) облегчает модели применение этих правил - ей не нужно собирать в разных местах промпта правила одного типа
Не совсем понятно с чего вы решили что Open SWE какое то отношение имеет к нашей теме. Кроме общих буковок и концепции агенты + документация - особых пересечений нету. А кто выдумал в статье написано, со ссылкой: > Memory Bank - это концепция, представленная в виде официальной инструкции для Cline Поэтому не совсем понятный тезис
При разработки агентских систем действительно основным результатом работы является тот или иной вид промпта - инструкции ИИ агенту, кастомные команды, и прочая документация в мемори банке являются промптам.
А при использовании таких систем команды довольно короткие - запуск того или иного процесса. Беседы случаются при разговорах о возможностях системы, или про обратную связь от её использования.
Пакуете репомиксом полный проект, чтобы и спеки, и код, и тесты были в репо.
Потом обычным образом общаетесь в чате: спрашиваете как посоветует реализовать такую то фичу, с вариантами. Проанализировать что то. Объяснить как работает и устроено. Оценить конструкцию какой то подсистемы.
Пока проект влезает в Гемини - такая деятельность - одно удовольствие: не нужно индексировать, нет агентских поисков, все оч быстро в режиме вопрос-ответ.
Для небольших проектов сработает и один файл, вы правы: меньше думать над структурированием и проще сопровождать/пишете все в один файл.
Но с ростом проекта архитектура не масштабируется. Пример: фуллстек приложение next js. Для любых действий с самим api routes в контексте агента избыточны все сведения об архитектуре фронтэнда или playwright тестов. Если у вас все прописано в одном файле, оптимальный контекст собрать не получится. А с какого то размера файлов и проекта это будет представлять проблему: у клода контекст всего 200к токенов.
Такая проблема есть, например, в дефолтном сетапе Kiro.
Поэтому принцип декомпозиции работает очень просто: собрать контекст из разных файлов агентом довольно просто, а разобрать один большой файл при необходимости оптимизации контекста - никак.
Ну - вот такие цифры для небольшого greenfield проекта на ts с 35k loc + 15k loc доков.
Я делал оценку трудоёмкости, когда СС взял всю историю коммитов в репозитории, считал сколько строк кода, для каких файлов добавлено, изменено или удалено, смотрел сами файлы. В итоге он делал оценку трудоёмкости написания этого кода/документации "руками", если бы это писал человек уровня Senjor Developer. Получилась оценка в 5800-6300 человеко-часов.
Потом сделал такой отчёт: СС смотрел фактические даты и время создания файлов, время создания коммитов - и считал фактически потраченное время. Оказалось около 125 часов.
Итого х50 получается к "ручному" написанию.
p.s. Да, тут надо учесть что Greenfield, для brownfield нужно будет кучу времени на переработку и документирование потратить. Плюс язык и платформа знакомые ИИ, плюс следование всем методикам изначально. Так что можно оценить это как "оптимистичный" коэффициент в приближённых к идеальным условиях
Действительно, код с докстрингами/jsdoc сам себя документирует. но ему в дополнение стоит добавить более высокоуровневые концепции - паттерны, принятые в проекте, схему подсистем, схему взаимодействия разных частей, и прочая информация более высокого уровня.
Разбивать контекст лучше тем, что тогда его легче собрать под каждую конкретную задачу для агента, не загромождая ненужными ему сведениями. Например, в момент написании кода модуля агенту не нужно знать о системе тестов или gitflow проекта.
Там получились довольно очевидные результаты: если людям дать инструмент, который они не особо знают (или совсем не знают), и начать применять его для задач, которые не очень подготовленные для инструмента, то ничего хорошего не выйдет.
AI SWE требует методики прежде всего, и определённой подготовки проекта. С ними работает весьма прилично. Лично имею вполне положительный опыт на средних проектах около 100k loc на мейнстримовых языках (ts/python).
да, это же не инструмент "отучения" СС от "плохих манер" отправлять телеметрию разрабам. Он просто заменяет основной ИИ движок, остальная функциональность без изменений.
К сожалению, СС не является open source, поэтому сделать версию без телеметрии не выйдет. Можно немного изучить что именно она шлёт в каждом конкретном случае, в паблике есть старый "слив" кода от апреля 2025 (https://github.com/ripgrim/anon-kode)
Неправильно применённые инструменты в деле, в котором разбираешься плохо - могут дать плохие результаты. Казалось бы - кому это может быть не понятно, и кто будет спорить? "Сдуру можно - ... повредиться!"
Но использование ИИ даёт иллюзию что именно ИИ инструменты достаточно умные, чтобы их применение не подчинялось этому правилу. Finally! Молоток умнее плотника
Это развитие концепции Мемори банка довольно известное и популярное. В репозитории есть отдельный очень полезный раздел, как автор оптимизировал процессы - очень полезное чтение.
Хотелось бы отметить, что сам меморибанк довольно базовый по функциям именно как меморибанк: структура хранения информации в нем без наворотов.
Мощным эту реализацию делают очень хорошо проработанные процессы на базе custom modes курсора. Тут ничего не скажу - действительно хорошая реализация реального SDD (Spec driven development). Интересно смотреть над развитием проекта но уже для СС.
Разбивка промпта на группы (желательно семантические) облегчает модели применение этих правил - ей не нужно собирать в разных местах промпта правила одного типа
самый конец статьи - ну и ники у меня везде консистентные)
Приходи ко мне в чат в телегу!
Информация помимо официальной документации и официальных курсов собирается в твиттере, профильных телеграм каналах, реддите. Пожалуй, основное - там
-
Кое что я писал в своём тг-канале! Посмотри, думаю будет полезно
Не совсем понятно с чего вы решили что Open SWE какое то отношение имеет к нашей теме. Кроме общих буковок и концепции агенты + документация - особых пересечений нету.
А кто выдумал в статье написано, со ссылкой:
> Memory Bank - это концепция, представленная в виде официальной инструкции для Cline
Поэтому не совсем понятный тезис
При разработки агентских систем действительно основным результатом работы является тот или иной вид промпта - инструкции ИИ агенту, кастомные команды, и прочая документация в мемори банке являются промптам.
А при использовании таких систем команды довольно короткие - запуск того или иного процесса. Беседы случаются при разговорах о возможностях системы, или про обратную связь от её использования.
Структурированная память нужна чтобы сохранить консистентность проекта. Это не совсем связано с потоком задач!
Если агент прочитал Мемори банк и собрал себе правильный контекст под задачу - то даже вашу одну редкую задачу он сделает с более высоким качеством!
Иначе вам прийдется полагаться или на разработчика агента, которым вы работаете (условный курсор), или на агентность и инициативность модели.
Когда считаем человеком часы, мы просто делаем оценку трудоемкости а часах работы.
А как вы эти человеко-часв будете вкладывать, с каким графиком - 8часов/5 дней, 12 часов / 7 дней - кже другой вопрос.
Я бы сказал что структурированная память - первый краеугольный камень ai swe. Но не единственный!
Дальше добавляем процессы, дальше добавляем прослеживаемость - и уже похоже на технологию.
Пакуете репомиксом полный проект, чтобы и спеки, и код, и тесты были в репо.
Потом обычным образом общаетесь в чате: спрашиваете как посоветует реализовать такую то фичу, с вариантами. Проанализировать что то. Объяснить как работает и устроено. Оценить конструкцию какой то подсистемы.
Пока проект влезает в Гемини - такая деятельность - одно удовольствие: не нужно индексировать, нет агентских поисков, все оч быстро в режиме вопрос-ответ.
Какое задание вам сложно прописать?
Для небольших проектов сработает и один файл, вы правы: меньше думать над структурированием и проще сопровождать/пишете все в один файл.
Но с ростом проекта архитектура не масштабируется. Пример: фуллстек приложение next js. Для любых действий с самим api routes в контексте агента избыточны все сведения об архитектуре фронтэнда или playwright тестов. Если у вас все прописано в одном файле, оптимальный контекст собрать не получится. А с какого то размера файлов и проекта это будет представлять проблему: у клода контекст всего 200к токенов.
Такая проблема есть, например, в дефолтном сетапе Kiro.
Поэтому принцип декомпозиции работает очень просто: собрать контекст из разных файлов агентом довольно просто, а разобрать один большой файл при необходимости оптимизации контекста - никак.
ну - я ж не руками все цифры считать буду))
ну и не претендую на академическое исследование - иначе бы мы с вами статью на arxive обсуждали бы
в этом смысле - да, "оценка эффективности использования компьютера напечатана на компьютере". На бересте вроде бы неуместно
Ну - вот такие цифры для небольшого greenfield проекта на ts с 35k loc + 15k loc доков.
Я делал оценку трудоёмкости, когда СС взял всю историю коммитов в репозитории, считал сколько строк кода, для каких файлов добавлено, изменено или удалено, смотрел сами файлы. В итоге он делал оценку трудоёмкости написания этого кода/документации "руками", если бы это писал человек уровня Senjor Developer. Получилась оценка в 5800-6300 человеко-часов.
Потом сделал такой отчёт: СС смотрел фактические даты и время создания файлов, время создания коммитов - и считал фактически потраченное время. Оказалось около 125 часов.
Итого х50 получается к "ручному" написанию.
p.s. Да, тут надо учесть что Greenfield, для brownfield нужно будет кучу времени на переработку и документирование потратить. Плюс язык и платформа знакомые ИИ, плюс следование всем методикам изначально. Так что можно оценить это как "оптимистичный" коэффициент в приближённых к идеальным условиях
Верно.
поэтому у меня в меморибанке есть папка architecture/ где описано "что сделано" и папка guides/ где описано "детали и как этим пользоваться"
В итоге собирается довольно качественный контекст
Действительно, код с докстрингами/jsdoc сам себя документирует. но ему в дополнение стоит добавить более высокоуровневые концепции - паттерны, принятые в проекте, схему подсистем, схему взаимодействия разных частей, и прочая информация более высокого уровня.
Разбивать контекст лучше тем, что тогда его легче собрать под каждую конкретную задачу для агента, не загромождая ненужными ему сведениями. Например, в момент написании кода модуля агенту не нужно знать о системе тестов или gitflow проекта.
Исследование проводили, да.
Там получились довольно очевидные результаты: если людям дать инструмент, который они не особо знают (или совсем не знают), и начать применять его для задач, которые не очень подготовленные для инструмента, то ничего хорошего не выйдет.
AI SWE требует методики прежде всего, и определённой подготовки проекта. С ними работает весьма прилично. Лично имею вполне положительный опыт на средних проектах около 100k loc на мейнстримовых языках (ts/python).
да, это же не инструмент "отучения" СС от "плохих манер" отправлять телеметрию разрабам. Он просто заменяет основной ИИ движок, остальная функциональность без изменений.
К сожалению, СС не является open source, поэтому сделать версию без телеметрии не выйдет. Можно немного изучить что именно она шлёт в каждом конкретном случае, в паблике есть старый "слив" кода от апреля 2025 (https://github.com/ripgrim/anon-kode)
Неправильно применённые инструменты в деле, в котором разбираешься плохо - могут дать плохие результаты. Казалось бы - кому это может быть не понятно, и кто будет спорить? "Сдуру можно - ... повредиться!"
Но использование ИИ даёт иллюзию что именно ИИ инструменты достаточно умные, чтобы их применение не подчинялось этому правилу. Finally! Молоток умнее плотника
Ан - нет!