Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 14
Уважаемая публика, внимание! Только сегодня, удивительный аттракцион: на ваших глазах зумеры изобретают проектную документацию! Простите, если что. На самом деле мысль мне кажется полезная, но почему бы просто не хранить и не обновлять требования в каком-то плюс-минус классическом виде?
Цель - не создать спецификацию в гите, а скорее подвязать человекоподобные описания к конкретным изменениям в коде, на которые будет ссылаться агент при попытке понять историю.
Я думаю ваш когнишн лээр оф лонг терм проджект мемори если его немного потереть, оказывается старыми добрыми хорошими практиками кодирования и спеками. Есть какой-нибудь https://google.github.io/styleguide/ . В подобных местах написано, что надо комментировать, а что не надо. Например хитрая логика, неочевидные решения и т.д. должна быть описана в коментах. Скорее всего ваш агент и так их пишет (у вас же не дурно воспитанный агент?). Баги и новые фичи обычно на больших проектах описаны в тасках, хорошая практика ссылаться на них при коммите, если у вас нет тасков - в указать полностью в комменте к коммиту. Общие знания проекта живут в требованиях, описании архитектуры (кстати никаких проблем их хранить в гите). Т.е. на вид вы изобретаете хороший такой пяти колёсный велосипед. Хотя концепция, что все это видно сразу одновременно в виде такого готового микроконтекста для агента прямо из куска кода мне нравится.
Про велосипед согласна.
Еще, до меня не вовремя дошло попросить у того же курсора рассказать мне "Как изменялась логика выполнения этой задачи?" (То есть как мы к этому пришли?), однако с четкой инструкцией обращаться напрямую в гит к моим коммитам, на что он прошелся по шагам ниже, и выдал мне правдивую историю.
1) Поиск коммитов по ключевым словам
2) Поиск коммитов, изменявших конкретный файл
3) Статистика изменений в коммите
4) Просмотр конкретных изменений
5) Поиск упоминаний в коде через grep
6) Сравнение коммитов
То есть необходимо было вручную попросить обращаться в гит, а не к текущему контексту.
"Хотя концепция, что все это видно сразу одновременно в виде такого готового микроконтекста для агента прямо из куска кода мне нравится." – по сути, это прописывание инструкций для агента куда и за чем обращаться, вместо слепого поиска по кодовой базе.
Вот и вопрос – насколько это было бы полезно – заточить агента правильно искать информацию, обращаясь туда куда нужно, без необходимости ходить кругами.
/
Данные должны быть нормализованы т.е. не должны дублироваться. Если у вас уже все это есть в требованиях, тасках и комментах, и вы параллельно ведете требования для агентов - это плохая затея, т.к. они очень быстро разойдутся, у вас будет два варианта требований и какой правильный уже никто никогда не узнает. Возможно ваша идея - это сделать агента, который после каждого коммита пересобирает "витрину данных знаний о проекте для разработчика". Тем самым ускоряет работу агентов не заставляя их каждый раз залезать в десять мест. Например это может быть md файл или несоклько, куда агент собирает изо всех перечисленных источников (ТЗ, таски, коммиты, комменты и т.д.) данные и мэпит их на код скажем с точностью до метода. Фантазирую, но как вариант: в md файле вы храните списокм название файа с исходниками, название класса, метода - под ним собранная информация. Если мы планируем что с кодом будет работать агент, его не будут раздражать полотна комментов, можно наверное и просто в комменты это все запихнуть.
Хранить спецификации просто, диалоги как будто только перегружают контекст и тратят токены.
Ну я перестал уже активно пользоваться, но обычно правил спецификацию и просил сделать или просил сделать, а потом просил поправить спецификацию.
Хороший формат спецификации не нашел, к сожалению.
В третьем пункте у вас Злюша. Оставьте, так даже лучше чем Илюша.
То что вы описали очень сильно похоже на подход который предлагает OpenSpec (Spec-Driven Development). В нем явно ничего не говорится про Git, но подразумевается (или не исключается) возможность хранения файлов спецификаций в репозитории рядом с кодом.
Спасибо за статью. И материал хороший и идея здравая.
И да, это конечно велосипед... мы же называем так новое решение проблемы для которой уже есть старое.
Но хорошо ли это старое решение - вот вопрос. Требования в confluence, задача в jira (условно), комменты в коде... Не претендую на истину, но лично меня этот веб-сёрфинг не радует совершенно.
Идея все держать в одном месте и совместно версионировать - напротив, очень привлекательна. В "традиционной" разработке она правда часто разбивается обо что-то типа "ой, не хочу я в этот ваш гит".
Но современная разработка с агентами (не путать с вайб-кодингом) открывает совершенно новые возможности, и нам конечно надо искать новые решения старых проблем.
Так что не слушайте никого, дорогой зумер. Исследуйте, изобретайте - что-то взлетит, что-то нет, жизнь покажет.
Привет вам от миллениала!
P. S.
https://github.com/vanzan01/cursor-memory-bank - смотрели? Тут есть похожие идеи
https://github.com/orneryd/Mimir
M.I.M.I.R - Multi-agent Intelligent Memory & Insight Repository
AI-Powered Memory Bank + Task Management Orchestration with Knowledge Graphs
Апдейтить доки в том же коммите — классная идея. Вместо ссылок на строки кода в разных файлах получаем ссылку на историю диффов кода, связанных с фрагментом документа.
Чтобы не пугать публику «велосипедом», можно подать это как вариант ADR -
https://github.com/joelparkerhenderson/architecture-decision-record
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Project Cognition Layer: Почему AI-агенту нужна не только векторная БД, а Git. Архитектура долговременной памяти проекта