DEKSDEN notes

♊️ Планируем с Gemini 3/3 Предыдущая часть: https://t.me/deksden_notes/105 ... ▶️ Третьим запросом к модели мы просим сформировать чек-лист по рефакторингу, где укажем все существенные детали реализации, которые важны для нашей системы и функционировании решения. Модель, сформировав контекст из концепции + плана может выдать адекватный чек-лист для проверки как этот план реализован. Чек-лист мы аналогично сохраняем в отдельный файлик md, и после завершения рефакторинга просим ИИ агента использовать этот чек-лист для проверки фактического кода и документации. ❓ Зачем нужен чек-лист, ведь у нас есть подробный план реализации? В принципе, можно и план реализации использовать как чек-лист, но отдельный документ улучшает качество проверки. ❓ А а чем вообще чек-лист, может достаточно одного плана? Как показывает практика, агент при реализации самого подробного плана всегда может немного отклониться от задания. А ревью сделанной работы по чек-листу помогает добиться практически гарантированной реализации задуманного. Посмотрите сами - даже в несложных задачах ревью по чек-листу может вскрыть какие то шероховатости. ▶️ Почёму мы вообще ведём речь об этом "ручном" способе планирования, если в нынешнее время уже есть ИИ агенты, и даже Gemini CLI, работающая ровно на этой же модели? Вопрос совершенно закономерный. Тут важно понимать: есть существенная разница между контекстом, который сформировал агент, и контекстом из файла репозитория, где методично запакованы все файлы, ещё и, как правило, по папкам разложенные в логически связанные группы - мы же разные подсистемы обычно по папкам располагаем, и в репо они упакованы аналогично, рядом. Качество контекста, который формирует агент очень сильно зависит от того, как вы ведёте меморибанк и насколько агент смог разобраться, какую релевантную информацию и из какого места следует подгрузить в контекст. Кроме того, агент как правило, читает файлы "кусками", что может вызвать некоторую фрагментацию. В итоге: работа Gemini CLI и Gemini 2.5pro в AI Studio сильно отличается в пользу веб-версии: она меньше путается в контексте и почти не путается в сообщениях (только в районе лимита в 1m). Gemini CLI не будет иметь каких то особенных преимуществ по сравнению с другим агентом, только за счёт огромного контекста - ведь этот контекст ещё надо собрать! и если Gemini его смог собрать по вашему меморибанку, скорее всего то же самое может сделать и другой агент. Да, Gemini CLI на большом контексте может теоретически работать дольше, но тут есть практические вопросы к более низкой агентности Gemini 2.5pro в сравнении с Клодом или Gpt-5-codex. Тут надо ждать Gemini 3.0, в которой, наверняка, агентность будут повышать - проблема то известная. 🟢 Такие вот приёмы я использую при планировании с Гемини - чего и вам настоятельно советую. На данный момент один из лучших вариантов для проектов меньше 1m токенов. #post @deksden_notes

♊️ Планируем с Gemini 2/3 предыдущая часть: https://t.me/deksden_notes/104 ... ▶️ Итак, постепенно через некоторое количество итераций вы сформировали концепцию и получили полностью устраивающий вас ответ модели, который в нужном ключе описывает вашу идею рефакторинга. Теперь пришло время составить план. Вам нужно объяснить модели что реализацию этого плана будет делать junior developer, у которого не будет доступа к контексту чата, и ему нужно будет рассказать все детали плана. Более того, он слабо разбирается в проекте, поэтому ему нужно дать ссылку на всю необходимую документацию относительно аспектов плана, и вообще - всячески облегчить ему жизнь. Пускай модель подумает что ему ещё поможет помимо того, что вы просите. Очень важно промптом просить все затрагиваемые высокоуровневые концепции проекта прописать в плане. Если использовать C4 методику (пост про C4 тут https://t.me/deksden_notes/55) для структурирования понимания проекта, обязательно просите прояснить затронутые L2 контейнера (подсистемы), их контракты, схему интеграции. Какие общие пакеты/модули надо задействовать. Про текущий код - обязательно какие паттерны использовать. Необходимо спланирвоать L3 компоненты, которые буду созданы, как они впишутся в текущий L2 контейнер. Это помимо деталей самого кода, алгоритмов там и прочего - уровня L4. Если в вашем меморибанке прописаны мета-сведения (карты взаимодействия подсистем, контракты подсистем) - нужны будут ссылки на эти документы. Важно: насыщайте план "увязками" на уровне "выше" кода, - L3, L4. Модель (пока еще?) не в состоянии проработать абсолютно все детали, и ИИ агенту может понадобиться самому принимать некоторые решения при реализации плана - и будет важно чтобы у агента был необходимый контекст для грамотной интеграции решения в проект. Не забывайте об интеграции новой документации в меморибанк: просите добавить раздел про документацию в план работы - и прописать куда, что и как добавить. Ведь модель "видит" весь ваш меморибанк, и может грамотно посоветовать какие файлы нуждаются в обновлении, а когда можно новый файл создать. Назовём эту технику "junior-dev-plan", хотя это про целевую роль, а сам план должен быть весьма и весьма хорошего уровня проектирования. ▶️ Модель в итоге выдаст вам некий подробный план, который можно сразу "закидывать" в ИИ агента просто Paste в строчку ввода - но вы так не делайте. Сохраняйте план в md файлик, благо AI Studio поддерживает копирование в формате маркдаун всего ответа "за раз". Зачем? Этот файлик поможет ИИ агенту если план окажется ОЧЕНЬ объёмным и агент не сможет выполнить его "за один контекст". Вы всегда сможете "восстановить" контекст после компакта простым промптом вроде "Прочитай файл {мой_план_рефакторинга}.md для контекста, продолжай работу". СС такие подсказки "подхватывает" даже "на ходу", не останавливаясь, а для Кодекса нужно тормознуть агента. Важно понимать, что план будет ВТОРЫМ ответом модели в чате - ведь проработку концепции вы просили первым ответом. ❓ Почему не попросить сразу план в первоначальном запросе, ведь мы его меняли столько раз, чтобы итеративно доработать? По двум причинам: - проработка концепции - это один фокус модели, она должна думать о задаче, предметной области, вариантах решения, идеях и развитии; проработка плана - немного другой фокус, уже с вниманием на текущем существующем коде, интеграции, документации, сборке контекста; не нужно пытаться в одном запросе мешать два фокуса внимания - это снижает качество; - рефлексию никто не отменял - модель "еще раз" просмотрит концепцию при формировании плана, особенно если вы ей это позволите, и может кое что лучше проработать, особенно когда при проработке плана она фокусирована на интеграции с существующим кодом; ... Продолжение: https://t.me/deksden_notes/106 #post @deksden_notes

♊️ Планируем с Gemini 1/3 Очевидно, что вводный пост про Repomix (https://t.me/deksden_notes/102) был нужен чтобы рассказать про тему работы с Gemini 2.5 pro в AI Studio. На самом деле, конечно, любое веб приложение подходит под такую методику - достойные варианты Qwen, DeepSeek, chatGPT, grok, z.ai, kimi. Но на сентябрь 2025 достойных моделей с контекстом 1m токенов, ещё и бесплатно - таких вариантов почти нет. Про Qwen 1m и Meta Llama4 я знаю, но я же специально сказал - достойных! )) Да, Gemini 2.5 pro и сейчас, более чем через полгода от выпуска, смотрится вполне достойно. С нетерпением ждём поколение 3.0. Впрочем, приступим! Дано: у нас есть маленький или средний проект. Мы хотим провести рефакторинг, добавить фичу или ещё чего-то сотворить с проектом, для чего, конечно, будем использовать ИИ агента. Мы уже знаем, что Vibe Coding нам не друг, потому что когда такие друзья, жить будет совсем не скучно, а мы хотим - спокойно и без сложностей на ровном месте. А для этого надо качественно сделать работу и мы уже знаем что надо бы пользовать SDD - Spec Driven Development. Здорово, когда в нашем проекте уже есть меморибанк. Итак, мы понимаем что для нашей работы нам нужен план. "Есть ли у вас план, мистер Фикс?!". Вот его то мы и будем собирать в Gemini. На самом деле, "единый" взгляд на проект может быть удобен для самых разных вещей - обсудить архитектуру, ревизовать меморибанк, подумать над фичами, собрать техзадание под разработку дизайна в тулах, - мало ли! Но мы обсудим использование и практические приёмы на примере планирования некоего рефакторинга в коде: довольно показательный кейс, паттерны которого можно применять и в других активностях. Я напишу про свои приёмы, которые я использую - не претендую на абсолютную истину или методичность, это просто обобщение практики и воспринимайте это как некие советы. Никаких особых "законов" или строгих методологий тут нет - "мы здесь занимаемся практической магией". ▶️ Начнём планировать рефакторинг. Если у вас есть "в загашнике" специальный промпт на 3 страницы - применяйте. Если нет - не страшно: пишите обычный вопрос "хочу обсудить как сделать ...". Модель вам отвечает. Читаете ответ, то что нравится - вы добавляете как уже готовые вводные В ВАШ ОРИГИНАЛЬНЫЙ ЗАПРОС. В AI Studio можно легко редактировать хоть свой запрос, хоть ответ модели. Добавляйте то, в чем у вас возникла уверенность или новое понимание, можно куски ответа модели копировать. Когда закончите - ПЕРЕГЕНЕРИРУЙТЕ ответ на ваш первоначальный запрос. На следующей итерации за счёт более "обогащённого" запроса модель у вас получается более развёрнутый ответ модели, и уже в нужном вам ключе, который проработан в нужном вам направлении. Используя этот ответ, вы далее "обогащаете" запрос, добавляя тезисы, которые вам нравятся и ведут вас в нужном направлении. Такими вот итерациями, ваш первоначальный просто неструктурированный запрос постепенно превращается в развёрнутую концепцию. Не забывайте "забирать" из ответов модели то, что вам понравилось - чтобы не потерять при перегенерации полезную информацию. Если температура выше 0, то следующий ответ даже на такой же запрос будет точно другим. ❓ Назовём эту технику "Итеративное улучшение промпта". Но зачем так сложно? Дело в том, что на контекстах более 300к токенов внимание модели все более размывается, она становится менее внимательная, и качество ответов падает. Если вы будете много спрашивать модель о разных штуках - контекст чата с этими разноплановыми запросами и ответами будет размывать внимание модели, и она начнёт путаться. Вам же нужно развитие идеи в нужном вам направлении? Так не оставляйте в контексте ничего постороннего: GIGO (garbage in, garbage out!). А за счёт перегенерации оригинального запроса качестов ответа модели не деградирует даже если сделать десятки итераций. ... продолжение: https://t.me/deksden_notes/105

📦 Кейс: пакуем проекты с Repomix 2/2 Начало: https://t.me/deksden_notes/102 ... В этом конфиге указано, что ИГНОРИРУЕТСЯ папка "tests/". В принципе, в качестве игнорируемых папок можно прописать ВСЕ ПАПКИ исходников проекта, и комментировать те, которые НУЖНО ВКЛЮЧИТЬ. Так можно точечно включать или выключать нужные папки. Такой конфиг можно назвать "repomix:cutom" и использовать его в специальных случаях. Используем кастомные конфиги если нужно экономить контекст - отключаем паковку "кусков" системы, которые обсуждать с Gemini не будем - например, обсуждая UI, можно отключить api (кроме спеков по контрактам/описанию api).  Всегда можно часто используемые "пресеты" сохранить в отдельную конфигурацию и уже паковать её скриптом одним кликом - я всегда за автоматизацию, она сокращает ошибки и не тратит ресурс внимания пользователя. ▶️ Когда repomix запаковал проект, полезно в логе посмотреть такие вещи: - Главное: какого размера получился _repo.xml в токенах, чтобы было меньше 1m. - Второе: какие самые крупные файлы попали в проект - иногда паковка "хватает" ненужные файлы типа логов или какие то крупные служебные файлы, или какой нибудь json экспорт или ещё чего то лишнее. - Можно открыть репо файл в вашей IDE и посмотреть оглавление - repomix его добавляет в начало файла. Там проверьте, что все нужные папки и файлы попали в репозиторий. ▶️ Итак, репо файл получен, мы готовы для его загрузки в AI Studio. Счётчик токенов студии будет немного другой чем у репомикса, потому что Гугл использует иные токенайзеры, но это не принципиально. 👉 К слову - файл прекрасно загружается в DeepSeek, z.ai, ChatGPT Pro, Grok, claude.ai. #post @deksden_notes

📦 Кейс: пакуем проекты с Repomix 1/2 Небольшой практический кейс. Вспомним те доисторические времена, овеянные легендами древности, когда для работы с проектами мы использовали веб приложения чатов с различными моделями. Ведь тогда нам ещё не явились ИИ агенты с подписками по разумным ценам! Но и сейчас есть достойные случаи для всей этой возни с веб чатами: например, контекст в 1m токенов у Гемини, который позволяет модели сразу видеть огромный объём данных - например, ваш проект целиком. До сих пор скорость, удобство и качество такого подхода сложно превзойти любому ИИ агенту с каким бы то ни было меморибанком или индексом (пожалуй, только Qoder немного составляет конкуренцию). Поэтому кейс актуален и по сей день. ▶️ Для передачи в Ai Studio будем использовать Repomix (https://repomix.com/), поставим его в свой проект своим любимым менеджером пакетов - инструкции на оффсайте по ссылке чуть выше. Для ts/js проектов в проектах я прописываю скрипт для использования репомикс в package.json: "repomix:all": "repomix -c repomix.config.json".  Как ещё можно запаковать, почему "all", для чего нужно по-другому? Например, для крупных проектов - только меморибанк, чтобы хотя бы общие вещи обсуждать. Можно паковать только код - без тестов, если размер проекта пограничный на 1m токенов, или вы не хотите размывания внимания модели.  Для обеспечения разных "видов" паковки нам потребуются разные конфиги repomix. конфиг - файл в корне проекта, документация по нему на оффсайте. 🟢 Вот пример моего конфига для "repomix:no-test": "repomix -c repomix.no-test.config.json": repomix.no-test.config.json:

{
  "output": {
    "filePath": "_repo.xml",
    "style": "xml",
    "parsableStyle": false,
    "fileSummary": true,
    "directoryStructure": true,
    "removeComments": false,
    "removeEmptyLines": false,
    "topFilesLength": 5,
    "showLineNumbers": false,
    "copyToClipboard": false
  },

  "include": [],

  "ignore": {
    "useGitignore": true,
    "useDefaultPatterns": false,
    "customPatterns": [
      ".git",
      "data",
      ".husky",
      "pnpm*.*",
      "_archive/",
      //        "src/",
      ".tasks/",
      ".memory-bank/archive/",
      ".memory-bank/.obsidian/",
      ".memory-bank/agents/",
      ".memory-bank/commands/",
      ".memory-bank/issues/",
      ".vscode/",
      ".idea",
      ".gemini",
      ".codex",
      ".claude",
      ".aider",
      ".github",
      "test-results/",
      "tests/",
      "seeds/",
      "scripts/",
      "logs",
      ".run",
      "*.patch",
      "**/*.log",
      "log*.txt",
      "*-lock.*",
      "LICENSE"
    ]
  },

  "security": {
    "enableSecurityCheck": true
  },

  "tokenCount": {
    "encoding": "o200k_base"
  }
}

Особенности "пациента": игнорируется куча ненужных файлов: разные артефакты агентов, IDE, менеджеров пакетов и прочее, что не очень нужно (артефакты тестирования/сборки/ci-cd).  Обратите внимание : меморибанк я смотрю через Obsidian, подключая его как отдельный Vault - мы игнорируем служебную папку Obsidian. Мы игнорируем папки агентов и команд - они подключены к Клоду (в папку '.claude/' проекта) через симлинки, - чтобы я мог хранить команды и агентов. Если нужно, я могу переподключить на уровень пользователя для использования этого же набора агентов и команд в другом проекте. Или использовать эти команды в другом ИИ агенте - вдруг появятся совместимые по формату. "seeds/" - вспомогательные папки, храню там начальные данные для БД. "scripts/" - вспомогательные скрипты (sh/ts). Если использовать расширение *.jsonc/*.json5 (https://github.com/yamadashy/repomix/issues/618) можно комменты в конфиг добавлять без репорта об ошибках от IDE. ... продолжение: https://t.me/deksden_notes/103

🐞 Anthropic публикует post-mortem анализ багов с Claude Сабж: https://www.anthropic.com/engineering/a-postmortem-of-three-recent-issues ❓ Верим? Причина "отупления" Claude Code найдена и устранена? ▶️ Я не могу сказать, я особо на такие эффекты не натыкался. Пытаясь разобраться, сравнивал какие заключения о причинах багов делает sonnet и gpt-5-codex/high . В целом, кодекс обычно подтверждает выводы, но может копнуть поглубже, и лучше "понимает" как комплексно исправить баг. Конечно, более корректно сравнивать opus 4.1 с codex/high, чем я сейчас занимаюсь. Результаты расскажу, конечно - но надо бы поднабрать статистику. ⏩️ 👉 А у вас какой опыт/наблюдения? #post @deksden_notes

Github MCP Registry BIG news для отрасли, в каком то смысле. Github запускает свой регистр MCP серверов, убив разом пучок стартапов, видимо! https://github.blog/ai-and-ml/github-copilot/meet-the-github-mcp-registry-the-fastest-way-to-discover-mcp-servers/ Нужная инициатива и признание роли MCP. Круто же! ) К релизу приурочен GA собственного MCP от GitHub https://github.blog/changelog/2025-09-04-remote-github-mcp-server-is-now-generally-available/ Пока в реестре 38 серверов всего, но в планах - поддержка/интеграция с открытым реестром: https://github.com/modelcontextprotocol/registry/ Интересно, конечно #post @deksden_notes

⚒️ Gpt-5-codex, вторые впечатления Первые впечатления были тут https://t.me/deksden_notes/91 Это - вторые впечатления. В общем, модель очевидно другая в части агентности. В районе часа над моими задачами работает сама, без особых плясок с бубном. План, конечно, выгрузил в файлик - но не особо пригождается: ей хватает контекста! Удивительно. Надо изучить как именно она так экономно работает с контекстом. Запускать что то внешнее по прежнему можно с проблемами. модель иногда достаточно медленная. но все это не главное - главное что модель весьма умная! радует Плюс: она не льстит, что капец как важно при обсуждениях. Хороший релиз, кмк. #post @deksden_notes

🤔 Думать надо анимированно Тут подоспел релиз СС с индексом 115 (на самом деле 117 уже) И в нем реализовали визуальный фект для "магических" слов, которые заставляют Клод думать Попробуйте! Пишем в строке ввода в СС: - think - think hard, think deeply - ultrathink Эффект разный)) Не уверен что это прям нужно, но местами может быть даже полезно и забавно Upd: коллеги уже постят мемы на тему https://t.me/aiclubsweggs/73056 #post @deksden_notes

🆕 Первые впечатления от Claude for Chrome Утром получил письмо счастья от Антропиков, что мой лист ожидания сработал и у меня есть доступ к их новой фиче, клод в твоём браузере. Ура! Пойдём тестить. Качаем расширение, логинимся в клод с Макс тарифом, одобряем подключение расширения и получаем аккуратную панель чата с клодом сбоку странички. Ставим одобрение всего сразу - "нам нечего терять кроме наших цепей!" Просим смотреть озон и искать товары. Заходит норм, антибот озона на него не срабатывает, что отлично. Поиском пользуется, навигацию по сайту делает. Дальше начинаем тупить - при попытке открыть товар кликом по нему, на озоне он открывается в новой вкладке, чего клод не видит и тупит. Потыкавшись немного в проблему с невозможностью зайти в товар, он придумывает сходить в гугл поиск. Далее получаем ошибку переполнения контекста. Ну ок - что то работает, что то нет. Надо подумать над другими тестами #post @deksden_notes

➡️ Параллельный запуск - итоги ❓ Короткий апдейт: в чем был смысл? Посмотрите на скрин. Система работала итого чуть более 8 минут абсолютного времени. Но за это время сделано общей работы - более 25 минут! более 600к токенов. В один поток это было бы 150к токенов максимум за такое время. А это - все показатели реально выполненной работы и пользы. PROFIT? Очевидно - да, кмк. ▶️ Как можно улучшить? Можно инструктировать оркестратора на генерацию yaml/json файла с итогами. Этот файл - машиночитаемый. Ваш раннер для скрипта может смотреть на этот файл, и если вас не устраивают показатели - делать повторный запуск. Кто в курсе - у текущего клода есть ... не знаю как сказать, но пусть будет "особенность"! Он очень любит приукрашивать состояние дел, и при запуске тестов отчитываться об enterprise ready high quality system когда у вас 50% тестов валится красными. Для борьбы с "особенностями" пригодится такой сгенерированный файл: если гонять агентов "до посинения" бездушным скриптом по крону "в ночь", то можно к утру каждый день получать "полностью зеленый" проект! Это касается и lint/typecheck, и тестов. #post @deksden_notes

➡️ Небольшой практический пример параллельного запуска агентов Приведу простой пример как можно организовать агентный процесс и использовать возможность СС запускать процессы параллельно. Исходная задача: проект на TypeScript. Для него мы делаем typecheck и lint. Typecheck - это запусе typescript компилятора в режиме проверки кода (без генерации js бандла), lint - это запуск линтера, который используется в проекте. Часто это ESLint, для next.js это next lint, я последнее время для ts настраиваю biome. ➡️ Рассмотрим как тут можно кое-что ускорить за счёт параллельных задач. Первое: получить результаты компилирования и линтинга. Очевидно, что утилиты можно запустить параллельно, это мы пропишем "ручную". Для запуска будем использовать специализированного агента, назовём "qa-agent". В контексте агента указываем: - соберём из меморибанка сведения о тех стеке проекта, чтобы агент умел запускать утилиты, - знал про конфиги и в случае чего мог поправить конфиг. - знал какие папки нужно игнорировать (для ts это dist папки со сгенерированным компилятором js) - определитесь - lint для тестов в проекте вы делаете? а компиляцию? и пропишем это в агенте; - (на самом деле главная компетенция агента - умение запускать тесты, но чтобы не разводить слишком большую стаю агентов мы его и для компиляции с линтингом задействуем) Итак, запуск агентов параллельно нужно сопроводить фразой: "запускай агенты qa-agent для выполнения Typecheck и lint проекта параллельно, для этого вызывай команду запуска двух агента в ОДНОМ своём сообщении." Суть магии этой фразы - добиться чтобы модель сделала "параллельный вызов" tools. Технически это происходит когда модель в одном своём ответе запрашивает вызов нескольких инструментов. СС поддерживает такую штуку и запустит агентов параллельно. ➡️ Дальше интереснее: получив результаты компилятора и линтера можно поручить модели спланировать параллельную обработку результатов - мы будем фиксить проблемы параллельными агентами. ❓ Какие есть возможности параллельной обработки проекта? принципиально их всего две: - развести "области работы" и параллельно обрабатывать непересекающиеся части проекта; это самый простой и беспроблемный способ - если задача с понятной "зоной изменения", и мы знаем какие файлы будут изменяться, то можем поручить исправление разных файлов разным агентам. Этот способ позволяет избежать стадии решения конфликтов при "вливании" результатов работы в репозиторий. - если зоны работы агентов пересекаются - необходимо использовать изоляцию на уровне Git: локально мы можем использовать worktree для каждого агента, или классические branch. Детали зависят от схемы работы с git в вашем проекте. Это может быть стандартные бранчи main -> develop -> (feature branch). По завершении работы мы мержим worktree/branch обратно в develop - конечно, все это делают агенты. Для нашей задачи с исправлением ошибок компилятора / lint подходит первый вариант: ведь мы знаем списки проблемных файлов. Мы инcтруктируем оркестратора сгруппировать проблемы с компиляцией и линтом по файлам, и распределить их между 5-7 агентами таким образом, чтобы файлы не пересекались и агенты не мешали друг другу. Запускать агенты мы будем также, параллельно. Агент нужен будет для написания кода, "code-writer": - знает структуру кода в проекте - знает стандарты кодпирования - знает как оформлять jsdoc, какие кросс-ссылки проставлять Запускаем аналогично: даём инструкцию вызывать всех агентов в ОДНОМ сообщении оркестратора. ➡️ Итак - на верхнем уровне у оркестратора одна задача - запускать агентов, получать списки файлов и провести планирование работы так, чтобы разделить "зоны" между агентами, а в конце отчитаться о результатах. Все детали о запуске компилятора/линтера и требованиях к написанию кода будут внутри промптов субагентов. 🟢 Такая штука работает вполне надёжно и может быть запущена как отдельное агентское воркфлоу через claude code sdk/cli, можно даже по крону (ночью?). #post @deksden_notes

⚒️ Новый релиз codex 0.36.0 и gpt-5-codex модель Не даром аж 4 дня не обновляли кодекс! Готовился достаточно крупный релиз: - новая специальная кодинговая модель - codex resume : можно выбрать сессию которую восстанавливать, можно --last, можно по <id> - и куча других мелких, но приятных новшеств, подробнее тут: https://github.com/openai/codex/releases/tag/rust-v0.36.0 Первые впечатления про codex-5-medium/high Не хуже классического gpt-5-medium/high. Интерфейс теперь показывает кое-какие мысли. Думать может долго, но для простых задач может и быстро - не разобрался ещё что и как. Пока кажется что стало несколько задумчевее все! Посмотрим как будет работать на крупном контексте. Gpt-5 на 75% контекста уже начинает путаться в ответах и чудить. Посмотрим как будет себя вести кодекс. Upd: добавлю ссылочку где почитать про модель: https://openai.com/index/introducing-upgrades-to-codex/ - на простые вопросы отвечает действительно быстро. Видимо, это и есть обозначенная динамическая подстройка под сложность вопроса. - местами задумывается без признаков жизни - только часики тикают. Но это просто думает. - на большом контексте догнал 2 чата до 4% left, не чудил. Но есть ли или нету автокомпакта (который анонсировали) пока не пробовал, эти чаты было жалко, попробую потом на чем нибудь не важном Upd2: спецэффекты к gpt-5-codex начинаются при приближении к 0% свободного конекста! не доводите, он прям деградирует по вниманию - путает сообщения при ответах, и все такое. Лучше уж компакт и восстановление контекста Промпт для рефреша контекста в таком духе: "подготовлся с обсуждению вопроса {тематика}, читай код, документацию/меморибанк и подготовь контекст. Сами вопросы будут позже." #post @deksden_notes

👉 Вайбкодинг сессии 2/2 ... (начало тут: https://t.me/deksden_notes/89) ❓почему документация именно вторым пунктом а не после внесения изменений? По той же причине, что и создание плана первым пунктом. Только план вы используете сейчас, а документация - это то что останется для последующей работы. Это не менее важно, потому приоритетно. ❓Зачем сверять в конце? Потому что агент "забывает" или "упускает" ряд моментов. Чем тщательнее на старте были прописаны детали вашего плана в файл, тем полнее будет реализация того. Даже не очень длинные воркфлоу на моей практике оборачивались доработками по чек-листу. ❓Что делать если настигла компактификация? Простой промпт "по ходу дела" помогает - "Прочитай файл {путь и имя файла с планом} для контекста, продолжай по плану". Засылайте такой промпт во время компактификации, тогда он его обработает сразу после возобновления работы, и забывание будет значительно скомпенсировано. ❓Есть же встроенный инструмент todo? Зачем дублировать в файл? Встроенный инструмент не содержит подробных сведений - только краткие пункты. Да, агент не забудет что надо сделать. Но может упустить проработанные вами при планировании детали - "как" именно все нужно было делать, ну и нюансы интеграции. Вы же проработали это при планировании, да? ℹ️ Это базовый подход. Что можно улучшать: сделать отдельные этапы на базе специализированных агентов. Если у вас есть агент, работающий с меморибанком, который в курсе про структуру хранени я информации и правила хранения данных, то документирование в меморибанк проводим через него. Если у вас есть кодовые агенты, которые знают стиль кодирования, структуру системы, интеграции подсистем, где искать контракты подсистем, то код писать лучше через них. Да, субагенты будут работать подольше - зато качество работы будет повыше и конекст оркестратора "целее", что позитивно для отслеживания общего плана. Такие вот приёмы #post @deksden_notes

👉 Вайбкодинг сессии 1/2 Да, мы все с вами понимаем, что Spec-Driven Development это топ, и в целом видимо в тех краях будущее AI-driven разработки. Но регулярно возникает необходимость оперативно внести изменения в код проекта, для которого ещё не выстроен полноценный AI SWE Pipeline на спеках и агентах. Тогда у нас начинается "вайбкодинг" - относительно интерактивные сессии работы с системой. Что я бы посоветовал и что применяю сам в таких случаях: ‼️ Контекст должен быть чистым/достаточно свободным. Всегда начинайте новый вопрос с чистого контекста, идеально - /clear для старта новой сессии; Иногда это невозможно: допустим, если вы в процессе чата поняли необходимость внесения изменений в код. Тут важно понять: достаочно ли у вас контекста для обсуждения изменений. Вы же используете ccstatusline? смотрите сколько токенов сейчас в контексте. Прикидывайте сколько вы потратите на обсуждения вашего рефакторинга. Если есть опасения что не хватит - делайте команду "/compact {инструкции}", а в качестве инструкции описывайте максимально те сведения, которые вам надо оставить в контексте - тогда компактификация чуть лучше сохранит вам контекст. ‼️ Используем plan mode. Идеально если у вас есть max план и доступен opus. тогда вы можете поставить модель "opusplan" (через команду /model), и тогда при переключении в режим планирования включится гораздо более эрудированный опус, что поможет. А когда вы завершите планирование, для кодинга по сформированному плану у вас будет достаточно быстрый соннет. ❓Зачем использовать "plan mode" если у вас нету opus на тарифе, и есть только соннет? Потому что это удобная возможность не писать в промптах "не делай пока код, давай обсудим". Агент будет обсуждать с вами планы, не "срываясь" фальшстартами в кодинг. ‼️ Включите стиль "Explanatory" - он значительно разбавит сухой лаконичный стиль общения СС, что важно в обсуждениях при планировании. Используйте команду "/output-style" ‼️ Прежде чем задавать свой вопрос попросите агента подготовится. Пишите "Подготовься, собери необходимый контекст: будем обсуждать вопрос ...". СС пошуршит по вашему проекту, соберёт инфу. Тогда обсуждение сразу будет предметное. ‼️ Обсуждайте вопрос. Если вышла табличка с планом, жмите 3 (отвергнуть план, продолжить обсуждение) - и пишите дальнейшие вопросы для проработки. ‼️ Когда вы получили нужное вам решение, то перед реализацией советую сделать следующие пункты: ▶️ Первым пунктом плана необходимо запланировать создание подробного плана работы в файле маркдаун с чек-листом, где указать что будем делать, где, ПОЧЕМУ именно так, какие сведения используем, на какую документацию опираемся, каким стандартам кодирования следуем, что в части интеграции отслеживаем. План разместить в папке .protocols/ в корневой папке проекта. ▶️ Вторым пунктом плана: изучить меморибанк, изучить его структуру, понять какие документы используются в документировании изменяющихся модулей системы, и прописать изменения в документацию. Принцип - docs first, мы прописываем изменения ДО их внесения. ▶️ Последним пунктом плана необходимо прописать: читаем файл маркдаун из пункта один, и систематически сверям каждый изменённый файл коди и документации с планом. Далее необходимо запланировать внесение изменений по выявленным недоработкам и недостаткам. ❓ Зачем файлик в маркдауне? Этот файл позволит вам в полном объёме сохранить ваш обсуждённый план, с проработанными деталями. Плюс вы можете сами изучить не краткое резюме плана от агента, а подробный перечень действий, и скорректировать при необходимости (что, впрочем, довольно редко). ❓ почему файл плана первым пунктом? Потому что после старта изменений агент все постепенно забудет, а вам нужно сохранить полный качественный план! Если вы этого не сделаете сразу - считайте что половину качества планирования вы слили. Продолжение тут: https://t.me/deksden_notes/90

Хабр: Claude Code - субагенты Не прошло и недели, как хабр расчехлился с модерацией статьи! Сабж тут: https://habr.com/ru/articles/946748/ Примерно то же самое что было в канале, но немножко причесано #post @deksden_notes

☝️ ХоЗАЯке на заметку простите за каламбур, просто пост про ЗАЮ: z.ai Как подключить модель GLM в Клод Код и получить (по бенчам) модель на уровне Соннет 4 с ценой $3/$15 в месяц с приличными лимитами! Даже без акции это будет $30. Весьма интересно, чтобы попробовать - я вот собираюсь затестить попозже. * про модельки тут: https://z.ai/model-api * про подписку тут: https://docs.z.ai/devpack/overview * про использование с СС тут: https://docs.z.ai/devpack/tool/claude Пишите в чат, кто попробует - любопытно же! #post @deksden_notes

🎁 Jules опять немного обновился Теперь картинки можно отправлять прямо со стартовой задачей, а значит, например, легче ставить задачи на дороботку фронта и в целом любые UI вопросы. Полезная мелочь, но не могу не отметить уверенный темп развития продукта https://jules.google/docs/changelog/ #news @deksden_notes

⚒️ Codex : небольшие ремарки На данный момент мой основной рабочий инструмент, который работает 24/7 (ну - не совсем, но все таки), и в пару потоков - это СС. Но я всегда смотрю альтернативные инструмены. 🟢 После выхода GPT-5 таким инструментом стал Codex CLI. Мало того, что он довольно бодро развивается, так ещё и модель, которая работает в нем - очень умная. GPT-5-Medium / High Thinking отлично справляется с вопросам, на мой взгляд, заметно превосходя Opus 4.1. Но тулинг вокруг модели пока довольно сырой! Мало того что не хватает почти всего, что есть в СС: сессии - да, продолжить чат нельзя, нет субагентов, нет /memory команды, нет /context, нет statusline / ccusage. В общем - как жить - хз. ⚠️ Неожиданно возникли определённые вопросы с агентским поведением модели: упорно "тупит" при запуске моего оркестратора, запуская его в синхронном режиме, и ожидая ответа. Где то - умная, но тут - почему не в фоне? Как вы понимаете, "переключить" как в СС в фоновый режим через Ctrl+B в кодексе нельзя, такой фишки нету! Проблемы, как мне кажется, в недостаточно отладенных системных промптах кодекса и описании тулов. Клод тут с начала года "полирует" тему регулярно. Например, чтобы избежать подобных кейсов в СС запуск bash сопровождается таймаутом в 2 минуты, так что через 2 минуты процесс продолжится. Сколько процесс может висеть в кодексе - я не проверял, но точно больше 2 минут! ▶️ На мой взгляд - кодекс штука интересная, но в данный момент выглядит как нишевая, для решения "сложных" задач или отдельных тем. Например, пускать кодекс как MCP сервер с Cc, для генерации "второго мнения". Я её попробую к ещё к фронтэнду подпустить - посмотрим как там оно, ещё и с playwright MCP работать будет. В общем, текущая премиум подписка остаётся за клодом. #post @deksden_notes

📝 Память AI SWE Tools Закончим обзор китайскими инструментами - там тоже есть достойные варианты! ... Trae и Quoder. 6️⃣ Trae Интересен инновационным режимом SOLO, но сегодня мы про систему памяти, которая очень базовая: * скоуп - правила пользователя (settings - rules - user rules) * правила проекта: .trae/rules/, пользовательские md файлы * frontmatter не применяется, настройки скоупа нет; в целом - это все что можно сказать. Довольно скудно! прочитать тут: https://docs.trae.ai/ide/rules-for-ai?_lang=en 6️⃣ Qoder ‼️ Один из самых интересных релизов последнего времени. Релиз упакован рядом иновационных и интересных фишек: - repoWiki : огромный подробный автоматически создаваемый/обновляемый wiki по проекту, - quest mode : их тейк про spec-driven development, - быстрый code search : graph + векторный поиск (возможно, задействуют и repowiki) - несколько моментов про long-term memory, про что мы и поговорим подробнее Система памяти похожа на Cursor: * .qoder/rules папки для правил * скоуп - проект * есть тюнинг скоупа правил: manual / agent decides / glob pattern matching files / always * есть система памяти: memory ▶️ Агент автоматически хранит структурированную информацию о проекте: * персональные предпочтения (Personal Preferences): стиль кода, подходы к разработке (test-forst development), пользовательские правила; * извлечённый опыт (!!!): решения для повторяющихся ошибок, общие шаги для решения проблем, инстуркции по сборке и развёртыванию проекта (build/deploy), извлечённые уроки из проведённых рефакторингов и исправления багов (lessons learned) * база знаний проекта : архитектура/структура, техстек, api/subsystems integration ▶️ Агент использует следующие источники для информации: - чаты с пользователем: извлекаем явные указания и неявные паттерны - логи работы агента: анализируем итоги работы для понимания что работает и что не работает; - структура проекта и документация: извлечение семантической карты проекта ▶️ Для поддержания памяти в актуальном состоянии, агент производит оценку всех записанных фактов по следующим критериям (критерии весьма интересны, кмк): - насколько релевантны записи для будущих задач - точность и актуальность информации - влияние на выполнение задач Оценка производится после выполнения любой задачи, заметки которые имеют низку оценку помечаются к удалению из актуальной памяти. ▶️ Помимо этого, агент регулярно производит "ревизию" системы памяти: - дедупликация: объединение дублирующейся/пересекающейся информации - устранение конфликтов: устраняются выявленные противоречия в записях - механизм "забывания": убираем нерелевантную или устаревшую информацию, основываясь на частоте использования и актуальности 🟢 Таким образом, агент используют следующий цикл в работе с памятью: - извлечение: поиск в памяти необходимых фактов для контекста задачи - использование: выполнение задачи с использованием сформированного контекста - анализ: извлечение инсайтов/итогов выполнения задачи - оценка: качества и полезности новых "воспоминаний" - ревизия: цикл "обслуживания" памяти, рассмотрели чуть выше. Написано в блогах крайне интересно, что уже очень здорово - идеи реально инновационные и ранее не встречавшиеся в готовых продуктах. Как работает с реальными проектами - пока не понятно, надо пробовать. Почитать подробнее: * блог - https://qoder.com/blog * документация, rules: https://docs.qoder.com/user-guide/rules * memory: https://docs.qoder.com/user-guide/chat/memory #post @deksden_notes