И... тут дядя Боб свой опенсорсный оркестратор зарезил с акцентом на локальные модели: https://github.com/unclebob/swarm-forge
Интересно, что написан он на Clojure... А файлы CLAUDE.md/AGENTS.md отсутствуют, так что не знаю что и думать)
Еще из забавного - мне казалось, что может быть интересным покопаться в его промптах. И там действииельно есть такая строка Prefer the Babashka APS tools for gherkin-parser - "бабашка"?? какая-то секретная техника от дедушки дядюшки Боба подумал я... но нет, просто популярный интерпретатор для Clojure. Вот так вот, век живи, век учись :)

А если серьезно, то даже в том же промпте Боб Мартин упомянает, к примеру, crap4clj - а это как раз нишевая, но очень интересная метрика от Google, которая пытается <объективно> оценить качество кода, на основе его цикломатической сложности и % покрытия тестами - я, кстати, давно хотел посвятить этой метрике отдельный пост и прикольно, что дядюшка эту метрику тоже использует - учитесь, вайбкодеры ;))

А сворм этот если кто попробует - расскажите. Пока выглядит скорее загадочно.

@ai_driven

Друзья, через пол часа стартуем стрим с Иваном Закутным, будем говорить про ошибки Spec-Driven Development - у Ивана очень интересный практический опыт на эту тему.

Стартуем в 13:30 МСК, 15:30 по Алматы: https://youtube.com/live/N01bvw44P60?feature=share

"Исходи из того, что пьяный пользователь использует наш продукт"

Вы же знаете как я люблю UX (понятность и удобство продукта)? В общем, небольшой, но очень мощный пет-проект сейчас пилю для безопасного хранения API ключей и прочих секретов, там немало GUI/CUI и в очередной раз сталкиваюсь с тем, что агент делает плохой UX, его постоянно приходится поправлять. Добавил вот такую строчку в AGENTS.md, чтобы поправлять его не так часто:

For every product-facing change, think through the "drunk user" path: a tired, distracted, impatient user should still understand what just happened, what is safe to click next, and whether the system is waiting, broken, or done. Avoid ambiguous labels, hidden toggles, silent waits, stale loading states, and choices that require remembering implementation details. Prefer one explicit next best action.

Т. е. "При каждом изменении продукта, продумывай флоу с точки зрения пьяного пользователя". Понятно, что не панацея, но точно сильно лучше, чем ничего. Увы, так получается, что программисты сами часто не понимают как сделать хороший UX/DX. И вообще, мало кто понимает. А лучшим UX-чекапом будет наблюдение за вашим целевым пользователем-человеком за тем, как он использует ваш продукт с нуля без всяких объяснений.
И повторюсь, что я искренне верю, что будь в приложениях продуманный UX, люди в мире был бы немного счастливее :)

P.S. Много о чем есть рассказать на тему безопасности в эпоху агентной разработки - напишите в комментариях какие конкретно сабтопики для вас наиболее актуальны. И напомню про свои хуки безопасности для агентов, которыми делился недавно.

@ai_driven

Похоже, что последнее обновление Codex App врубило какую-то дико назойливую песочницу, которая задает кучу лишних вопросов когда не надо, да еще и с ходу не отключается.
В общем, нашел как отключить полностью.
В файле ~/.codex/config.toml нужно указать:

default_permissions = ":danger-full-access"
approval_policy = "never"

Как обычно, используем осторожно. Обязательно в связке с собственными хуками типа моих.

@ai_driven

Голосовой ввод + параллельная работа агентов

Вы же уже используете голосовой ввод? И агентами параллельными наверняка работаете над одним проектом. Там есть тонкая грань между worktrees и no worktrees - я обычно использую ворктри при параллельной работе над большими фичами, а если же ведется точечная работа не очень большими ченжсетами, то часто достаточно правильно проинструктировать агентов.
В общем, вот неплохой сетап для вашего AGENTS.md / CLAUDE.md при AI-Native разработке, который должен упростить жизнь вам и вашим агентам:

## Workflow

- Parallel agent sessions may work on this project at the same time. Treat unexpected file changes as legitimate work by another correctly running agent unless there is clear evidence otherwise. Do not clean, revert, overwrite, reformat, or "fix" changes you did not make. If your work conflicts with concurrent changes, pause briefly, re-read the affected files and `git status`, then retry with a smaller, targeted change that preserves the other agent's work. If the conflict still cannot be resolved safely, stop and explain the conflict instead of forcing your version.
- Tasks in this project are often dictated by voice and transcribed through ASR, so task text may contain recognition errors, especially in technical terminology, names, commands, and product terms. When the intended meaning is clear from repository and club-agent context, infer the likely intended term and proceed. When the ambiguity materially affects the implementation or safety of the work, ask the user for a concise clarification before continuing.
- At the end of every agent session, commit completed work to the local Git repository.
- Do not push commits unless the user explicitly asks for or approves a push.

Это, конечно, чисто под AI-native сетап. Главное тут то, чтобы агенты уважали работу друг друга и никогда не портили ее, и то, чтобы работа ведется через голосовой ввод, в котором могут возникать ошибки - чтобы агент либо догадывался если очевидно, либо спрашивал вас в противном случае.

Upd: Для ASR использую Codex. Он с недавних пор умеет на уровне ОС тоже работать, а задачи на русском языке надиктовываю.

@ai_driven

Если вы по каким-то причинам еще не вайбкодите, но зачем-то читаете меня, то объявляю last call на третий поток курса по вкатыванию в вайб-кодинг.

Стартуем 22 июня, уже в этот понедельник. Инструменты развиваются стремительно, поэтому собрал офигенную обновленную программу под современные реалии.

Расскажу и покажу, как делать ботов, сайты, мобильные приложения.
Помогу с настройкий и покупкой необходимых инструментов.
Рассказываю не просто «что и как», но еще и «почему», короче, до кучи это экспресс-курс по вкатыванию в архитектуру современного IT

Курс веду лично, так что вы все узнаете непосредственно от меня, а не в десятом перессказе 🙂

Отзывы и подробную программу смотрите тут: https://glebkudr.com/courses/vibecoding

Скидка 10% по промокоду GLEB3 💵

Тут друг нашего канала Глеб Кудрявцев запускает новый поток по вайбкодингу. Я отправил на него своего брата (он у меня композитор, на секундочку!), расскажу вам потом про результаты по итогу. Может, даже стрим с ним сделаем про его путь (надеюсь не забросит).

https://t.me/gleb_pro_ai/625

Вижу Сергея Теплякова - ставлю лайк. Сергей - один из самых хардкорных чуваков из мира .NET (один только его доклад про отладку асинхронного кода чего стоит) и довольно известный деятель в индустрии. Он автор книги "Шаблоны проектирования на C#", которая в до ИИ эпоху у меня была настольной. А ещё, Сергей всегда очень интересно рассказывает. В общем, не могу с вами не поделиться. За ИИшку и всякие солиды ребята тоже поговорили.
Спасибо Кириллу за такого крутого гостя: https://t.me/orgprog/489

По теме выпуска поделюсь сразу своими мыслями. Я раньше с большим интересом следил за обновлениями своего, можно сказать, родного языка C# - кайфовал когда появился NRT (nullable ссылочные типы, нынче это база во многих современных ЯП), радовался всяким switch expression, pattern matching и тд и очень ждал появления поддержки discriminated union, (которого, кстати, так до сих пор и нет). Так вот, для меня лично, с появлением и развитием агентной разработки, практически все вопросы фич языка потеряли смысл по очевидной причине - 99% я теперь пишу на русском или на английском языке. Больше того, я убежден, что, как минимум, для условных MVP уже можно в принципе выбирать тот ЯП, который лучше подходит под решение конкретной задачи - я сам уже успешно пишу программы на Python, TypeScript, Go и даже на Swift когда это нужно. Мне, кстати, представляется, что в большинстве случаев, когда мы говорим о бытовом софте с веб интерфейсом: full stack TypeScript + какой-нибудь ultracite может быть лучшим выбором по умолчанию. Вот такие мысли у меня.
А что вы думаете про новые фичи в ЯП и про возможность выбрать ЯП под задачу?

@ai_driven

Уря! Выпуск про .net уже доступен для просмотра. И все равно мы там в середине скатились в обсуждение clean code, solid и потом заели все агентами 🙂 https://www.youtube.com/watch?v=7uj6IxxW13w

Альтернативные ссылки: Аудио | vk

OS Deep Cleaner теперь доступен для Windows.

Напомню, что это безопасная и мега удобная чистилка ОС, реализованная в виде скилла для агента - он сначала анализирует систему, находит как мусор/кеш и тд, так и большие файлы, затем позволяет пользователю выбрать что убрать, а что оставить. Без подтверждения ничего не удаляет, а каждый кандидата на удаление поясняет.

Версия для Windows: https://github.com/CodeAlive-AI/ai-driven-development/tree/main/skills/maintaining-windows-health

Версия для macOS: https://github.com/CodeAlive-AI/ai-driven-development/tree/main/skills/maintaining-macos-health

1М контекстное окно - прорыв или фикция?

Context Arena забенчмаркали стойкость контекста для GLM 5.2 и Opus 4.8 - значит, это хороший повод нам вспомнить про контекстную инженерию.
На бенчмарке отчетливо видна существенная просадка внимательности моделей на 512к контексте: в среднем, почти в 2 раза в сравнении с 64к контекстом и примерно в 1.5 раз в сравнении с 128к контекстом - грубо говоря, для нас с вами это означает то, что на 512к контексте агент будет терять в полтора раза больше деталей, чем на при 128к заполненности. Для открытых моделей проблема потери контекста особенно актуальна, поэтому практический вывод такой, что по-хорошему, с ними стоит держать заполненность контекстного окна не выше 128к, а лучше даже меньше - ни о каком 1М, конечно, и речи не идет, там просадка будет колоссальной. Кстати, у моделей Kimi K2.6 и, тем более, Minimax M3 дела обстоят еще хуже.
Что еще? Открыв закрытых моделей на большом контексте от открытых все еще впечатляет, хоть уже и не такой драматичный - спасибо DeepSeek за DeepSeek Sparse Attention, которую в GLM-5.2 развили через IndexShare. Кстати, о GLM 5.2 - как видно, моделька действительно на удивление успешная в т. ч. на больших контекстах. Opus 4.8 идет рядышком с GPT 5.5, но последняя все равно сильнее, особенно на совсем больших контекстах. На этом месте вспоминаем интересную деталь - в Codex App по дефолту контекстное окно для GPT 5.5 все еще 256к - то есть, по сути, точность всегда остается где-то на уровне 75%+- (по MRCRv2), а благодаря превосходному алгоритму компактизации, команде Codex удается сохранить все действительно важное так, что эти компактизации обычно и не заметны вовсе - то есть, конкретно в случае с Codex проблему контекстной инженерии ребята здорово решили на уровне модели и на уровне Harness (обвязки), в то время, как Claude Code в этом аспекте требует чуть больше ручной работы - модель на 1M контекста там включается прямо в выпадающем списке (велик соблазн ее включить), но кажется, что простой обыватель зачастую не очень понимает, что переключение на эту модель потребует от него ручного управления контекстом - как только контекст переваливает за условные 200к, начинается зона риска, в которой нужно либо переходить в новый чат, либо, хотя бы, вызывать компактизацию - что и приходилось делать. Что уж говорить, что пользователям открытых моделей за загрузкой контекста все еще стоит следить куда пристальнее. Короче, в 2026-м контекстную инженерию (в которую входит контроль % заполнения контекстного окна) пока никто не отменял - чем больше забит контекст, тем сильнее приходится надеятся на удачу.
И, конечно, не забываем про контроль AGENTS.md, скиллов, MCP, progressive disclosure и т. д. - тоже все составляющие context engineering, с открытыми моделями все это становится еще важнее.

Кстати, современная версия Context Arena прогоняет бенчмарк MRCRv2 от Google DeepMind (GDM-MRCRv2).

Paper про MRCRv2 (Michelangelo)
Датасет MRCRv2

А как вы менеджите контекст? Обращаете ли внимание на % заполнения? Наблюдаете ли просадки в качестве output модели на больших контекстах?

@ai_driven

/goal или вайб-кодинг по ключ

Тут наш друг Костя Доронин хороший кейс с /goal описал про, фактически, создание приложений "под ключ", когда агент по подробному плану может работать сутки и более: https://t.me/kdoronin_blog/1312

Но там есть пара важнейших нюансов, которые я не смог не прокоментировать, продублирую:
При всей моей любви к GPT 5.5 Pro - это вообще не панацея. Я довольно часто использую эту модель для разных задач, в т. ч. для V0 примерно как Костя описал и хочу сказать, что GPT 5.5 Pro это все еще совсем не магия. В кейсах "приложение под ключ с нуля" именно этап интервью критически важен - чем оно подробнее тем лучше результат на выходе. И в целом, такой подход довольно рискованный. Даже Pro модель часто такую дичь может напланировать, что можно вообще приложение свое не узнать после этих 26-ти часов. И, конечно, бизнесовый контекст в этом случае очень важно давать - для кого приложение, нефункциональные требования (профиль нагрузки, например), иначе может как переусложнить (часто) так и упростить не там, где надо.
Ну и UX лучше отдельно прорабатывать - а то, вроде, все красиво делает и функционально, но дико неудобно и совершенно непонятно для пользователя, который видит приложение в первый раз. Поэтому по UX прям отдельно интервью лучше провести, а по-хорошему, сначала макеты посмотреть.

Кстати, раз уж про инженерию с нуля заговорили, расскажу про свой мини-проектик новый, вайб стек называется. Короч, помимо бизнесовых требований, чтобы разработка и сопровождение шли как гладко, довольно важно еще и с технологиями оптимальными определиться - собсна, вайб стэк эту проблему и решает, давая очень оптимальные opinionated дефолты: https://github.com/CodeAlive-AI/vibe-stack/
На днях подробнее расскажу подробнее про эту штуку.

@ai_driven