⚪️ 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 по слухам вот вот. Еще вчера!

Ждемс?

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

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

⚪️ Kilo CLI 1.0


Я чего то перестал все известные мне CLI агенты постить (а их пара десятков то наберется, наверное) - но этот стоящий упоминания.

Во первых KILO - довольно известное и популярное расширение для VS code. Поэтому - своей популярностью уже заслужил.

Во вторых, на этот раз это форк ОПЕНКОДА!

Ну - посмотрим посмотрим на развитие

🔗 блог : https://blog.kilo.ai/p/kilo-cli
🔗 страничка на оффсайте: https://kilo.ai/cli
🔗 гит : https://github.com/Kilo-Org/kilocode

@deksden_notes

⚪️ .agents/skills петиция


К Антропикам. Сабж:

https://x.com/iannuttall/status/2018760297368932726?s=20

Хотят чтобы де-факто народившийся стандарт поддержали все топовые вендоры. Это разумно! почему не agent/skills? По AGENTS.md аналогии.

В общем - хорошее дело!

Кому не жалко - лайкните! Я лайкнул

@deksden_notes

⚪️ Материалы канала

Не все обращают внимание - в закрепе есть оглавление канала. Там я некоторые ссылки на полезные посты размещаю, для облегчения навигации! Но не все вошло

Подсобирал материал по каналу, может пригодится кому каталог ссылок:

▶️ Контекст-инжиниринг для меморибанков:

* индексные файлы index.md : https://t.me/deksden_notes/46
* главный индекс меморибанка и прайминг контекста: https://t.me/deksden_notes/51
* аннотированные ссылки : https://t.me/deksden_notes/47
* атомарные файлы : https://t.me/deksden_notes/49 , https://t.me/deksden_notes/52
* С4 модель : https://t.me/deksden_notes/52
* XML-like теги : https://t.me/deksden_notes/73
* оверинжиниринг : https://t.me/deksden_notes/368
* Progressive Disclosure : пробеги по граблям Skills и меморибанки : https://t.me/deksden_notes/407

▶️ кейсы и разбор проблем с агентами:

* Vibe Coding мифы и "охотничьи рассказы" : https://t.me/deksden_notes/59
* Разбор vibe-кейса 1️⃣ : https://t.me/deksden_notes/60
* Модель не справляется : https://t.me/deksden_notes/262

▶️ Тактические приемы работы с агентами:

* планирование в СС : https://t.me/deksden_notes/64 и https://t.me/deksden_notes/65
* vibecoding в CC : https://t.me/deksden_notes/89 и https://t.me/deksden_notes/90
* вайбкодинг в Кодексе : https://t.me/deksden_notes/124
* Codex workflow для рефакторинга : https://t.me/deksden_notes/144
* Local multiagent flow : https://t.me/deksden_notes/146
* Прайминг - Специализированные сессии : https://t.me/deksden_notes/329
* Флоу Peter Steinberger : https://t.me/deksden_notes/331
* Прайминг, если нет меморибанка : https://t.me/deksden_notes/412
* Планирование с агентом: работа с контекстом после прайминга : https://t.me/deksden_notes/413


▶️ Git flow: https://t.me/deksden_notes/420 , https://t.me/deksden_notes/421 , https://t.me/deksden_notes/422 , https://t.me/deksden_notes/423


▶️ Memory bank для существующих проектов :: Реверс-проектирование и реверс-документирование в brownfield : https://t.me/deksden_notes/66 , https://t.me/deksden_notes/67

▶️ Агентная память (обзор технологии, agents.md ): https://t.me/deksden_notes/77 , https://t.me/deksden_notes/81 , https://t.me/deksden_notes/83 , https://t.me/deksden_notes/84


▶️ Тестирование:
* Тестирование в эпоху AI агентов : https://t.me/deksden_notes/249 , https://t.me/deksden_notes/250 , https://t.me/deksden_notes/251
* Тестирование, бизнес-процессы (e2e) : https://t.me/deksden_notes/286

▶️ ‼️ Серия постов про #deksdenFlow :
* TLDR : https://t.me/deksden_notes/197 ,
* #DeksdenFlow - 1 :: git, worktree : https://t.me/deksden_notes/198 , https://t.me/deksden_notes/199
* #DeksdenFlow - 2 :: Контексты : https://t.me/deksden_notes/200
* #DeksdenFlow - 3 :: Protocol - Этап обсуждения : https://t.me/deksden_notes/201 , https://t.me/deksden_notes/202
* #DeksdenFlow - 4, Protocol, Этап фиксации плана : https://t.me/deksden_notes/203 , https://t.me/deksden_notes/204
* #DeksdenFlow - 5, Protocol, этап Реализация : https://t.me/deksden_notes/205 , https://t.me/deksden_notes/206
#DeksdenFlow - 6, Protocol, Этап Review and Merge : https://t.me/deksden_notes/207
* #DeksdenFlow - 7, Заключительное организационное : https://t.me/deksden_notes/208
* #DeksdenFlow и Gpt-5.1 : https://t.me/deksden_notes/210
* Регулярный анализ проектов : https://t.me/deksden_notes/316
* Модернизация протокола #deksdenFlow: https://t.me/deksden_notes/309
* слайды : https://t.me/deksden_notes/252


▶️ Разное:

* О верификации - коротко : https://t.me/deksden_notes/367
* Схема "Критик" : https://t.me/deksden_notes/142
* Фичапаки CLI агента : https://t.me/deksden_notes/308

⚪️ Рыбный день

... как известно - четверг! А этот выдался особенно рыбным. Тятя, тятя! Наши сети притащили:

* Claude Opus 4.6
* gpt-5.3-codex

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

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

из интересного - 1m контекста у опуса идет за premium прайс, о чем скромно умалчивают в новости. зато $10/$37.50 ясно указаны в карточке цен. Впрочем, на соннет 4.5 премиум цены на большой контекст тоже обозначены - хотя доступ к 1m модели был только у узкого круга ограниченных лиц.

Думаю, сейчас мы таки посмотрим как себя чувствуют модели клода на больших контекстах! по бенчмаркам - фантастические результаты. Надо сомтреть живьем

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

——

Кодекс поколения 5.3

СОТА на куче кодинговых бенчмарков. Впечатляет рост агентного компьютерюза - х2 практически по бенчмарку OSWorld. То есть в агенте тыкать мышкой будет бодро

Еще сказали что будет развлекать пользователя комментариями в процессе работы. Аутичный стиль стремятся изжить

И еще он на 25% быстрее! Это хорошо

Кодекс 5.3 тоже выглядит бодро и интересно! Пойду включу его ))


——

🔥 GO тестить!


@deksden_notes

⚪️ Swarms - новая парадигма?


В СС вышла в качестве research preview новая фича, которая называется Agent Teams (агентные команды).

🔗 почитать тут: https://code.claude.com/docs/en/agent-teams

Идея такая: агент-координатор (team lead) создает команду из агентов, координирует работу, раздает задачи другим участникам команды и пишет отчет о результатах работы.

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

Разница в уровне децентрализации и оформленности выделенных членов команд. В агентной команде агенты - это полноценные агенты, в разных процессах, каждый со своей сессией. Общаться они могут друг с другом напрямую, минуя координатора (agent mail). Вы можете подключаться к каждому агенту в команде и даже давать ему инструкции через чат с ним! Агенты само-координируются в процессе работы

Недостатки? Потрата токенов возрастает кратно. Тратим время и токены на координацию.

Плюсы? Сложная работа, требующая обсуждений и предполагающая большой объем - вот тема такой фичи. Мы же все знаем что рефлексия работает. Вот тут она помогает в полный рост!

В общем, интересная фича, надо смотреть как это все будет работать.

П.С. В кодексе готовится нечто похожее - collab назыввается в рабочем порядке

@deksden_notes