PRO продукты и системы | Иннокентий Бодров

то самое ощущение, когда твой подчиненный мудак, но все равно ты виноват как руководитель 🌚

Глеб глаголит истину

Рассказал на АД про роль аналитика, как архитектора контекста в эпоху ИИ.
Спасибо @sofyakalinina за фоточки!

Закрылся первый поток Intensive Vibe Analytics 🔥

В начале года собралась группа аналитиков. Разный уровень, разные индустрии, разные задачи. Но почти у всех была одна и та же боль:

👉 огромное количество рутины, которую AI теоретически уже мог бы закрывать, но почему-то в реальности этого не происходило.

Изначально я планировал курс где-то на месяц-полтора. В итоге всё растянулось больше чем на три месяца — потому что очень быстро стало понятно: чтобы реально начать использовать AI в работе, недостаточно просто «уметь писать промпты». Нужно перестраивать само мышление и подход к работе.

За это время ребята:
- собрали собственные AI Workspace
- научились работать с агентными пайплайнами
- прошли путь от идеи до рабочего прототипа
- и в финале защитили свои проекты

Что получилось в итоге:

— голосовые подсказки оператору в реальном времени во время разговора с клиентом
— приложение для семейного бюджета
— аналитический инструмент, который уже пошёл в работу в банке
— приложение, которое человек защищал на испытательном сроке — и получил thumb-up от CEO 👍

И вот что, наверное, мне нравится больше всего.

👉 Никто из ребят не писал код в классическом понимании.

Они:
- формулировали задачи
- писали спецификации
- декомпозировали процессы
- оркестрировали AI-агентов
- и направляли реализацию

По сути, это был очень наглядный пример того, как меняется роль аналитика и TPM-а прямо сейчас.

На этой неделе буду публиковать отзывы выпускников — у каждого получилась своя история и свой опыт прохождения.

А в конце недели открою набор на второй поток 👀

И да — огромное спасибо первой группе.

Честно, вы сделали этот курс сильно лучше, чем я его изначально задумал.

Этот пост написан без использования ИИ

Всем привет!
Я тут пропадал на некоторое время и тому были веские причины:
1. Жесткий загруз по работе
2. Переезд на другую квартиру
3. Всей семьей переболели каким то вирусом
4. Ах да, еще жесткий загруз по работе и проектам 🙂
5. Я очень хочу проводить время с семьей
В итоге я сознательно отказался от участия в трех интересных активностях, порезал время на все второстепенные активности, в том числе и на канал.

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

А еще отпраздновали 4-летие сына с палеонтологической экспедицией и баней.
Доволен собой 🙂

Теперь буду постепенно возвращаться в строй, рассказывать по свои (и не только свои) успехи на ниве вайбкодинга и образования.

Stay tuned!

Сегодня день анонсов. Но все реально очень полезное, всячески рекомендую!

Полгода назад мы разбирались, реально ли создавать промышленные решения с помощью AI, а не только вайбкодить прототипы. Сегодня мы смотрим, каких результатов уже добились крупнейшие российские компании с помощью AI.

О чем будем говорить:

• как AI меняет цикл разработки и роли в команде

• как оценить эффективность использования AI, какие метрики будут важны в будущем

• с чего начать внедрение, и на какие результаты рассчитывать

• какова роль человека в будущем программной инженерии

Если вы тоже обнаружили, что ваши новые коллеги — не люди, а агенты — подключайтесь ко второму сезону AI Dev Conf — 21 мая, онлайн

🔗 Программа и регистрация — на сайте aidevconf.org

Хм... Вот смотришь на миллионы AI-каналов, а чаще всего новое, что узнаешь, - только то, что кто-то выпустил новую модельку. Реального использования очень мало. В итоге совершенно случайно в блогах OpenAI за апрель находишь золото. Например, новый оркестратор от OpenAI - Symphony.

Давно думал переходить на что-то типа канбана для AI и видел, что экс-команда Wrike делала подобное в ZenFlow, но увидеть примеры от ведущей лаборатории - это сильно. Решали абсолютно ту же проблему, что сейчас стоит у всех, кто использует ИИ для генерации кода в промышленных масштабах. Вот есть Codex – AI-агент, который пишет код. Но даже с ним инженеры упираются в потолок: один человек может одновременно вести 3–5 сессий с агентом, дальше начинается ад переключения. Агенты быстрые, но человек, который их направляет – узкое место. Получилось как с командой джуниоров: вроде бы их много и они способные, но тимлид в мыле, потому что каждому надо объяснить и проверить.

Что придумали и протестировали: перестали управлять агентами напрямую. Вместо этого подключили агентов к таск-трекеру (Linear – аналог Jira). Логика такая:
- Открыл задачу в трекере → автоматически запускается агент, который её делает
- Агент работает в своей папке, видит код, может открывать pull request, отвечать на ревью
- Если упал – перезапускается. Если завис – система его перезапускает
- Если нашёл по дороге другой баг – заводит новый тикет, который тоже подхватит другой агент

То есть таск-трекер стал пультом управления для AI. Завёл задачу – забыл, через какое-то время приходишь смотреть результат.

Что в итоге изменилось:
- Замёрженных PR стало в 5 раз больше
- Один инженер сделал три серьёзные правки прямо с телефона из домика с плохим вайфаем – просто заводя задачи в Linear
- Продакт-менеджеры и дизайнеры теперь сами кидают фичи в систему, минуя инженеров. Получают обратно видео с работающей фичей
- Стало дёшево пробовать идеи – завёл десять тикетов «попробуй так», плохое выкинул

Пишут, что было и еще два важных момента:
1) процесс команды должен быть записан текстом. Раньше передавалось устно: «заведи ветку, поставь статус In Progress, открой PR, дождись CI, перенеси в Review». Теперь это явный файл WORKFLOW.md в репозитории. Полезно даже если агентов нет – новички понимают как работать.
2) единица работы это задача, а не сессия с AI. Не «открой чат и попроси AI написать код», а «опиши задачу в трекере». Это снижает порог входа для неинженеров. И можно на фоне сделать все нужные проверки и обвязки.
Короче, нормальное описание задач все еще рулит, но теперь можно не инженеров на таски направлять, а AI.

Как сделать своё. Тут прикол. Они выложили по сути набор промптов, а не код :)
Текстовый файл SPEC.md с описанием как должна работать система. Кажется, это будущее разработки ПО - набор инструкций для ваших ИИ агентов, типа инструкция от ИКЕА :)

Завтра вот как раз обсудим с командой, пользуемся Linear тоже.

https://openai.com/index/open-source-codex-orchestration-symphony/

Проджекты идут на завод?)

Не могу не поделиться интересным постом.
Соответственно ИИ занимает нишу мидлов?
Как думаете, заменит сеньоров?

Что послушать на выходных?
📢 [AI Dev подкаст #1] ИИ в проектировании архитектуры: метрики и «скиллы»

Спойлер: LLM уже справляется с проверкой техрадара, оценкой пул-реквестов и анализом архитектурного долга. Но есть нюансы.

Мы собрали трех практиков, чтобы ответить на вопросы:
— как ИИ меняет работу архитектора;
— почему SDD (Spec-Driven Development) пока сырой, но пробовать уже надо;
— что такое agent skills и как их писать уже сегодня.

🎙 Гости выпуска:
Максим Смирнов (@it_arch) — экс-главный архитектор ЦБ РФ, «БИНБАНК Диджитал», Билайн.
Руслан Сафин (@rsa_enc) — техдир и партнёр в «Бындюсофт», преподаватель ИТМО.
Андрей Бураков (@another_sa) — автор канала «Yet Another Analyst».
Андрей Дмитриев - JUG Ru Group 😀

🧠 О чём говорили (кратко):

🔹 Что ИИ умеет уже сейчас:
-проверять код на соответствие архитектурным паттернам;
-контролировать пул-реквесты (актуально, когда агенты шлют много изменений);
-оценивать архитектурный долг через метрики;

🔹 Почему C4 + LLM пока «не взлетели»?
Модели путаются в большом контексте, зато agent skills существенно улучшают выдачу.

🔹 Миф про бюрократию
Да, ИИ забирает на себя документирование и прочее, но не это главное. Главное — он помогает перейти от субъективных оценок к объективным метрикам качества архитектуры и уже сейчас накапливать информацию об архитектуре.

🔹 SDD — пока сыро
GitHub SpecKit, Amazon’s Kira — генерация спецификаций часто больше кода, а без человека качество низкое. Но если ваш проект новый, то вполне уже рабочий вариант.

🔹 Что делать прямо сейчас?
-Оцифровывать свои навыки (просто текстовый файл + описание).
-Внедрять пилоты в компании.
-Перестать ждать когда «устаканится».

🔹 Через 2–3 года
Переход от системного подхода к средовому. Языки программирования могут измениться — ИИ не нужны современные синтаксисы. Возможен ренессанс DSL.

🎯 Три главных мысли из выпуска:
➕Контекст важнее промта — модель сама поймёт, что делать, если правильно подать данные.
➕ADR становятся еще ценнее — они сохраняют память проекта, которую ИИ забывает.
➕Не пробовать ИИ — значит отстать. Но пробовать без критики — накопить ошибки.

📌 Полезные ссылки из выпуска:
Маркетплейсы навыков: skillsdirectory.com, skills.sh, clawhub.ai
Статья на Хабре от Руслана

🎧 Слушать подкаст.

#AI #архитектура #подкаст #LLM #softwarearchitecture #SDD

Программа собрана — ждем только вас! 🚀
Мы финализировали сетку докладов предстоящей конференции. Это не просто выступления, а полноценный интенсив по архитектуре, аналитике и новым технологиям. Мы собрали экспертов, которые ежедневно решают сложные задачи в крупных проектах, и готовы поделиться этим опытом с вами.

18 апреля, суббота, с 10:00 до 17:00 пройдёт онлайн-конференция Аналитический марафон 17 "Технологии и коммуникации в работе системного аналитика"

Что в программе? Разбираем детально:

🔹 Хайдаров Ильназ — «Стандартизация API: от хаоса к качеству»
Методика для тех, кто устал от зоопарка интерфейсов. Как внедрить единые стандарты и измерить их эффективность.
🔹 Прохоров Николай — «Быстрый старт для создания ИИ-ассистента»
Практический гайд по внедрению LLM в кодовую базу организации. Узнайте, как заставить ИИ помогать в исследовании ваших приложений.
🔹 Ирина Орлова — «Надёжная шина данных на Apache Kafka»
Разберем нюансы асинхронного обмена сообщениями и построение отказоустойчивых систем на базе Kafka.
🔹 Дмитрий Курило — «От таблиц к графам»
Новый взгляд на анализ отраслевого рынка. Почему графовые модели эффективнее привычных таблиц для выявления скрытых связей.
🔹 Шутова Елена — «От монолога к модели»
Как с помощью правильных вопросов и методологии Event Storming избежать бесконечных правок и сразу строить то, что нужно бизнесу.
🔹 Максим Смирнов — «Навыки архитектурных решений»
Поговорим о фундаменте: как системно подходить к принятию решений, которые не придется переделывать через полгода.
🔹 Калинина Софья — «От промпта к прототипу»
Валидация требований на ранних этапах. Как современные инструменты помогают проверить гипотезы еще до написания первой строчки кода.
🔹 Бурмистров Владимир — «Privacy by Design для аналитика»
Проектирование систем с учетом конфиденциальности данных. Как аналитику учитывать требования безопасности с самого начала проектирования.

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

Регистрация здесь ➡️ https://clck.ru/3T6usa

🔥 «Говнокод», который зарабатывает деньги — и почему это не баг, а выбор

Все уже обсудили слив исходников Claude Code: посмотрели, разобрали и довольно быстро пришли к ожидаемому выводу — «никаких паттернов, всё плохо, код грязный». На этом обычно разговор заканчивается. Но если остановиться на секунду и посмотреть шире, возникает куда более интересный вопрос.

Этот «плохой» код:
• стабильно работает
• выдерживает нагрузку
• используется миллионами разработчиков
• и приносит деньги

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

⸻

🧠 Где реальность расходится с учебниками

Проблема в том, что мы часто смотрим на разработку через призму «идеального мира», в котором всё должно быть красиво, структурировано и соответствовать best practices. Но продуктовая разработка живёт по другим законам.

Есть две параллельные реальности:

С одной стороны — инженерный идеал:
• чистая архитектура
• слои и зависимости
• отказоустойчивость
• переиспользуемость

С другой — реальность продукта:
• сроки
• деньги
• гипотезы
• необходимость быстро выходить на рынок

И в этой второй реальности чаще выигрывает не тот, кто написал «правильно», а тот, кто быстрее доставил ценность и проверил, что она вообще кому-то нужна.

⸻

💡 Непопулярная, но важная мысль

Архитектурные паттерны — это не цель и не религия. Это инструмент, который решает конкретные задачи.

Да, они критичны там, где:
• высокая нагрузка и требования к надежности
• сложная доменная логика
• долгий жизненный цикл системы

Но там, где продукт только формируется, где риски относительно невысоки, а скорость важнее идеальности, решение «сделать проще и быстрее» часто оказывается рациональным, а не халтурным.

⸻

⚡ Где чаще всего ошибаются команды

Очень часто аналитики, архитекторы и даже продакты начинают тянуть «правильную архитектуру» туда, где она пока не нужна. В итоге система усложняется раньше времени, разработка замедляется, а time-to-market страдает.

Парадокс в том, что в попытке сделать «как надо» команда может просто не успеть сделать «вообще».

⸻

✅ Что важно держать в голове

Зрелость инженера или TPM не в том, чтобы всегда следовать паттернам, а в том, чтобы:
• понимать их
• осознавать, какие риски они закрывают
• и осознанно принимать решение, когда их можно не применять

То есть речь не про «забить на качество», а про управление компромиссами.

⸻

🔥 Вывод

Идеальный код — это абстракция. Продукт — это всегда компромисс между скоростью, качеством и рисками.

И настоящий профессионал — это не тот, кто пишет «идеально», а тот, кто понимает, где можно сделать проще и быстрее, а где это приведёт к проблемам.

⸻

А ты как для себя проводишь эту границу?
Где заканчивается «разумный компромисс» и начинается технический долг, который уже опасен? 👇

🔥 Вайбкодинг: когда ИИ уверенно ведёт тебя… не туда

Сегодня из практики, немного про будни вайбкодинга и про то, почему роль человека в разработке никуда не делась, а местами стала даже критичнее.

Собирал я тут одного «интеллектуального помощника», который должен был в зависимости от задачи ходить в разные API и дергать модели от OpenAI, Anthropic и Google. Идея простая и вроде бы красивая: делать A/B-тесты, сравнивать ответы моделей и выбирать оптимальную под конкретный сценарий.

Ключи вставил, токены прописал, всё как обычно. Запускаю — и почти сразу начинаются ошибки. Сначала прилетает 500, потом стабильно начинает сыпаться 404 с сообщением, что модель не найдена. Я, как честный вайбкодер, даю ИИ возможность «самому разобраться», ведь он же только что всё это сгенерировал и вроде как «понимает, что делает».

Но проходит одна попытка, вторая, пятая, десятая — и ничего не меняется. Ошибки те же, решения всё более странные, а уверенность в ответах — всё такая же высокая.

В какой-то момент я останавливаюсь и решаю вернуться к базовой инженерной логике. Мы делаем простой отладочный скрипт, который напрямую дергает каждую модель и показывает, доступна она или нет. Результат оказывается предсказуемым, но от этого не менее показательным — все модели возвращают 404.

Тогда убираем все обёртки и идём напрямую в API. И снова получаем те же самые ошибки. На этом этапе становится очевидно, что проблема не в сети, не в токенах и не в библиотеке.

Открываю документацию — и вот тут всё встаёт на свои места.

Оказывается, что ИИ аккуратно и уверенно подставил неправильные имена моделей. Причём у всех трёх провайдеров. Где-то это были устаревшие названия, где-то слегка искажённые, а где-то просто «похожие на правду» варианты, которые он сам и сгенерировал.

После того как я вручную прошёлся по документации, проверил актуальные названия и подставил их в код, всё «внезапно» заработало с первого раза.

⸻

🧠 И вот здесь главный вывод, который важно проговорить

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

Особенно это проявляется в интеграционных задачах, где есть реальные API, версии, ограничения и требования к точности до символа.

⸻

⚡ Вывод

👉 вайбкодинг — это не замена инженерного мышления, а его усилитель
👉 если ты не проверяешь, ты не ускоряешься — ты просто быстрее приходишь к неправильному результату

И, наверное, самая простая формулировка всей этой истории:

👉 на ИИ надейся, но и сам не плошай

⸻

А у тебя были кейсы, когда ИИ уверенно вел тебя в тупик?
Где чаще всего ловишь его на ошибках? 👇

🔥 «Все псы, а я Д’Артаньян» — самый дорогой баг в карьере*

Ох, эта мысль у меня зрела все выходные и, кажется, наконец дозрела.

Хочу поговорить про штуку, которая, если честно, мешала мне сильнее всего — и в карьере, и в жизни. Это тот самый синдром, который в народе описывают фразой «все вокруг плохие, а я один Д’Артаньян».

На первый взгляд это выглядит как уверенность в себе и критическое мышление. Но на практике в большинстве случаев это совсем не про зрелость.

⸻

🧠 Неприятная правда, которую тяжело принять

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

Это может быть:
• отсутствие контекста — бизнес-ограничений, сроков, политики
• непонимание реальных целей задачи
• зацикленность на своей «правильной» картине мира
• банальное эмоциональное и физическое истощение

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

⸻

⚡ Где здесь главная ловушка

Самое неприятное, что этот синдром очень коварный. Он дает ощущение, что ты умнее системы, что ты видишь глубже и понимаешь лучше других.

Но по факту он:
• мешает видеть реальную картину
• блокирует развитие
• и снимает с тебя ответственность за происходящее

Потому что если «все вокруг некомпетентны», то тебе вроде как и делать ничего не нужно.

⸻

💡 Когда это особенно проявляется

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

И именно тогда особенно легко поверить, что проблема точно не в тебе.

⸻

⚖️ Но важно не впасть в другую крайность

Иногда процессы действительно сломаны, решения действительно плохие, а люди действительно принимают странные решения. Это тоже реальность.

Но даже в этом случае ключевой вопрос звучит иначе:

👉 не “кто виноват”, а “что я с этим делаю”

⸻

🔥 Вывод

Синдром «я один прав» — это не признак силы или экспертизы. Это чаще сигнал, что ты уперся в предел своего понимания ситуации.

И если хочешь расти, то критически важно научиться делать неприятную, но очень полезную вещь:

👉 сомневаться в своей правоте быстрее, чем в чужой

⸻

А у тебя было такое состояние, когда казалось, что все вокруг делают ерунду?
Как ты с этим справляешься? 👇