AI-Driven Development. Родион Мостовой

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

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

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

Сегодня в 14:00 МСК продолжаем разбираться в Full-Cycle Agentic Engineering вместе с Денисом @deksden_notes. Сегодня больше будем говорить про практическую часть: * Флоу артефактов: откуда что берется из документов и как собирается * CLI: особенности организации фронтенда для быстрого тестирования * Memory bank: как устроен и как с ним работать * Vertical slices: принципы архитектуры, удобной для агентов * Связка сценариев и UI QA: POM, data-test-id, автотесты * Кросс-эпик сценарии (что бы это ни значило) Стрим проведем в ютубе, ссылка будет ближе к встрече. Событие тут: https://luma.com/904bned9 Запись будет.

🌸 GDG Almaty Spring Meetup уже через 2 дня 11 марта 2026 года в 19:00 мы встречаемся в MOST IT Hub 📍 Алматы, ул. Ходжанова 2/2, БЦ Fortis Это будет весенняя встреча сообщества GDG Almaty — для тех, кто делает технологии, продукты и стартапы. В программе — доклады про: • AI и облачную инфраструктуру • No-code / Low-code и будущее разработки • мобильную разработку и практический опыт инженеров из индустрии Будет много общения, идей и людей, которые строят технологические продукты в регионе. Если вы в Алматы — приходите. Регистрация: https://gdg.community.dev/events/details/google-gdg-almaty-presents-gdg-almaty-spring-meetup/ До встречи 11 марта 🚀 #GDG #Almaty #TechCommunity #Developers #AI #MobileDevelopment #NoCode

Мои друзья из GDG Алматы проводят эту среду проводят митап. Попросили репостнуть, что я с удовольствием делаю. Так что, приходите все желающие, и я тоже постараюсь заглянуть на огонек.

Продолжаем в YoutTube: https://www.youtube.com/watch?v=O3RKuenDtK4

Мы начали! https://us06web.zoom.us/j/87983770169?pwd=1cQDRyHRvUocWPoywjK5aigrKGEfvv.1

Митап: Agentic Engineering полного цикла или как сгенерировать пару десятков тысяч prod-ready кода Друзья, вы тоже замечали, что использовать кодагентов в разработке можно очень по-разному? Кто-то на пару с AI агентом становится эффективнее на 10%, а кто-то на 1000%. Так вот, Денис, наш завтрашний эксперт, явно из второй категории. Уже в этот четверг Денис (автор канала @deksden_notes) покажет нам свой воркфлоу агентной разработки. Из известных мне вайб-кодеров экспертов по агентной разработке, Денис, пожалуй, абсолютный чемпион по расходу токенов - агенты, генерирующие тысячи строк кода в параллель для него совершенная обыденность. Но интереснее всего - это воркфлоу Дениса, а именно все то, что происходит до кодогенерации (спека, планирование) и после нее (верификация, тестирование). На встрече Денис расскажет про свой протокол агентной разработки поделиться наиболее ценными инсайтами из своего воркфлоу. Кстати, свой протокол разработки Денис подробно описал в своем канале (получилось аж 9 постов), поэтому могу смело рекомендовать сие чтиво: https://t.me/deksden_notes/197 Дата и время: 6 марта 16:00 МСК. Ссылка на регистрацию: https://luma.com/e7clxtiw @ai_driven — AI-Driven Development

Внимательно слежу за творчеством Андрея Бреслава и его нового продукта CodeSpeak и интересно, на сколько мы в одну сторону думаем - только на днях я написал о важности тест-системы (верификации изменений), а ребята так же на днях выпустили новую фичу для автоматизации покрытия Python-проекта тестами: https://codespeak.dev/blog/coverage-20260302 Интересно, будем пробовать. Ещё, CodeSpeak умеет генерировать код по спеке и наоборот спеку из кода - в принципе, сейчас и обычные агенты с таким неплохо справляются при должной сноровке, но поскольку Андрей супер-профессионал (создатель языка Kotlin на минуточку), есть высокие шансы, что CodeSpeak сможет выдавать сильно более качественный результат. Постараюсь вытащить Андрея на интервью к нам на канал. А на очереди у меня как раз пост про повышение верифицируемости кодовых баз на Python. Кто уже успел попробовать CodeSpeak - поделитесь фидбеком, очень интересно как это на практике работает, особенно на средних и больших проектах. @ai_driven

Промпт-инжиниринг умер... или нет? Действительно, нынешние модели (reasoning версии, прежде всего) теперь менее капризны и придирчивы к промптингу, но тем не менее все еще остается множество нюансов, которые следует учитывать при создании/отладке промпта. И часть из них совсем неочевидны. Мы в CodeAlive постоянно улучшаем наши промпты и какое-то время назад прямо через промпт сделали файлы, на основе которых генерируется ответ кликабельными (LLM просто оборачивает название файла в ссылку). Сделали, написали тест - все ок. Но через какое-то время мы заметили, что чатик периодически выплёвывает сырые XML-теги прямо в ответ. Пользователь спрашивает про код, а ему в ответе почти рандомно вылетает <repository_links>. Вроде мелочь, но выглядит как баг - надо фиксить. Короче, как вы уже поняли, проблема оказалась в промпте - мы активно используем технику с XML-тегами для структурирования инпута в LLM, и в некоторых местах, когда нужно сослаться на конкретную секцию писали что-то вроде "в секции <smthng> лежат ссылки на репозитории" - так вот, этот нюанс, что мы ссылались именно через тэг и создавал тот неприятный артефакт в ответе от LLM. В принципе, починилось это простым выпиливанием скобок (типа "см. секцию repository_links"). Ну, в общем, чтоб во всех этих техниках, ошибках и мис-юзах не утонуть, я, уже по традиции, соорудил скилл для вашего агента, который умеет как писать новые промпты, так и проводит аудит существующих - техник и ошибок там довольно много всяких с четким описанием юзкейсов, так что в должно быть полезно всем, кто хоть как-то соприкасается с промптингом. Скилл: https://github.com/CodeAlive-AI/prompt-engineering-skill Ставится одной командой: npx skills add CodeAlive-AI/prompt-engineering-skill — Кстати, про автоматизированную отладку и улучшение промптов (мета-промптинг) я уже рассказывал в своем посте - ведь как бы здорово вы не написали промпт, все равно нужно провести ряд экспериментов конкретно на вашей LLM, чтобы убедиться, что все работает корректно. Расскажите в комментариях о ваших факапах с промптингом и неочевидными техниками, которые пришлось применить, чтобы достичь желаемого результата. @ai_driven

Друзья, начинаем митап про AI кодинг в больших проектах через 5 минут. Приходите! "Во всех кионтеатрах всех стран", :)) выбирайте что душе угодно. Ссылка на Зум в Luma: https://luma.com/event/manage/evt-AuFhLXtqp1DlqGi/overview Трансляции: https://www.youtube.com/live/F2cpHNF0Jwg https://rutube.ru/video/private/93a8d325a1a8be7dccc785542fe9a1ae/?p=PEbI8DRIhdVL1CAamGDD6w Важно: Смотреть можно откуда угодно, но вопросы читаем только из Зума.

Тест-система как гарант качества AI-generated кода Я пишу большой гайд о том, как грамотно использовать и получать высококачественный результат от AI-агентов и многоуровневая надежная тест-система там является центральной фигурой, эдакой страховочой сеткой (safety net), гарантирующей корректность кода на выходе. И ключевая идея подхода, который я продвигаю в том, что следует стремиться к такой тест-системе, которая будет ловить 100% проблем и багов еще до того как они попали на прод - т. е., цель тест системы в том, чтобы баги не доходили до прода в принципе. И дальше самое важное - если вдруг какой-то баг дошел до прода - значит, это, прежде всего, баг тест-системы - значит, мы где-то облажались с дизайном тест-системы. И вот тут важно, прошу заметить, что в моей парадигме к "тестам" системы относятся не только классические юнит/интеграционные/e2e тесты, но и PRD assessment, review спеки, review кода и прогон статическим анализатором и визуальные тесты - это все очень важные части тест-системы. Более детально именно составляющие тест-системы я напишу в отдельном посте (хотя, фактически, там описание каждого этапа заслуживает отдельного поста :)) В качестве примера - упрощенный протокол по исправлению бага:

1. Разберись, что сломалось и придумай как это воспроизвести. Что-то непонятно - спроси, не гадай.
2. Воспроизведи баг через тест - если воспроизвести невозможно, явно скажи об этом с обоснованием.
3. Найди настоящую причину. Не симптом, а корень.
4. Придумай грамотный фикс, а не костыль. Если тянет на большой рефакторинг — остановись и спроси меня.
5. Почини с минимальными правками, чтобы не аффектить другие части системы.
6. Запусти тест. Тест зелёный? Соседние тесты не сломались? Идём дальше.
7. Оглянись: раз тест система не поймала эту проблему, значит пласт подобных проблем может быть где-то ещё в проекте - проведи глубокое ревью и найди подобные проблемы.
8. И теперь главное - почему наша тест-система упустила этот баг? Проведи аудит тест системы и найди способом улучшить тест-систему так, чтобы не допустить подобные проблемы в будущем.

Каждый баг-фикс — это два фикса: код и патчинг тест-системы, которая его проморгала.

Полностью протокол тут: https://github.com/CodeAlive-AI/ai-driven-development/blob/main/BUG-FIX-PROTOCOL.md P.S. Этот протокол предполагает, что принцип работы тест системы вашего проекта описан в папке docs/test-system. Ещё, из этого протокола легко генерится скилл. Поделитесь в комментариях какие интересные техники вы применяете для верификации изменений от AI и какие инсайты для себя открыли на этом пути? @ai_driven — AI-Driven Development

AI-Driven Development: Новый сезон Давненько ничего не писал сюда - уж очень был увлечен и стартапом и адаптацией кодбазы под агентов. Материалов и экспертов накопилось множество, поэтому я возобновляю и блог и YouTube канал. AI-Ready Codebase Открываем сезон с Максимом, автором канала Этихлид с разговором о том, что на практике нужно сделать в больших кодовых базах, чтобы получать от кодагентов желаемый результат. О чем будем говорить с Максимом — Почему большой проект нельзя просто «бросить в агента» и что делать вместо этого — Иерархия MD-файлов как навигационный слой поверх кода: архитектура, сущности, процессы — Минимальный набор документации для legacy-проекта: что писать и в каком объёме — Онтологии и графы зависимостей: зачем строить и как поддерживать — Агенты для исследования legacy: формат «поставил — подождал — получил отчёт» — Граундинг на существующий код при внедрении новых фич: как агент находит противоречия раньше людей — Проблема памяти агентов и почему MD-файлы пока лучшее, что у нас есть Встречи проходят Live, поэтому будет возможность задавать вопросы спикерам. Дата и время: вторник 3 марта 16:00 МСК. Длительность: 1.5 часа. Расписание новых встреч (под спойлером, чтобы с толку не сбивало :)) Четверг 5 марта 16:00 МСК встреча с Денисом DEKSDEN (автор канала @deksden_notes) про его флоу агентной разработки для генерации десяток тысяч строк prod-ready кода. Пятница 6 марта 13:00 МСК - встреча с Иваном Закутным (автор канала @neuralstack) про First Principle Framework в контексте агентной разработки и инструмент quint-code. Чуть позже будут еще анонсы, следите за каналом. А если вы знаете интересных гостей, которым есть что полезного рассказать - пишите свои предложения в личку или в комментарии к этому посту. @ai_driven

Психотерапевт для Claude Code или пусть он настроит себя сам А вы знали, что можно настраивать Claude Code, прямо через Claude Code? Для этого достаточно написать в чат, например: > Добавь хук, который блокирует глобальные rm -rf команды > Добавь хук, который спрашивает разрешение на команды с 'db reset' или так: > Установи Grafana MCP > Измени мой API-ключ CodeAlive в конфиге MCP Классно же? Так вот, я удивлюсь если вы знали о такой возможности, потому что в действительности в дефолтном Claude Code такая возможность отсутствует. Поэтому я сделал плагин, который позволяет вносить в настройки CC почти любые изменения, просто написав об этом текстом самому клоду, как в примерах выше - плагин так и называется Claude Code Reflection. Что еще входит в плагин: Управление скиллами Просмотр, настройка, удаление, перемещение user scope - project scope и даже ревью. Управление субагентами Создание, изменение и удаление субагентов с корректными разрешениями. Создание и публикация плагинов Сделали классный скилл или скиллы и хотите упаковать их в плагин и отдать в пользование этому миру? Не проблема, claude-plugins-manager скилл там как раз для этого. Напомню, что поскольку весь функционал плагина реализован в виде скиллов, они очень экономны к контексту (менее 500 токенов в сумме). Ну, и бонусом: Claude Best Practices Skill Скилл проверяет, на сколько хорошо ваш проект (кодовая база) и сам клод оптимизированы под эффективную работу Claude и фактически делает аудит контекста и кода, и дает рекомендации по оптимизации. Еще, это скилл можно в принципе поспрашивать про актуальные лучшие практики CC. --- Устанавливается двумя командами. Запускаем claude и:

# Сначала добавляем маркетплейс, чтобы плагин появился в поле зрения
/plugin marketplace add https://github.com/CodeAlive-AI/claude-code-reflection-skills.git

# Теперь ставим сам плагин
/plugin install claude-code-reflection-skills@claude-code-reflection-skills

Теперь перезапускам Claude Code и вуаля - теперь ваш клод как после сеанса к психотерапевту, прокаченный рефлексией. Код, конечно, открыт, а звезды приветствуются: https://github.com/CodeAlive-AI/claude-code-reflection-skills Кстати, пока я занимался этими мета-скиллами, осознал сколько же всевозможных сущностей с разными нюансами появилось в CC, отсюда возникла идея для нового стрима с разбором всего этого разнообразия и практическими кейсами под каждую сущность, интересно ли кому-то такое? @ai_driven

Через 5 минут начинаем митап про SWE-бенчмарки с Ибрагимом, автором SWE-rebench. Ссылка на встречу в комментарии к этому посту.

Разбор SOTA агента от Ильи Рис - победителя ERC3 Ну что, друзья как начался ваш год? Надеюсь, что хорошо и что вы отдыхаете! Пока все отдыхают, мы с Ильей собрались и записали бомбическое интервью об архитектуре его AI-агента, который недавно взял первое место в соревновании ERC-3 Рината Абдулина среди агентов на базе опенсорс моделей. В итоге получился великолепный материал по Context Engineering в мультиагентных системах. Поэтому хочется отдельно сказать спасибо Илье за такую открытость. Напомню, кстати, что статья Ильи про архитектуру его RAG системы, наверное, является наиболее залайканым материалом по RAG на Хабре за все время (+161!). Мне было особенно интересно разобрать именно решение Ильи, т. к. мне часто приходится общаться с энтерпрайзами и банками, а они очень уж любят открытые модели и почти не используют проприетарные. В общем, без лишних слов - тот редкий случай, когда множество инсайтов обеспечены даже матерым агентоводам. Запись интервью-разбора: https://youtu.be/3JYHMMw5WSU Таймкоды: 00:00:02 Вступление. Илья Rice и его победа в бенчмарке агентов ERC-3 00:06:03 Что из себя представляет соревнование ERC-3: симуляция энтерпрайз среды 00:13:39 Open Source решение и инструмент визуализации трейсов 00:18:07 Архитектура решения: определение пользователя (WhoAmI) и прав доступа 00:24:14 Динамический системный промпт: как не засорять контекст 00:38:06 Хак с пагинацией: Wrapper для API инструментов 00:41:14 Структура ответа агента: State, Plan, Action, Function 00:44:02 Почему отказались от нативного Tool Calling в пользу Structured Output 00:51:13 Стоит ли верить публичным бенчмаркам? 00:55:45 Разбор реального кейса: задача по смене статуса проекта 01:03:30 Почему не использовали классический RAG 01:05:58 Динамическая подгрузка инструкций для инструментов 01:11:14 Валидатор (The Validator): отдельная LLM для проверки действий агента 01:21:43 Работа с контекстом: работа с ошибками агента 01:33:20 Техника Sliding Window: обрезка истории для экономии внимания модели 01:36:05 Store Benchmark: Оркестратор и специализированные субагенты 01:44:26 Выбор моделей: почему Open Source 01:45:41 Заключение Исходный код агента Ильи: https://github.com/IlyaRice/Enterprise-RAG-Challenge-3-AI-Agents Трейсы агента: https://ilyarice.github.io/Enterprise-RAG-Challenge-3-AI-Agents/ Чат с исходным кодом агента в CodeAlive: https://app.codealive.ai/public/chat/3geNycM--lLbA3vxL272vA P. S. А уже в этот вторник 6-го января в 12:00 по Лондону, 13:00 по CET, 15:00 по МСК и 17:00 по Алматы состоится встреча с Ибрагимом - автором SWE-бенчмарка SWE-rebench и автором тг-канала @c0mmit. Добавляйте событие в календарь, чтобы не забыть.

Начинаем прожарку UX https://us06web.zoom.us/j/84038206833?pwd=qrZCoowZlrmPFm5XFflFhxLhq5VZpY.1

Прожарка UX через 45 минут в прямом эфире Хороший продуманный UX всегда был редкостью - до сих пор остается огромное множество красивых, но совершенно непонятных и неудобных интерфейсов - причем, как в дорогих продуктах, так и в AI-generated интерфейсах. Если AI уже прекрасно генерирует интерфейсы почти любой сложности, то абсолютно не факт, что эти интерфейсы будут понятны вашим пользователям. Это как раз та проблема, с которой мы столкнулись в CodeAlive. К счастью, нам повезло посотрудничать с очень опытным UX-специалистом, он помог нам провести несколько сессий и выявить ключевые проблемы в наших флоу. Поскольку я повсеместно вижу неудобные приложения и периодически сам страдаю от этого - в целом, я вижу определенную миссию в распространении знаний о том, что такое хороший UX. Так вот, совместно с Алексеем Тушкановым мы запускаем новый эксперементальный формат прожарки UX ваших интерфейсов. Мы собрали несколько реальных приложений и их фаундеров и в прямом эфире проведем разбор их интерфейсов по фреймворку Алексея. А заодно проверим, на сколько современный AI может быть полезен в задачах на улучшение UX. В общем, формат должен быть особенно интересен тем, кто вайбкодит создает свои приложения. Встреча сегодня в 17:00 по Алматы, 15:00 МСК и 13:00 по CET: https://calendar.app.google/WQd2qCRkTV7tmvZn8

Начинаем митап по Zenflow Подключайтесь по ссылке: https://us06web.zoom.us/j/82921157920?pwd=3BgZuT7UbBOQvq7piTpcDOb6s0v1NV.1