Comments 37
Хайп LLM проходит и лично у меня до сих пор вопрос в их возможности быть полезными на реальных проектах с большой кодовой базой. Тут на хабре была статья про исследования, что они могут даже замедлять работу инженеров.
Исследование проводили, да.
Там получились довольно очевидные результаты: если людям дать инструмент, который они не особо знают (или совсем не знают), и начать применять его для задач, которые не очень подготовленные для инструмента, то ничего хорошего не выйдет.
AI SWE требует методики прежде всего, и определённой подготовки проекта. С ними работает весьма прилично. Лично имею вполне положительный опыт на средних проектах около 100k loc на мейнстримовых языках (ts/python).
Хотелось бы какие-то цифры увидеть, а не просто "весьма прилично". Это крайне субъективная оценка и в исследованиях как раз показательно, что субъективное сокращение времени выполнения задач при использовании LLM легко превращается в объективное увеличение.
Ну - вот такие цифры для небольшого greenfield проекта на ts с 35k loc + 15k loc доков.
Я делал оценку трудоёмкости, когда СС взял всю историю коммитов в репозитории, считал сколько строк кода, для каких файлов добавлено, изменено или удалено, смотрел сами файлы. В итоге он делал оценку трудоёмкости написания этого кода/документации "руками", если бы это писал человек уровня Senjor Developer. Получилась оценка в 5800-6300 человеко-часов.
Потом сделал такой отчёт: СС смотрел фактические даты и время создания файлов, время создания коммитов - и считал фактически потраченное время. Оказалось около 125 часов.
Итого х50 получается к "ручному" написанию.
p.s. Да, тут надо учесть что Greenfield, для brownfield нужно будет кучу времени на переработку и документирование потратить. Плюс язык и платформа знакомые ИИ, плюс следование всем методикам изначально. Так что можно оценить это как "оптимистичный" коэффициент в приближённых к идеальным условиях
Я верно понял что оценка эффективности LLM проводилась самой LLM?
Штука невероятно полезная, в том числе и на больших проектах, и на всяких экзотических языках. Да, в плохо организованных, плохо типизированных проектах, работает хуже. Но все равно супер полезно.
Я бы сказал что структурированная память - первый краеугольный камень ai swe. Но не единственный!
Дальше добавляем процессы, дальше добавляем прослеживаемость - и уже похоже на технологию.
ИИ ассистенты уже похожи на технологию, потому что они уже позволяют эффективно выполнять задачи и дают (ну лично для меня) экономический эффект. Структурированная память больше похожа на какое-то управление проектом, но лично в моих проектах просто нет такого потока задач, чтобы это было актуально.
Структурированная память нужна чтобы сохранить консистентность проекта. Это не совсем связано с потоком задач!
Если агент прочитал Мемори банк и собрал себе правильный контекст под задачу - то даже вашу одну редкую задачу он сделает с более высоким качеством!
Иначе вам прийдется полагаться или на разработчика агента, которым вы работаете (условный курсор), или на агентность и инициативность модели.
Для технических деталей (паттерны, стандарты кодирования) лучшим источником является сам код. Хорошо написанный, самодокументированный код с комментариями в нужных местах часто лучше любого отдельного гайда.
Вместо десятка .md файлов (tech_stack.md, patterns/, guides/, workflows/) у меня есть один мощный README.md для бизнес-контекста и сам код для технического. Этого более чем достаточно для большинства проектов.
README.md (бизнес-логика, флоу) + Код (реализация, техдетали) = Полный контекст.
Вот с чем не раз сталкивался - АПИ "документировано", но часто нет достаточных описаний на параметры функций (разрешенный набор, нужно/не нужно освобождать (и как это делать) и т.п.) и самое главное - нет примеров, как с помощью этого апи что-то делать.
Действительно, код с докстрингами/jsdoc сам себя документирует. но ему в дополнение стоит добавить более высокоуровневые концепции - паттерны, принятые в проекте, схему подсистем, схему взаимодействия разных частей, и прочая информация более высокого уровня.
Разбивать контекст лучше тем, что тогда его легче собрать под каждую конкретную задачу для агента, не загромождая ненужными ему сведениями. Например, в момент написании кода модуля агенту не нужно знать о системе тестов или gitflow проекта.
README.md (ЗАЧЕМ) + CODE_GUIDE.md (КАК ИСПОЛЬЗОВАТЬ) + Код (КАК РЕАЛИЗОВАНО) = Полный контекст v2
CODE_GUIDE.md (или ARCHITECTURE.md)
Это один дополнительный файл в корне проекта. Не папка, не сложная структура, а просто один документ.
Его цель: Быть тем самым связующим звеном между бизнес-логикой из README и кодом. Он отвечает на вопросы "Как?" и "Почему?" на более высоком уровне, чем комментарии в коде.
80% результата при 20% усилий.
Мне кажется вы не дооцениваете workflow где мы прописываем инструкции для каких-то дейтсвий: исправение бага, новая фича, или других задач.
Например субагент, который после завершения задачи запускается и проверяет по некоторому своему workflow всё ли агент сделал. Сделал ли новую ветку, закомиттел, добавил ли описание в документацию, обновил ли канбан-доску и т.д. И под каждую специфичную задачу или требование можно реализовывать свой workflow.
Для небольших проектов сработает и один файл, вы правы: меньше думать над структурированием и проще сопровождать/пишете все в один файл.
Но с ростом проекта архитектура не масштабируется. Пример: фуллстек приложение next js. Для любых действий с самим api routes в контексте агента избыточны все сведения об архитектуре фронтэнда или playwright тестов. Если у вас все прописано в одном файле, оптимальный контекст собрать не получится. А с какого то размера файлов и проекта это будет представлять проблему: у клода контекст всего 200к токенов.
Такая проблема есть, например, в дефолтном сетапе Kiro.
Поэтому принцип декомпозиции работает очень просто: собрать контекст из разных файлов агентом довольно просто, а разобрать один большой файл при необходимости оптимизации контекста - никак.
Очень насыщенная статья, спасибо!
Хорошая статья, лайк и подписка.
Было бы фантастично, если бы вы добавили ссылку на git, где вот все уже организовано как показано в статье. Что бы можно было на примере пробовать делать свое.
Но, «чит-код» с полным контекстом не будет работать вечно, когда проект вырастет больше чем 1 млн.токенов, и не будет вмещаться в контекст Gemini 2.5 Pro, мы естественным образом перейдем к более «навороченным» процессам планирования.
На самом интересном месте остановились.
Все-таки проект, умещающийся в окно gemini - это не совсем репрезентативный пример промышленной разработки.
Также кажется по опыту, что вот эти сложные фреймворки с большим объёмом требований и перекрёстными ссылками между документами не очень хорошо работают, LLM без указаний все равно редко будет пользоваться этими ссылками, а часть из большого объёма информации явно потонет в контексте.
а как описываете задание для Gemini если не секрет? Попробовал пару раз, но пока что много глюков
Пакуете репомиксом полный проект, чтобы и спеки, и код, и тесты были в репо.
Потом обычным образом общаетесь в чате: спрашиваете как посоветует реализовать такую то фичу, с вариантами. Проанализировать что то. Объяснить как работает и устроено. Оценить конструкцию какой то подсистемы.
Пока проект влезает в Гемини - такая деятельность - одно удовольствие: не нужно индексировать, нет агентских поисков, все оч быстро в режиме вопрос-ответ.
Какое задание вам сложно прописать?
"На ИИ-топливе": очень неплохой художественный перевод английской контрукции "AI-fueled", мне понравился. В наше время таким уже не заморачиваются, а тупо пишут кириллицей английские слова.
Я бы добавил репозиторий промптов. Ибо наверное в итоге листинг отлаженных промтпов и должен стать основным воспроизводимым артефактом результата разработки систем на нейротяге.
При разработки агентских систем действительно основным результатом работы является тот или иной вид промпта - инструкции ИИ агенту, кастомные команды, и прочая документация в мемори банке являются промптам.
А при использовании таких систем команды довольно короткие - запуск того или иного процесса. Беседы случаются при разговорах о возможностях системы, или про обратную связь от её использования.
Ну и ссылку оригинал Open SWE добавить было бы неплохо, а то такое впечатление, что вы сами всё придумали.
Не совсем понятно с чего вы решили что Open SWE какое то отношение имеет к нашей теме. Кроме общих буковок и концепции агенты + документация - особых пересечений нету.
А кто выдумал в статье написано, со ссылкой:
> Memory Bank - это концепция, представленная в виде официальной инструкции для Cline
Поэтому не совсем понятный тезис
Привет! хорошо описано - я к этому процессу пришел тоже. Только вот один вопрос - как клауди агент будет выдерживать из проекта нужные ему для работы файлы? Ведь у него маленькое окно, а чтобы выдернуть файл нужно загрузить целый проект
Решается двумя способами:
1) С помощью ТЗ - мы прям в тз прописываем путь к файлам, где какие компоненты лежат и как их использовать, в статье в примере это есть блок с ### Ключевые компоненты для реализации. Базовые схемы, такие как BatchCommandRequest, уже реализованы в core/src/schemas.py
2) Это создать в memory_bank файл с навигацией по архитектуре проекта. Прям указывать пути к файлам с описанием, что там лежит и зачем это можно использовать. Такую спеку по проекту так же можно сделать через Gemini
Хорошая статья. Было бы очень интересно прочитать, как эта методология может адаптироваться для команды из нескольких человек.
У меня пока проблема в плоскости заставить перейти на один инструмент, сейчас команда на проекте пользуется разными AI решениями. К консенсусу еще не пришли.
Эта методология мне кажется гибка и масштабируема, главное все должны ей придерждиваться и выработать внутренние правила работы с ней. Проблемы в самой методологии пока не вижу.
Спасибо за полезный и интересный контент.
В разделе 2.3 последнее предложение обрывается:
"при необходимости - создает или обновляет гайд в guides/ с примерами использования или ..."
AI Software Engineering: От хаоса Vibe Coding к системной разработке с AI-агентами