DEKSDEN notes

⚪️ Антропики свармом навайбкодили С компилятор Вот статейка: 🔗 https://www.anthropic.com/engineering/building-c-compiler Опус 4.6 за 2 недели, 16 агентов, $20k в ценах апи потрата кредитов (это 2 подписки макс-200 наверное). 2000 сессий. 2B токенов всего. Вышло 100k loc, rust компилятор - компилирует ядро Linux, для x86, arm, risk-v. В статье самое важное - это собственно не сам проект, хотя сделать РАБОТАЮЩИЙ компилятор - это прикольно. В статье интересно КАК разработчик организовывал этот проект. Я специально использую такой термин - ведь работа человека изменилась. Он не разрабатывает софт. Он создает условия чтобы ИИ агенты разрабатывали софт! Что пришлось делать: • он сделал циклы в ральф-стиле, чтобы агенты брали очередную задачу, и решали ее "до упора"; интересно что один из агентов самоубился через pkill -9 bash, убив контролирующий скрипт; • он не делал агента оркестратора • он не делал коммуникации между агентами • пул задач с локом задачи • в целом оркестрация выглядит примитивной и рудиментарной - явная область улучшения • основная работа челоека заключалась в системе тестов, чтобы сформирвоать такую систему тестов, которая позволила агентам сделать работоспособный продукт Интересно, как решил проблему с компиляцией ядра линукса. Это одна гиганская задача. В лоб не решалось - все 16 агентов начинали работу, сталкивались с одинаковыми багами и терли изменения друг друга. Как решил: взял GCC, компилировал им большую часть ядра - а некоторые файлы компилировал своим компилятором. Если встречалась ошибка - пробовал GCC для верификации - и если баг локализован, отдавал на фикс агенту. Также некоторых агентов специализировал: следить за эффективностью компиляции, устранять дублирующийся код, следить за общей архитектурой решения "сверху". Интересно, что опус 4.5 первым в 4 поколении клодов, кто сделал хоть какой то работающий компилятор. И только опус 4.6 смог сделать компиляцию ядра линукса! В общем, вот оно: https://github.com/anthropics/claudes-c-compiler Там куча ограничений и недоделок - подробнее в статье, но это во многом работает! Круто, конечно (ц) Такое мы уважаем @deksden_notes

⚪️ Startup perks: каталог програм поодержки стартапов Какие облачные сервисы дают стартапам кредиты на свои услуги для поддержки. Собственно, сабж: 🔗 https://www.startupperks.xyz/ 41 программа! (ц) Такое я вижу полезным @deksden_notes

⚪️ Swarms - новая парадигма? В СС вышла в качестве research preview новая фича, которая называется Agent Teams (агентные команды). 🔗 почитать тут: https://code.claude.com/docs/en/agent-teams Идея такая: агент-координатор (team lead) создает команду из агентов, координирует работу, раздает задачи другим участникам команды и пишет отчет о результатах работы. В чем отличие от субагентов? На первый взгляд, с точки зрения структуры работы ситуация аналогичная: главный агент-оркестратор и работающие параллельно в отдельных сессиях суб-агенты. Разница в уровне децентрализации и оформленности выделенных членов команд. В агентной команде агенты - это полноценные агенты, в разных процессах, каждый со своей сессией. Общаться они могут друг с другом напрямую, минуя координатора (agent mail). Вы можете подключаться к каждому агенту в команде и даже давать ему инструкции через чат с ним! Агенты само-координируются в процессе работы Недостатки? Потрата токенов возрастает кратно. Тратим время и токены на координацию. Плюсы? Сложная работа, требующая обсуждений и предполагающая большой объем - вот тема такой фичи. Мы же все знаем что рефлексия работает. Вот тут она помогает в полный рост! В общем, интересная фича, надо смотреть как это все будет работать. @deksden_notes

⚪️ Рыбный день ... как известно - четверг! А этот выдался особенно рыбным. Тятя, тятя! Наши сети притащили: * 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

⚪️ Материалы канала Не все обращают внимание - в закрепе есть оглавление канала. Там я некоторые ссылки на полезные посты размещаю, для облегчения навигации! Но не все вошло Подсобирал материал по каналу, может пригодится кому каталог ссылок: ▶️ Контекст-инжиниринг для меморибанков: * индексные файлы 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

⚪️ .agents/skills петиция К Антропикам. Сабж: https://x.com/iannuttall/status/2018760297368932726?s=20 Хотят чтобы де-факто народившийся стандарт поддержали все топовые вендоры. Это разумно! почему не agent/skills? По AGENTS.md аналогии. В общем - хорошее дело! Кому не жалко - лайкните! Я лайкнул @deksden_notes

⚪️ 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

⚪️ Соннет 5 … и опус 4.6 по слухам вот вот. Еще вчера! Ждемс? Чего думаете поправят? Мои боли от Клодов: контекст, внимание, вранье.

⚪️ Git flow, часть финальная. А чо так замороченно? Я всегда говорил, что у каждого свои флоу. Но свой я задумал завернуть в оркестратор. Когда это работает "в ручном" режиме, кажется все намного проще. Попытки автоматизации всего процесса делают его немного более сложным: каждая часть флоу при автоматизации требует обустраивания. Детерминированные части работают не всегда автономно, и без агентных добавок могут требовать ручного вмешательства. Поэтому везде по возможности прикручивал агентов. В итоге получилось не особо сложно: * агенты крутятся в своих флоу, пилят фичи в рабочих деревьях, и мержат их очередью * результаты можно пощупать через пары релизных пайплайнов - чтобы и npm релизы посмотреть, и текущую работу в develop * а сам могу руками поработать в dev ветке, которую "тащат" два процесса: Add-merge добавляет мою работу в общую очередь мержей, и dev-sync "подтягивает" мою ветку на текущий origin/develop Вот такая гравицапа вышла ❓ А вы как работаете с агентами? с git?

⚪️ Агентный 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, часть 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 для оркестратора, часть 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 чтобы если что - пользователя вовлечь к решению проблемы. Удобно.

⚪️ 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 • план-мод включили по-умолчанию @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

⚪️ JustBash Чего то Vercel разошелся! Новый релиз - JustBash: это такой сендбокс для багаш на TS, с кучей знакомых команд и настройками файловой системы. Например, читаем файлы с диска, пишем файлы в память. Получается полная изоляция Любопытно 🔗 https://justbash.dev/ 🔗 https://github.com/vercel-labs/bash-tool @deksden_notes

⚪️ KIMI 2.5 free в OpenCode Кто хотел пощупать кими как агента - в openCode оно пока бесплатное! Успеваем тестить @deksden_notes

⚪️ 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

⚪️ Vercel и Agents.md По следам блога Vercel про усвоение скиллов, уже сделали вот такую штуку, которая превращает скиллы в индекс для добавления в AGENTS.md файл, улучшая воспирятие агентом: 🔗 https://github.com/leviathofnoesia/AgentCompiler Ну и такая штука встретилась: компилирует любую документацию в скилл: 🔗 https://github.com/hyperbrowserai/hyperbrowser-app-examples/tree/ex/hyperskill/skills-generator Может, кому то будет полезно @

⚪️ Работа с контекстом после прайминга У меня практика такая: я использую контекст после прайминга для разных вещей. Во-первых, есть некоторый пул "контекстов", у которых завершена первая фаза прайминга - агент прочитал индекс меморибанка и изучил общие сведения о системе. Такие контексты висят у меня неким пулом, я беру очередной для той или иной работы. Во-вторых, в оркестраторе такие контексты используются для выполнения различных задач: текущий шаг, фикс, и тп. Так я обеспечиваю некоторый рост качества работы. Как работаю, если мне нужно сделать доработку в проект? • контекст прогрет под конкретную тему, агент погрузился в нее и готов обсуждать. • я в свободной форме излагаю свои идеи доработки и прошу проработать вопрос, сообщить мне как это можно сделать - на старте всегда предлагаю подумать несколько вариантов, и обязательно изложить логику для оценки вариантов, какие рекомендации дает агент; • я прямо говорю агенту: исследуй и изучи, как это лучше сделать в проекте; исследуй код, подготовься; • после того, как тема прорисовывается, я прошу задать мне вопросы: спросить все что непонятно, устранить 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