Я оцениваю свой проект, писЯ :) его с помощью него же. Эффективность начал он показывать почти сразу, стал сильно меньше забывать контекст, можно было закрыть сессию, поднять ее в другой CLI иной моделью. Но приходилось ручками напоминать агенту правила. Но стало легче, агент сам формулировал задачи, ранжировал по приоритетам, добивал постановку, я лишь обеспечил его удобным механизмом сохранения памяти. Причем код не какой-то там слишком заумный, это список инструментов сохранения, извлечения, семантического поиска, можно сказать бойлерплейт. По сути справится мамкин вайбкодер, только он не справится. Мамкин вайбкодер не сможет сформулировать задачу. Вот самое сложное здесь.
Вот список, почему пишу сам: 1. Я тот еще велосипедист, т.к. считаю, что идеальный под себя инструмент ты можешь сделать только сам, в остальном ты будешь мириться с компромиссами.
2. В продолжение первого пункта скажу, есть мудрость: "Если хочешь изучить инструмент, сделай его сам." Звучит как тавтология, но по другому сказать сложно.
3 .Опыт - это единственная ценность, что у тебя никто не сможет отнять.
4. Большинство популярных инструментов хочет, чтобы я оформил подписку и перечислял им денежку, и их столь много, что после оплаты AI-сервисов, квартплаты, ипотеки понимаешь, что кушать в этом месяце ты будешь макароны.
Теперь по инструменту, у меня свой MCP, развернутый локально в Docker, однако никто не мешает обращаться к нему по сети, что я и делаю. Задача MCP держать модель в рамках протокола решения задачи и предоставить удобны доступ к базе данных. Причем, самым сложным оказалось не общение с БД, а держать агента в жестких рамках, на эту тему тоже есть статья, чуть ранее опубликованная, но ее пока никто не понял. :)
Я пишу свое(точнее Codex пишет), и мне реально помогает, конечно это нейрослоп в какой-то мере, но инструмент не должен быть красивым, он должен быть эффективным. Раньше у меня агенты после мегабайта проектного кода начинали дичь творить, сейчас все норм. диалог примерно такой:
Я: продолжай
Агент:
Работал на протяжении 10s
Постановка задачи 1054b22f
Проблема: семантические запросы ошибочно маршрутизируются в лексический list_artifacts/list_open_tasks. Дефект снова воспроизведён при получении контекста этой задачи.
Цель:
отдельный маршрут семантического поиска;
Qdrant только формирует кандидатов;
каждый кандидат проверяется и загружается из SQLite;
orphaned refs доступны лишь как диагностические, не как существующие задачи.
В объёме: маршрутизация, ранжирование, подавление служебных слов, aliases, все статусы и типы артефактов, диагностические receipts.
Вне объёма: восстановление или удаление данных, миграция рабочей базы, признание индекса источником истины.
Критерии готовности:
запрос про reconstruction bundle находит релевантные материалы;
нет скрытого отката к lexical search;
8f39fa86-... показывается только как orphan diagnostic;
точный lookup остаётся fail-closed;
все write-тесты выполняются только в Docker.
Риск: утечка или ложное признание артефакта существующим. Защита: обязательная SQLite-валидация.
Первое действие: после claim исследовать текущие маршруты поиска и диагностический контур без записи в рабочую БД.
Про затраты токенов, они растут экспоненциально размеру проектов. Разные подходы к хранению памяти меняют эту зависимость. И как в графиках системы уравнений. в зависимости от сложности(объема) проекта различные методы имеют разные эффективности. На малых проектах .md достаточно, после определенного объема эффективность падает, либо ломается совсем. Tогда на сцену выходят более сложные методы, типа RAG, Cognition и т.д.
Не буду спорить, каждый выбирает то, что ему удобно, или то, к чему привык, в крайнем случает, то, к чему принуждают. Сам являюсь сторонником правила: хочешь понять как работает инструмент, сделай его сам.
Я чет прям описание своего проекта прочитал, пописываю потихоньку с февраля, на гитхабе в публичном доступе лежит. (если кому надо ссылку скину, может звездочку поставите :) Думаю, а почему его только боты скачивают, теперь знаю почему:) Если кому интересно, почему БД лучше чем использование AGENTS.md + MEMORY.md могу популярно в нескольких словах объяснить: Маркдаун файлы - это по сути статика, база данных - она живая. Затраты человека или агента на правку этих файлов сильно выше, чем через правильно приготовленный MCP rпростыми командами типа запиши правило X, или подними задачу Y. Более того, постановка задачи автоматизируется, превращаясь в непринужденный диалог с агентом. Кто пишет ручками пишет *.md для агента - срочно поднимайтесь с предыдущей ступени развития вайбкодинга :) Я вот интервью агента попросил записать: https://github.com/Utundry/sloplesscode/blob/master/docs/AGENT_MCP_INTERVIEW.md
Я написал правильный вариант в верхнем регистре. Неодушевленное существительное в винительном падеже(кого, что). Если я не прав, жду аргументированное возражение(и никак не АРГУМЕНТИРОВАННОГО ВОЗРАЖЕНИЯ)
со ссылкой на первоисточник.
Я оцениваю свой проект, писЯ :) его с помощью него же. Эффективность начал он показывать почти сразу, стал сильно меньше забывать контекст, можно было закрыть сессию, поднять ее в другой CLI иной моделью. Но приходилось ручками напоминать агенту правила. Но стало легче, агент сам формулировал задачи, ранжировал по приоритетам, добивал постановку, я лишь обеспечил его удобным механизмом сохранения памяти. Причем код не какой-то там слишком заумный, это список инструментов сохранения, извлечения, семантического поиска, можно сказать бойлерплейт. По сути справится мамкин вайбкодер, только он не справится. Мамкин вайбкодер не сможет сформулировать задачу. Вот самое сложное здесь.
Вот список, почему пишу сам:
1. Я тот еще велосипедист, т.к. считаю, что идеальный под себя инструмент ты можешь сделать только сам, в остальном ты будешь мириться с компромиссами.
2. В продолжение первого пункта скажу, есть мудрость: "Если хочешь изучить инструмент, сделай его сам." Звучит как тавтология, но по другому сказать сложно.
3 .Опыт - это единственная ценность, что у тебя никто не сможет отнять.
4. Большинство популярных инструментов хочет, чтобы я оформил подписку и перечислял им денежку, и их столь много, что после оплаты AI-сервисов, квартплаты, ипотеки понимаешь, что кушать в этом месяце ты будешь макароны.
Теперь по инструменту, у меня свой MCP, развернутый локально в Docker, однако никто не мешает обращаться к нему по сети, что я и делаю. Задача MCP держать модель в рамках протокола решения задачи и предоставить удобны доступ к базе данных. Причем, самым сложным оказалось не общение с БД, а держать агента в жестких рамках, на эту тему тоже есть статья, чуть ранее опубликованная, но ее пока никто не понял. :)
Я пишу свое(точнее Codex пишет), и мне реально помогает, конечно это нейрослоп в какой-то мере, но инструмент не должен быть красивым, он должен быть эффективным. Раньше у меня агенты после мегабайта проектного кода начинали дичь творить, сейчас все норм.
диалог примерно такой:
Я: продолжай
Агент:
Работал на протяжении 10s
Постановка задачи 1054b22f
Проблема: семантические запросы ошибочно маршрутизируются в лексический list_artifacts/list_open_tasks. Дефект снова воспроизведён при получении контекста этой задачи.
Цель:
отдельный маршрут семантического поиска;
Qdrant только формирует кандидатов;
каждый кандидат проверяется и загружается из SQLite;
orphaned refs доступны лишь как диагностические, не как существующие задачи.
В объёме: маршрутизация, ранжирование, подавление служебных слов, aliases, все статусы и типы артефактов, диагностические receipts.
Вне объёма: восстановление или удаление данных, миграция рабочей базы, признание индекса источником истины.
Критерии готовности:
запрос про reconstruction bundle находит релевантные материалы;
нет скрытого отката к lexical search;
8f39fa86-... показывается только как orphan diagnostic;
точный lookup остаётся fail-closed;
все write-тесты выполняются только в Docker.
Риск: утечка или ложное признание артефакта существующим. Защита: обязательная SQLite-валидация.
Первое действие: после claim исследовать текущие маршруты поиска и диагностический контур без записи в рабочую БД.
Подтверждаете старт реализации этой постановки?
Для тех, кому действительно интересно разобраться, я опубликовал статью
https://dzen.ru/a/aikKRKfi_X16HSoD
опубликовал бы и на хабре, но инваайта нет.
Про затраты токенов, они растут экспоненциально размеру проектов. Разные подходы к хранению памяти меняют эту зависимость. И как в графиках системы уравнений. в зависимости от сложности(объема) проекта различные методы имеют разные эффективности. На малых проектах .md достаточно, после определенного объема эффективность падает, либо ломается совсем. Tогда на сцену выходят более сложные методы, типа RAG, Cognition и т.д.
Не буду спорить, каждый выбирает то, что ему удобно, или то, к чему привык, в крайнем случает, то, к чему принуждают. Сам являюсь сторонником правила: хочешь понять как работает инструмент, сделай его сам.
В базе данных можно хранить декомпозированно. и доставать только релевантные части
Отлично, а какой размер проекта в строках?
Я чет прям описание своего проекта прочитал, пописываю потихоньку с февраля, на гитхабе в публичном доступе лежит. (если кому надо ссылку скину, может звездочку поставите :) Думаю, а почему его только боты скачивают, теперь знаю почему:) Если кому интересно, почему БД лучше чем использование AGENTS.md + MEMORY.md могу популярно в нескольких словах объяснить: Маркдаун файлы - это по сути статика, база данных - она живая. Затраты человека или агента на правку этих файлов сильно выше, чем через правильно приготовленный MCP rпростыми командами типа запиши правило X, или подними задачу Y. Более того, постановка задачи автоматизируется, превращаясь в непринужденный диалог с агентом. Кто пишет ручками пишет *.md для агента - срочно поднимайтесь с предыдущей ступени развития вайбкодинга :)
Я вот интервью агента попросил записать:
https://github.com/Utundry/sloplesscode/blob/master/docs/AGENT_MCP_INTERVIEW.md
Спасибо, vak0, за крайне лаконичный и ёмкий ответ. Истина рождается в споре.
Я написал правильный вариант в верхнем регистре. Неодушевленное существительное в винительном падеже(кого, что). Если я не прав, жду аргументированное возражение(и никак не АРГУМЕНТИРОВАННОГО ВОЗРАЖЕНИЯ)
со ссылкой на первоисточник.
А может быть стоит начать с русского языка? И не совершать ГЛУПЫЕ ОШИБКИ в названии статьи?