Не совсем понятно с чего вы решили что 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! Молоток умнее плотника
В агентах/командах нынче можно указать модель: фронтмэттер тегом 'model: opus', например (или sonnet, haiku).
Полезно для агента, который пилит архитектуру или общий implementation plan - чтобы использовал opus. А для генерации кода оптимален sonnet: шустро, качественно. Для простых maintenance задач (типа, проверить ссылки в memory bank) наверное можно и хайку напрягать.
Опус доступен только в подписках Max, для Pro подписок - максимум sonnet.
На слабом канале для клиента круто работает жесткое кэширование и lazy load. Я это в всяких erp / админках смотрел, но и для доменов типа файлов / папок должно хорошо подходить.
Стандарты коммуникации с клиентами и глоссарий очень хорошо ложиться на применение LLM для выработки рекомендаций или даже модерации ответов сотрудников. Небольшое дообучение любой современной модели сможет обеспечить ответы в нужном формате, тоне и в соответствии с рекомендациями.
Не совсем понятно с чего вы решили что 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! Молоток умнее плотника
Ан - нет!
В агентах/командах нынче можно указать модель: фронтмэттер тегом 'model: opus', например (или sonnet, haiku).
Полезно для агента, который пилит архитектуру или общий implementation plan - чтобы использовал opus. А для генерации кода оптимален sonnet: шустро, качественно. Для простых maintenance задач (типа, проверить ссылки в memory bank) наверное можно и хайку напрягать.
Опус доступен только в подписках Max, для Pro подписок - максимум sonnet.
Используете aider. А чего benchmark их не сделали? Довольно показательная штука же. Контекст у вас уже более менее, 128k норм. Не 32k.
протестировали бы! Любопытно сравнить с фронтирными моделями.
На слабом канале для клиента круто работает жесткое кэширование и lazy load. Я это в всяких erp / админках смотрел, но и для доменов типа файлов / папок должно хорошо подходить.
Стандарты коммуникации с клиентами и глоссарий очень хорошо ложиться на применение LLM для выработки рекомендаций или даже модерации ответов сотрудников. Небольшое дообучение любой современной модели сможет обеспечить ответы в нужном формате, тоне и в соответствии с рекомендациями.
У ребёнка школу закрыли на карантин по ОРВИ до нового года на 2 недели. В итоге получилось длинные каникулы