⚪️ СС теперь с нескучными обоями выражениями


Ну - все! Теперь заживм! В следующей версии можно будет кастомизировать чего вам СС во время работы будет писать как текст к спиннеру.

А если кроме шуток - мелкое QoL улучшение, но, в принципе, прикольное. Наверное, такие штуки украшают продукт

@deksden_notes

⚪️ Beautiful Mermaid


Крутой проект - стильный рендер Mermaid диаграмм, дуо-рендер в SVG/ASCII, то есть для TUI тоже! Сложные диаграммы, темы. Оч круто


🔗 https://github.com/lukilabs/beautiful-mermaid
🔗 https://agents.craft.do/mermaid

Просто посмотрите демо сайт! 🔥


Более ранняя работа - кому надо только ASCII рендер:

🔗 https://github.com/AlexanderGrooff/mermaid-ascii

Самое оно для документации. Еще и агенты понимают вполне вменяемо

@deksden_notes

⚪️ Progressive Disclosure : пробеги по граблям Skills и меморибанки


(Видимо,) В связи с активностью Vercel в отношении скиллов (запуск большой библиотеки Shills.sh) они тут исследование затеяли.

🔗 https://vercel.com/blog/agents-md-outperforms-skills-in-our-agent-evals

Суть их эксперимента в том, что они смотрели как агенты будут пользоваться скиллом, если туда пакануть документацию. Статья хорошая, прочитать стоит.

Что они обнаружили: что агенты не вызывают скиллы. "срезают углы" и идут простейшим путем. Можем не вызвать? не вызываем. Не новость (да, Опус?)!

Клозеды вот даже подучили как эвалы на свой скилл делать, чтобы смотреть когда он вызываетсяя, а когда - нет:

🔗 https://developers.openai.com/blog/eval-skills

В общем, проблема известная.

👉 Вкратце:
• просто поставить скилл почти совсем не помогает
• явный промптинг "используй скилл" уже заметно помогает
• лучше всего помогает если индекс явно грузить через AGENTS.md (индексный файл, ага) - но тогда теряется progressive disclosure
• думать надо именно в контексте progressive, то есть если сначала грузить документацию, а только потом смотреть на проект, то реультаты хуже чем если сначала смотреть на проект, а потом - в документацию. Это логично: агент будет знать чего смотреть конкретно и зачем.

При чем тут меморибанк? Дело в том, что я давно строю проекты с использованием именно меморибанков на progressive disclosure принципах (еще с тех времен когда они так не назывались - в закрепе канала индекс есть). И я давно свои флоу строю на явных директивных указаниях исследовать проект/меморибанк.

▶️ Vercel тут переоткрыл то, что давно было видно из практики работы с меморибанком: работают детерминированные этапы флоу - сначала готовим контекст явными промптами, потом работаем с ним. Для подготовки контекста принцип progressive disclosure работает хорошо - но только если его готовить.

Оставить все на откуп текущему поколению агентов нельзя, это не работает или работает неважно.

В следующем поколении, возможно (и скорее всего!) будет заметно лучше, раз скиллы настолько пошли в народ. Но пока - директивно праймим контекст.

(ц) А статейку то сами - прочтите, да!)

@deksden_notes

⚪️ Gemini CLI: hooks 🆕


В Гемини КЛИ завезли хуки!

Полезная штука, так то. СС ими силен. Еще бы разные агенты хоть какую то унификацию этих кастомизаций бы придумали, типа стандарта.. Как агентные скиллы / слэш команды, и AGENTS.md до этого!..

Но я, наверное, многого хочу

🔗 Блог тут: https://developers.googleblog.com/tailor-gemini-cli-to-your-workflow-with-hooks/


#deksden_notes

⚪️ Прайминг контекста


Я довольно давно использую прайминг, термин отчасти устоявшийся, но не особо широко используемый.

Под праймингом контекста я понимаю процесс подготовки контекста для работы агента.

👉 Сейчас схема отработана довольно длительной практикой, и я делаю ее в пару этапов. После старта новой пустой сессии:

1️⃣ первый промпт: агент инструктируется полностью прочитать главный ИНДЕКС меморибанка;

2️⃣ второй промпт: агент инструктируется ПОДГОТОВИТСЯ к общению по узкой теме (например: "мы обсуждаем дашборд и его работу с сервером; подготовься, ты должен все знать про дашборд и работу сервера с внешними компонентами; глубоко исследуй меморибанк и кодовую базу").

Почему это работает?

Во-первых, у меня есть меморибанк. Это структурированное хранилище информации о проекте, построенное по принципу progressive disclosure, структурировано для облегчения сбора контекста.

Главный индекс меморибанка содержит полную "карту знаний" о проекте - раскрывает структуру меморибанка на глубину 1-2 уровней. Про индексные файлы: https://t.me/deksden_notes/46

Индекс построен не просто из ссылок, а из АННОТИРОВАННЫХ ссылок. То есть к ссылке "прилагается" два компонента - что находится по ссылке, и ЗАЧЕМ/ДЛЯ ЧЕГО может быть полезно прочитать эту ссылку. Вот про аннотированные ссылки: https://t.me/deksden_notes/47

Аннотированные ссылки в некоторой стпени снижают эффект, который мы чуть раньше обсуждали по мотивам статьи Vercel: https://t.me/deksden_notes/407

То есть после первого промпта в контексте агента находится карта знаний с встроенным "маршрутизатором" - когда и в какой раздел "бежать" за нужной информацией. Но наличие ссылок не означает что он по ним будет ходить, как выяснил Vercel.

Поэтому вторым промптом мы обозначаем тему нашей дискуссии - и инструктируем агента СДЕЛАТЬ исследование по меморибанку/кодовой базе. И в этот момент агент уже набирает значительное количество контекста по теме.

У меня в кодексе выходит 15-25% занятого контекста к старту обсуждения какой то узкой темы: это цена подготовки. И времени это занимает от 3 до 10 минут (5.2 на high ризонинге).

▶️ Еще раз:
• идея в том, чтобы сначала дать потенциал для агента (скормить ему карту знаний)
• а потом заставить этот потенциал реализовать по конкретному вопросу

В итоге имею "прогретый" контекст, агент не путается, не создает дополнительных сущностей, в курсе архитектуры, деталей проекта, принципов и подходов.

‼️ Важно: еще это работает потому что в меморибанке такая информация есть - и агент ее достает.

@deksden_notes

⚪️ Прайминг, если нет меморибанка


Очевидно, он тоже возможен, только нужно задать больше инструкций, и займет он больше времени. Это сложно делать технично и занимает заметно больше времени.

Вам необходимо чтобы в этой сессии агент исследовал ваш проект и разобрался с ним. Вы можете его направить: расскажите ему что ему исследовать.

Я бы предложил первым этапом исследовать проект по С4 структуре, кратко посмотреть L1 (что за проект) и выделять L2 уровни (типа подсистем). Это чтобы агент сориентировался.
ОСТПосле первичного знакомства стоит чтобы агент глубже исследовал нужную вам L2 подсистему (форнтэнд, БД, сервер, ...).

Каждый раз просите агента рассказать в общих словах итоги его исследования - чтобы вы оценили правильно ли и полностью ли агент разобрался в вопросе. Любая неправильная деталь тут приведет при работе к ошибкам (новый кусок форнтэнда не стыкуется с бэком, или обладает своей системой атворизации).

❓ Можно ли заменить прайминг на систему индекстации / контекстный движок? Нет. Это разное: контекстный движок УСКОРЯЕТ исследование - но только если его делать. Агент должен получить сведения об устройстве вашей системы в целом, чтобы ничего сильно не напутать - а для этого он должен ПОЛУЧАТЬ эти сведения. ИМЕТЬ ВОЗМОЖНОСТЬ получить сведения - как подтвержадет Vercel, НЕ ДОСТАТОЧНО.

То есть системы типа курсора/qoder/augie/codealive помогают, но вам нужно их задействовать.

▶️ Меморибанк заменяет трудоемкую сборку контекста на довольно простой двухэтапный прайминг. Всячески рекомендую организовать ту или иную форму меморибанка.

@deksden_notes

⚪️ Планирование с агентом: работа с контекстом после прайминга


У меня практика такая: я использую контекст после прайминга для разных вещей.

Во-первых, есть некоторый пул "контекстов", у которых завершена первая фаза прайминга - агент прочитал индекс меморибанка и изучил общие сведения о системе. Такие контексты висят у меня неким пулом, я беру очередной для той или иной работы.

Во-вторых, в оркестраторе такие контексты используются для выполнения различных задач: текущий шаг, фикс, и тп. Так я обеспечиваю некоторый рост качества работы.

Как работаю, если мне нужно сделать доработку в проект?

• контекст прогрет под конкретную тему, агент погрузился в нее и готов обсуждать.
• я в свободной форме излагаю свои идеи доработки и прошу проработать вопрос, сообщить мне как это можно сделать - на старте всегда предлагаю подумать несколько вариантов, и обязательно изложить логику для оценки вариантов, какие рекомендации дает агент;
• я прямо говорю агенту: исследуй и изучи, как это лучше сделать в проекте; исследуй код, подготовься;
• после того, как тема прорисовывается, я прошу задать мне вопросы: спросить все что непонятно, устранить gaps для формирования техзадания на эти доработки;
• первая фаза планирования - это всегда обсуждение плана работы с содержательной стороны: что именно мы будем делать; здесь важно зафиксировать "ширину" ваших изменений и их содержание - чего будем делать, и почему будем делать именно так;
• первую фазу логично фиксровать в виде ADR - тогда вы сохраните ЛОГИКУ выбора тех или иных решений из вашего обсуждения;
• не лишним будет сохранить id сессии чтобы если что - вернуться
• после фиксации плана работы, можно начать прорабатывать implementation plan - тут агент должен предметно исследовать КАК в системе правильно приземлить твои изменения
• прорабатывайте side effects, использование существующих механизмов, убирайте оверинжиниринг и усложенния, ищите самый простой способ из возможных с сохранением функциональности
• еще раз просите агента все исследовать и думать как будет оптимально; просите предлагать идеи, давать оценки - это проработка;
• агент не должен выполнять ваши хотелки, агент должен найти качественное решение для поставленной задачи, поэтому местами он должен даже спорить ради эффективного решения - промптите его на это!
• проработанный implementation plan фиксируйте как Tech Specs
• я все документы храню в соответстввущих папках меморибанка, для истории (memory-bank/adrs/, memory-bank/tech-specs/, в последовательно пронумерованных файлах типа ADR-017-some-fieatures.md); использвоание номера сильно ускоряет отсылки к документам ("иди и прочитай ADR 021", и агент это понимает).


▶️ Общий принцип: расспрашивайте агента. Побуждайте его исследовать код, готовится к ответу на ваши вопросы, прорабатывать темы. Агент не должен выдумывать, агент должен бегать по проекту и изучать. Карта знаний по проекту му затем и дана - чтобы он знал куда бежать. И вот как раз настал момент, когда это надо сделать! побуждайте агента чтобы он это делал.

▶️ Проработка из двух фаз:
• выяснили ЧТО БУДЕМ ДЕЛАТЬ- фиксируем в ADR
• проработали КАК ИМЕННО ЭТО НАДО ДЕЛАТЬ - фиксируем в Tech Spec.


Когда рожден Tech Spec / Implementation plan - планирование в целом закончено, дальше - реализация. С оркестратором я просто даю id сессии и стартую флоу, где эта сессия превращается в план работ и реализуюется.

@deksden_notes

⚪️ Vercel и Agents.md


По следам блога Vercel про усвоение скиллов, уже сделали вот такую штуку, которая превращает скиллы в индекс для добавления в AGENTS.md файл, улучшая воспирятие агентом:

🔗 https://github.com/leviathofnoesia/AgentCompiler


Ну и такая штука встретилась: компилирует любую документацию в скилл:

🔗 https://github.com/hyperbrowserai/hyperbrowser-app-examples/tree/ex/hyperskill/skills-generator

Может, кому то будет полезно

@

⚪️ Vercel - Sandboxes

у Vercel тоже релизы на выходные, как и у Кодекса? (вышел 0.93 с доработкой план-мода и прочим, кстати).

Релизнули в GA сервис Sandboxes: безопасную VM для агентов:

🔗 https://x.com/rauchg/status/2017423825152184772?s=20

🔗 https://github.com/vercel/sandbox

https://vercel.com/docs/vercel-sandbox

https://vercel.com/docs/vercel-sandbox/pricing - лимиты тоже тут

На этом бегает Blackbox / rooCode / v0.

@deksden_notes

⚪️ KIMI 2.5 free в OpenCode


Кто хотел пощупать кими как агента - в openCode оно пока бесплатное! Успеваем тестить

@deksden_notes

⚪️ JustBash


Чего то Vercel разошелся! Новый релиз - JustBash: это такой сендбокс для багаш на TS, с кучей знакомых команд и настройками файловой системы. Например, читаем файлы с диска, пишем файлы в память. Получается полная изоляция

Любопытно

🔗 https://justbash.dev/

🔗 https://github.com/vercel-labs/bash-tool

@deksden_notes

⚪️ Pi Extention : AMP-like


Наткнулся тут на расширение для Pi Coding Agent. Мне не очень актуально, но зацепил сам контент.

Расширение привносит в pi wesearch через Jina API, что, наверное для пользователей pi полезно, но банально.

👉 Интересное: добавляется менеджмент сессий в стиле AMP, который меня заинтересовал. Я сам AMP глубоко не ковырял, но показалось оч интересным.

Сделано такое. Команда /handoff <goal>, которая не просто компактит сессию, а делает НОВУЮ сессию, в которой:
• с суммаризацией контента из старой сессии по указанному вопросу (goal).
• список файлов, релевантный goal
• собственно, описание goal
• ссылка на "родительскую" сессию

Это неплохо: немного похоже на /compact, но не в текущую сессию, а бранч в новую сессию с компактом.

👉 Самое оригинальное: не видел такого больше нигде - запросы в "родительскую" сессию. session_query позволяет агенту при необходимости "запросить" в родительской сессии какую то информацию! Например, компакт ее не передал, или слишком сжал. Есть возможность "дозапросить"

🔥 По мне - это полноценный обмен информацией между текущей задачей и прошлой. Оч полезно, кмк.

Сабж для сведения - суть поста была в концепции

🔗 https://github.com/pasky/pi-amplike

@deksden_notes

⚪️ Codex Desktop (macOS) - перые впечатления


Тут накануне клозеды выпустили Codex Dekstop для мака. Версия для Windows / Linux обещана тоже, и учитывая что это Electron приложение - не должно быть сильно долго.

Что умеет?

▶️ Automations: новая штука, позволяет запускать некие промпты по расписанию! Не знаю, насколько удобно, и не придумал пока как это можно задействовать - но, наверное, можно. Например, анализ проекта по четвергам делать.

▶️ Библиотечка Skills прямо в проекте: удобно посмотреть что поставлено. Можно ткнуть в скилл, и он покажет его прям в приложении (правда в модалке спорного размера). Линки внутри скилла глючат: пути относительно корня скилла не разрешаются, поэтому посмотреть по ссылкам чего там прогрессивно дискложает этот скилл не выйдет

▶️ Может сделать древоветку (worktree) и потом организовать PR в итоге. Из приятных мелочей: пустое commit сообщение может быть заменено автогенерированным.

▶️ Еще приятные мелочи: сессии можно переименовывать. Правда, в cli имени сессии не видно, что жалко. Буду писать, что это важная мелочь.

👉 В целом, наверное неплохая штука! Надо поюзать поактивнее, может найду некие преимущеста в сравнении с CLI. Пока плюсом считаю то, что глобальных недостатков тоже не выявлено.

🟢 Из больших плюсов: в честь выхода релиза клозеды устанавливают х2 лимиты на кодекс на всех планах (на 2 месяца!!!)! Плюс какой то доступ к кодексу free/go тарифов на месяц. Это BIG. 🔥

Ну и codex CLI 0.94 вышел, тожа пара фишек:
• поддержка .agents/skills в папках проектов (когда наконец то все поддержат этот "народный" стандарт? amp, kimi code уже в теме, гугл в антигравити не попал немного с .agent/skills). https://developers.openai.com/codex/skills#where-to-save-skills - тут пока не пишут! Некому документацию обновить то, наверное компьюта на агентов не хватает, это же бедный стартап с капитализацией которая даже до триллиона не выросла;
• персоналии для стиля общения включили как stable
• план-мод включили по-умолчанию

——

▶️ Upd 1️⃣ : работа с контекстом выстроена как то иначе, чем в CLI и он забивается оч быстро. Довольно непривычно после CLI. Странно. Местами тупит - использование cpu мощное.


@deksden_notes

⚪️ История про git flow для оркестратора, часть 1

Когда я задумал сделать себе операционный оркестратор (который потом назвался dd-flow) идея была такая: я "закидываю" работу в оркестратор, и он "впиливает" эту работу дальше автоматически, важно, чтобы "закидывание" было процессом асинхронным. Типа, можете добавлять несколько параллельных задач, которые будут реализованы, и автоматически смержены в проект.

Чтобы это все работало, предполагался простой флоу: от главной ветки делаем фичабранчи (оптимизируя это через worktree, чтобы чекауты бранчей были покомпактнее).

Вроде бы все просто. Но есть нюансы. Нюанс называется "релиз". Если у вас ci/cd, то любой мерж в origin сразу триггерит релиз. На каждую вмерженную фичу это неудобно.

Усложним. Делаем две главные ветки:
* main. Пуш в main триггерит релиз.
* develop. Главная ветка разработки, в нее собираем все фичи. Как набрали достойное количество - переливаем все в main, вот вам и релиз.
* hotfix пока решил не делать, вроде не было нужды.
* Решил что впоследствии мой main будет релизить beta.project.com, а в прод будем промоутить после тестирования beta если все ок. почти ничего не будем менять.

Теперь мы все вливаем в итоге в origin/develop. Выяснилось, что оркестратору реально нужно иметь свой локальный чекаут origin/develop, которым только он управляет. Это важно для работы очереди мержей.

Очередь мержей: разберем, что это такое. Когда параллельно пилятся куча разных задач/фич, то "вливать" итоги в develop нужно все равно по одному в некоей четкой последовательности. Это важно для обеспечение консистентности и стабильности develop: ветка должна быть всегда "зеленой", то есть на ней всегда должны проходить все тесты и она должна собираться в продукт. При вливании нужно решать конфликты, что требует синхронности - решать проблемы шаг за шагом. Вот эту последоватльность и обеспечивает очередь мержей, это такой механизм в оркестраторе.

Очередь мержей важно чтобы не косячилась и не зависала - важно чтобы механизм работал. Она должна всегда легко синхрониироваться с origin/develop. Пришлось сделать много гардов, чтобы они ее периодически обслуживали - сервисный чекаут был бы на origin/develop, чтобы на нем чеки проходили зелеными. В оркестраторе сервисные операции оказалось довольно удобно делать: организуем детерминированные команды, а если что то идет не так - у нас есть агентный флоу для фикса! И state, возможность переживать остановки, и ui чтобы если что - пользователя вовлечь к решению проблемы. Удобно.

⚪️ Агентный Git flow, часть 2: когда дистрибутив пакетами через npm

Когда релиз через npm, то важно тестировать работоспособность пакетов. Для этого внутрь пакетов должно попасть что положено. Желательно при этом протестировать чего туда попало. Работаем в монорепозитории через pnpm.

При этом не хочется тестировать только через npm. Иногда хочется посмотреть живьем фичи, которые живут в develop ветке, но чтобы было похоже на работу через пакеты. Это можно сделать если линкануть нужные монореповские пакеты через link глобально на машину.

В итоге пришел к такому: для запуска системы локально есть два режима:
* запустить из develop ветки
* запустить из релиза с npm

Все это обеспечил cli / скриптами. Как работает: есть команда cli dev sync, которая делает: служебный чекаут origin/develop, собирает систему там, и делает pnpm link global соответсвующих пакетов. В результате на локальном компе появляется софт, который через npm распространяется, в свежей сборке.

Если надо посмотреть версию которая в npm лежит, то делаем cli dev sync --prod. Она убирает глобальные линки пакетов pnpm (если были), и ставит версии пакетов из npm. Если потом захотим посмотреть develop версию, то команда cli dev sync уберет npm версии (деинсталлирует), обновит свой чекаут, и поставит pnpm link версии пакетов.

Обратили внимание? Да, я сделал для работы с dev ops задачками в проекте не просто скрипт, а cli для проекта! Зачем? Помимо того, что это удобно, это еще позволило сделать скилл и при необходимости управлять всем этим через агента. Cli очень органично пакуются в скиллы для агентной работы.

⚪️ Агентный git flow, часть 3: а где же human?

После реализации всего вышеописанного, оказалось, что разработка проекта закуклилась внутри оркестратора. Я просто даю задачи, и получаю результат. Вроде бы не плохо! Но мне это показалось слишком радикальным, ведь хочется иногда в режиме "ручного" управления что то доработать! Ну - агентом, конечно, но под управлением. Хотя бы иметь такую возможность.

Это прекрасно что агенты в своих рабочих деревьях чего то пилят сбоку.

Но хотелось прям вот тут, в оригинальном чекауте проекта, иметь возможность тоже чего то впилить. В общем, нужна локальная dev ветка. Вот ее я правильно прикручивал дольше всего.

Выяснилось, что мои корявые правки вечно все ломают. То они конфликтуют с . То куча проблем возникает с мержем моих правок в origin/develop, потому что оркестратор туда уже успел напихать много чего. И что обидно - свои конфликты он автоматом как правило решает, а мне мою работу мержить нужно каждый божий раз руками. Непорядок.

Первая мысль возникла - отправлять мои правки в ту же мерж очередь, и пускай оно туда впиливается! типа - заслал, оно вмержилось. Но есть ограничение - нельзя трогать dev пока правки не влились. И тут выяснилось, что ждать очереди - это дискомфортно, бывает долго и скучно.

Следующая идея: закидывать в очередь последний коммит. Типа, сделал в dev коммит с правками, вот его пускай именно его "завозят" в origin/develop. Правда, быстро выяснилось, что одного коммита - мало, и надо бы цепочку коммитов кидать. Схема вышла норм: цепочки заезжают норм.

Ну и дополнительные хлопоты возникли с тем, что "моя" ветка dev предполагалась "долгоживущей". Фичабранчи создаются под задачу. А вот dev ветку я не планировал регулярно менять - следовательно, появилась необходимость регулярных подтягиваний базы dev ветки на текущее состояние origin/develop.

Для реализации пришлось сделать отдельный небольшой тулинг.

* Мои изменения отправляет dd-flow dev add-merge: берет из ветки dev все невмерженные в origin/develop коммиты, и засылает их "трамвайчиком" в общую очередь мержей.
* Другой тул dd-flow dev sync --dev: делает "обратный мерж" - вливает изменения из origin/develop в dev, попутно решая конфликты. То есть такая "очередь мержей" для одной ветки, и в обратном направлении. Команда похожа на dev sync, но только названием - внутри там совсем другая логика, и она реализована через вызов оркестратора и специального флоу под хту задачу dev-sync.

Так организовалась работа с human in the loop.

⚪️ Git flow, часть финальная. А чо так замороченно?

Я всегда говорил, что у каждого свои флоу. Но свой я задумал завернуть в оркестратор. Когда это работает "в ручном" режиме, кажется все намного проще.

Попытки автоматизации всего процесса делают его немного более сложным: каждая часть флоу при автоматизации требует обустраивания. Детерминированные части работают не всегда автономно, и без агентных добавок могут требовать ручного вмешательства. Поэтому везде по возможности прикручивал агентов.

В итоге получилось не особо сложно:
* агенты крутятся в своих флоу, пилят фичи в рабочих деревьях, и мержат их очередью
* результаты можно пощупать через пары релизных пайплайнов - чтобы и npm релизы посмотреть, и текущую работу в develop
* а сам могу руками поработать в dev ветке, которую "тащат" два процесса: Add-merge добавляет мою работу в общую очередь мержей, и dev-sync "подтягивает" мою ветку на текущий origin/develop

Вот такая гравицапа вышла

❓ А вы как работаете с агентами? с git?

⚪️ Соннет 5

… и опус 4.6 по слухам вот вот. Еще вчера!

Ждемс?

Чего думаете поправят?

Мои боли от Клодов: контекст, внимание, вранье.