Начинаем, друзья - https://www.youtube.com/watch?v=lbsBHC5BR8I

Самый важный этап агентной разработки - уточнение требований и проработка спецификации

Знаете какой челлендж агентной разработки пока толком не решён? И на каком этапе наша роль как инженеров все ещё критически важна? Этап планирования изменений и принятия ключевых решений. В этом месте вы можете сказать - так есть же SDD, чем тебе не решение? И действительно, уже существует множество фреймворков, призванных помочь в проработке спеки: open spec, BMAD, GSD, GitHub spec kit и т. д., но проблема этих фреймворков во-первых, в качестве уточняющих вопросов, во-вторых в количестве этих вопросов - их либо слишком много, либо нет вообще. Так вот, когда человек на вход агенту отдает какую-то хотелку, для хорошего агента ключевая задача на этом этапе - это не код сгенерировать, а на основе граундинга контекста проекта (бизнесового, продуктового и технического) правильно принять ключевые решения - так, чтобы найти тот самый оптимум, который и задачу решит в приемлемый срок желательно без багов (в конце концов, временные затраты на тестирование пока никто не отменял) и не умножит тех. долг до big ball of mud, в котором каждое новое изменение что-то ломает, а каждый новый фикс этого нарушает стабильность вообще в другом месте - это, к слову, тот самый лимит, в который упёрлась Opus 4.6 со своим роем агентов при попытке создать C Compiler.

Соответственно, чем сложнее и масштабнее система, тем важнее именно этот этап проработки спеки.
И вот здесь важно, что от агента требуется именно помочь оператору в принятии ключевых оптимальных решений - я убежден, что это и есть главная цель SDD. Поэтому, хороший SDD фреймворк - это, прежде всего, операционная система анализа и принятия решений и, в итоге, основа любой зрелой системы агентной разработки. Особенно в компаниях, где профессионально разрабатывают софт.
Причем это работает на всех уровнях - от доработки PRD и UX до архитектурных и технических решений.

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

Сегодня в 13:00 по МСК мы проводим митап как раз на тему системного мышления и его применения в SDD - Иван Закутный (@neuralstack) расскажет нам про FPF (First Principle Framework) операционную систему мышления для LLM и как он на основе FPF сделал обвязку для Claude Code, набравшую более 1000 звёзд на GitHub.

Добавляйте встречу в календарь, чтобы не пропустить: https://luma.com/z0hnbsnl

Мы Начинаем митап по FPF и Spec Driven Dev - https://www.youtube.com/watch?v=brDGV_btDJY

Сегодня выступаю у Саши Кугушева в подкасте DotNet and more - будем обсуждать средний и продвинутый уровень Agentic Engineering.
Формат там свободный, так что приходите со своими вопросами.

Всем привет!

Продолжаем строить матрицу компетенции ИИ программиста и не только

ВНИМАНИЕ, ВЫХОДИМ РАНЬШЕ ОБЫЧНОГО!
Сегодня онлайн в 15:00 CEST (Сербия), 16:00 EEST (Кипр), 17:00 MSK (СПб)

YouTube: https://youtube.com/live/coA1Y5gpbBE
Twitch: https://www.twitch.tv/dotnetmore

Митап с Сергеем Барановым про LLM в архитектуре IT решений

Как вы поняли, на стримы мы подсели плотно :)
Очень интересные гости у нас. Почти в мой день рождения к нам на канал прийдет в гости Сергей Баранов @blog_sb - опытный IT архитектор, консультант и эксперт по DDD, довольно известных деятель в архитектурных кругах. Собственно, говорить будем о том, что там с нашей любимой ИИшкой в работе архитектора и вообще распросим Сергея о том, как он использует ИИ и что он думает про SDD, будущее разработки и архитектуры.
Небольшой пост из канал Сергея по мотивам нашей подготовки: https://t.me/blog_sb/716

Выходим в прямом эфире 1-го апреля в 11:00 по МСК, в 13:00 по Алматы и в 8:00 по UTC.

Регистрация на событие по ссылке: https://luma.com/k4uvyuvq

Начинаем встречу с Сергеем
https://www.youtube.com/watch?v=Dxb0OoeSMrI

Митап с Валерой Ковальским про SGR, GraphRAG по коду и воркфлоу Валеры

Ну, в AI индустрии Валеру не знает, наверно, только ленивый. Но на всякий случай:

- Head of AI Engineering, автор канала @neuraldeep
- Популяризатор SGR подхода (Scheme-Guided Reasoning) и автор популярного фреймворка-реализации SGR https://github.com/vamplabAI/sgr-agent-core (1100+ звезд!)
- Автор 10+ опенсорс проектов, включая ру базу скиллов https://neuraldeep.ru
- Наверное, один из наиболее востребованных экспертов по RAG и агентным системам в СНГ.

Что будет на митапе?
В прямом эфире создадим агента по SGR, который собирает связи по кодовой базе для последующего создания GraphRAG. Но самое интересное, что агента мы будем кодить вместе с Валерой по его воркфлоу (а значит, мы узнаем почему в узких кругах Валеру называют "120 минут").

Встречаемся сегодня в 14:00 по МСК онлайн.
Ссылка на встречу: https://luma.com/dheyf8hl

Мы в эфире с Валерой: https://www.youtube.com/watch?v=cMRo2CYrRNQ

Не покупайте дорогие подписки на топовые модели (пост для вашего работодателя)

Иначе вы рискуете затерять ваших разработчиков в исследованиях.

Инсайт такой - подписки уровня 200$/mo обычно легко позволяют, скажем так, в параллель с основными задачами запускать разного рода эксперименты - когда агент не просто выводит гипотезы, но и запускает проверку каждой гипотезы в поисках наиболее оптимального решения - это может быть как определение оптимального алгоритма (ну например, стратегии чанкинга), так и поиск оптимального промпта/конфигурации системы. А в связке с субагентами это может быть особенно эффективным.

Например, в апреле мы апдейтнулись с Claude Max 100$ до Claude Max 200$ (это х4 лимиты от 100) и это позволило мне свободно провести эксперименты по код ревью с новыми моделями (их сейчас вышло как никогда много) и поймать инсайт, что связка из 8 по-своему сфокусированных Qwen 3.6 Plus + DeepSeek 4 Flash ловят больше проблем при код ревью, чем одиночный Opus 4.7 - это при том, что часть проблем в нашем бенчмарке синьерного и даже экспертного уровня. А это, на секундочку, получается минимум 2-х кратная экономия. Но про этот кейс отдельно расскажу.

Вообще, AI разработка прямо изобилует экспериментами - потому, что никто не знает как правильно. Больше того, то, что было "правильно" вчера, сегодня уже неактуально и замещено чем-то более эффективным (как в примере с ревью). Именно поэтому в этом дивном новом AI-мире разработчикам важно не только бюджет выделять на эксперименты, но и время - в принципе, компании смело могут легитимизировать 20-30% рабочего времени инженеров на эксперименты с AI - это, опять же, потому что даже один такой успешный эксперимент, может принести пользы больше, чем месяц усердной работы (здесь можно отметить, например, эксперименты по улучшению пайплайна тестов и верификации изменений, которые можно проводить бесконечно), и совсем хорошо когда инженеры хотя бы пару раз в месяц собираются на выделенный звонок и делятся находками и результатами своих экспериментов.

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

—

@ai_driven

Мок-собеседование Agentic Software Engineer (AI Automation)

Мне все чаще попадаются новости о том, что кол-во кандидатов на программистские вакансии достигло какого-то аномального пика и этот разрыв продолжает расти, а востребованность обычных классических разработчиков стремительно падает. С другой стороны, появилась совершенно новая должность Agentic Software Engineer - это человек, который перестраивает разработку, да и весь SDLC на AI рельсы. Еще эта должность называется AI Automation Engineer, Agentic Advocate и т. д. - суть одна. Поскольку позиция новая, пока еще не очень понятно как на нее интервьюировать. К счастью, у Коли (автор канал @ai_grably, CTO и консультант) это понимание есть, поэтому мы решили провести первое публичное мок-интервью в рунете на эту позицию. Как обычно, проводим в формате стрима, онлайн.
А пока мы все дружно ждем это важное событие, вот интересное чтиво о том, как меняет подходу к интервью инженеров в AI-эпоху: https://sierra.ai/blog/the-ai-native-interview

Дата и время: 30 апреля 15:00 МСК, 17:00 Алматы, 13:00 CET.
Длительность: 1.5 часа.
Регистрация: https://luma.com/mm9dv0im

@ai_driven

Стрим про кодинг-интервью в эпоху агентов

Классические форматы найма разработчиков в свете AI устаревают на глазах.
Задачки с условного литкода оценивают навык, который в реальной работе и так редко использовался, да и сам процесс подготовки и проведения таких интервью давно уже превратился в специфический ритуал.

Так что некоторые компании уже начали в пилотном режиме проводить AI-assisted coding interview, где кандидату выдаётся агент и задача по работе с реальной кодовой базой.

Раньше мы чаще проверяли кандидата на то, может ли он писать код, а теперь всё больше становится интересно другое: как он декомпозирует задачу, ставит её агенту; как отличает хорошее решение от галлюцинаций; ревьюит результат и объясняет, почему сделано именно так.

О чём хочется поговорить:
● какие форматы устаревают и какие становятся важнее;
● какие из них теперь покрываются ИИшкой;
● какие задачи в принципе подходят для такого формата;
● какого агента давать кандидату (hot take, что не очень умного :));
● уровни и критерии оценки.

Короче, сегодня стихийно соберемся вместе:
● Коля с канала AI и грабли
● Родион - AI-Driven Development. Родион Мостовой
● Максим - Этихлид

...и поразгоняем на эту тему.

1 мая (сегодня), 15:00 МСК: https://luma.com/r3hyapoy

Кидайте ваши вопросы в комменты - постараемся и на них ответить на стриме.

#ai #hiring #interview

Улучшаем понимание контекста через субагентов

Собственно, исследование кода (или чего угодно другого) через субагентов на сегодня один из наиболее полезных кейсов применения этих самых субагентов - для этих целей, кстати, в Claude Code есть встроенные агенты, в т. ч. Explore.

Как правило, Claude Code (а с недавних пор еще и Codex) перед тем, как перейти к выполнению задачи запускает одного Explore субагента для сбора контекста. Но его явно бывает недостаточно для полноценного сбора, особенно на больших кодовых базах. К счастью, Claude Code позволяет прямо в запросе указать "запусти 3 сфокусированных субагента для глубого изучения контекста по задаче".

Explore агент на Sonnet
А если вы понимаете, что вопрос действительно сложный (запутанный), то можно просто попросить агента "запустить explore субагентов на Sonnet" и он так и сделает.

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

—

Напомню, что для комфортной работы с агентами в больших кодовых базах могу горячо рекомендовать наш продукт CodeAlive - он дает агентам суперсилу использовать очень качественный семантический поиск, с помощью которого в течение пары сотен мс. агент находит 90%+ релевантной информации, затем быстро добирает то, чего не хватает - экономит и время и токены. Мы, кстати, обновили и MCP и скиллы, а еще вот-вот выкатим обновленный чатик с новым супер-агентом, который быстро и глубоко отвечает даже на самые сложные вопросы по кодовым базам на 1М+ строк кода и по сотням репозиториев сразу - для компаний с тоннами кода и документации просто бомбическая штука. Скорее всего, отдельный стрим сделаем на эту тему чуть позже.

@ai_driven

Safety Hooks моей мечты

Наконец-то сделал хуки моей мечты - достаточно безопасные и практически без false-positive. Хуки вымученные, эволюционировали на граблях можно сказать.

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

Соответственно, когда хуков нет совсем или их мало, безопасность хромает - агент может уронить базу, сделать rm rf и тд, а если хуков слишком много , то... вы привыкаете клацать Enter на Allow, уже даже не читая о чем вообще сыр-бор. Поэтому, нужен тонкий баланс и хуками важно закрывать только действительно деструктивные, необратимые или критические действия.

Ну, и сразу второй нюанс - для блоков я предпочитаю использовать ask хуки вместо блокирующих, т. к. агенты нынче слишком умные и получив блокирующий хук, наверняка найдет способ обойти ограничение (особенно если прилетел какой-нибудь prompt-injection), тк хуки обычно весьма примитивны.

Короче-говоря, с учетом всех этих нюансов я написал свои opiniated-хуки, которые сам использую, они максимально сбалансированны по allow/ask с практически нулевым false positive - благодаря парсингу AST, а не regex'ам, которые обычно в хуках. Частично в основе лежит claude-code-safety-net (спасибо Рефату за наводку) весьма сильно переработанный и дополненный.

Внутри:
1. rm — rm/unlink/shred вне cwd, по /etc, $HOME; через sudo, xargs, find -delete, pipe-to-shell.
2. infra — kubectl, docker, terraform, helm, gcp.
3. db — DROP/TRUNCATE/DELETE через psql/mysql; redis-cli FLUSHALL/SHUTDOWN, supabase.
4. paas — Railway, Fly, Heroku, Vercel, Netlify с destructive-глаголами (PocketOS-класс).
5. git — reset --hard, clean -fd, checkout . / restore ., branch -D, stash drop/clear, push -f, push --delete.

Ссылка на репо: https://github.com/CodeAlive-AI/ai-driven-development/tree/main/hooks/balanced-safety-hooks - звезды как обычно приветствуются.

Быстро ставятся так: curl -fsSL https://raw.githubusercontent.com/CodeAlive-AI/ai-driven-development/main/hooks/balanced-safety-hooks/install-prebuilt.sh | sh

Из особенностей - написаны хуки на Go, поэтому выполняются буквально за несколько мс. Ну, и каждый, может поправить их под свои нужды, перекомпилячив бинарник. Еще из интересного - большинство хуков покрыты тестами.

Кстати, для простого и корректного управления своими хуками у меня есть отдельный скилл hooks-management, который теперь поддерживает Claude Code, Codex и OpenCode.

@ai_driven - AI-Driven Development

В это воскресенье в 18:00 МСК, 20:00 по Алматы поговорим с ребятами о том, как экономить на LLMках. Приходите. И пишите свои вопросы.

Я забыл попросить вопросы к стриму "Каждый токен на счету"! 🙈

Задайте их, пожалуйста, в комментариях к этому посту.

Кстати, Сергей, один из участников нашего стрима, опубликовал целую серию статей на Хабре про prefix_cache:

1. Экономика кэширования и особенности провайдеров

2. Самые частые анти-паттерны

3. Кэш в AI-агентах

Материалы – огонь. Если прочитать их до стрима, то просмотр станет ещё интереснее.

На стриме на практике проверим, как учёт особенностей prefix_cache влияет на расход токенов.

Добавить событие в календарь

Вопросы для стрима – в комментарии 😊

Уже видели, что Антропики переписали bun с Zig на Rust? Тут Никита Соболев интересный разбор этой истории сделал.
Вообще, мое почтение ребятам из Bun за смелость такое вмердживать - в PR'е на секундочку +1 009 257 строк и 6000+ коммитов. Я-то думал мои вымученные PR'ы на 10к+ строк - это много, а тут вон чего люди делают.
Интересно будет почитать блогпост про этот процесс миграции - ждем.

ИИ переписал Bun с Zig на Rust

PR: https://github.com/oven-sh/bun/pull/30412 (он настолько большой, что гитхаб его не открывает у меня)

Последние несколько дней в чате очень плотно обсуждали последнюю ИИ новость.

Один из альтернативных JS рантаймов bun полность переписали с zig на #rust.
Переписывали, конечно же, используя исключительно агентов и ИИ (от компании Anthropic) .
На все про все ушло 10 дней, тесты прошли, перформанс остался такой же.

Звучит красиво? Красиво.

Таймлайн истории

1. 2 декабря 2025 года Anthropic покупает bun и всю команду: https://bun.com/blog/bun-joins-anthropic
2. Команда Zig известна своим "No AI Slop" policy (прямо как django-modern-rest), некоторые люди сразу предсказывали конфликт интересов между Bun + Anthropic и Zig
3. 26 апреля 2026 года, команда bun форкает zig и добавляет туда поддержку параллельного семантического анализа https://x.com/bunjavascript/status/2048427636414923250
4. 9 мая открывается тот самый PR
5. 14 мая он успешно смерджен

Важные детали

А вот тут начинается интересное.

- Для начала авторы Zig объяснили, что подход форка с семаналом некорректный, и что они сами работают над данной фичей, скоро она будет доступна: https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilation-times/15183/19
- Билды получились недетерминированные, о чем им и рассказала кор-команда. Тогда форк пришлось закопать, видимо

Теперь посмотрим на качество PR.

- Качество кода там примерно вот такое: https://github.com/oven-sh/bun/commit/d144fa6e20ab65d55add82ef3241609dcbb04cdc (то есть - никакое)
- Файлы в нем даже были неотформатированы встроенным cargo fmt, что делается буквально в каждом Rust проекте: https://github.com/oven-sh/bun/pull/30695
- Ревью не было, потому что внутри PRа +1 009 257, -4 024 и 6000+ коммитов
- unsafe в коде встречает 10487 раз (да, там много ffi, но все равно). Для сравнения в uv (кода правда меньше в 2 раза) - всего 73 раза
- "Скорость работы осталось такой же" - довольно странный тезис, учитывая что zig и rust оба генерят код через LLVM, часто практически идентичный, заслуги ИИ здесь нет

Выводы

- Прикольно, что такое вообще можно сделать (с неограниченными токенами)
- Как теперь bun будет владеть своей базой кода, кто сможет в ней разобраться и что-то пофиксить - вопрос открытый
- Какой смысл во всем действии (кроме очевидного маркетинга) - вопрос открытый
- Брать ли теперь bun в прод? Конечно нет

Обсуждение: что вы думаете по данному вопросу? Стали бы использовать bun у себя в проекте в новом виде?

| Поддержать | YouTube | GitHub | Чат |

Радость же для любитей Claude Code. Установил себе.