Решения и действия (с)

Если разложить любую профессию на составляющие то, вы обнаружите одну и ту же повторяющуюся примитивную структуру:

Решения и действия. Всё

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

ПО автоматизировало «действенную» часть работы и поглотило действие, но уровень принятия решений остался человеческим, потому что принятие решений требует рассудительности, учёта контекста, терпимости к неопределённости, распознавания образов в неполной информации, креативности и творчества. Для всего этого необходим интеллект (и вкус – прим.). А интеллект раньше не был доступен по запросам из промптов.

Вот почему работники интеллектуального труда чувствовали себя неприкасаемыми. Они не просто кликали мышкой. Они РЕШАЛИ, НА-ЧТО кликать. Но ИИ полностью меняет это.

ПО – это «действие по триггеру»
ИИ – это «принятие решения по запросу»

Подключите ИИ к ПО и данным, и вы замкнёте цикл. Теперь вы можете создавать сущности, которые могут принимать решения и действовать автономно, от начала до конца.

Марк Андреессен однажды сказал, что ПО поглотит мир. Оно поглотило лишь часть работы. Теперь ИИ пришел, чтобы завершить трапезу.

Но, как ни парадоксально, это не убивает рабочие места в сфере разработки ПО и менеджмента, а создаёт бесконечный спрос на них.

Каждый рабочий процесс, который теперь можно автоматизировать, нужно пересоздавать заново.

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

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

Поэтому менеджеры и разработчики, которые понимают, что они больше не создают инструменты, а создают системы сущностей, не будут заменены.

Так они эволюционируют в Архитекторов всего, что будет их заменять.

Product Focus Club 2026 — главное событие весны про будущее продуктов в эпоху ИИ

17 апреля пройдёт конференция Product Focus Club 2026, где в одном месте соберутся собственники, C-level и руководители продуктов и подразделений, чтобы обмениваться свежими кейсам и идеями.

Четыре трека:

— Продуктовая, бизнес- и AI-трансформация
— Лидерство и команда в кризис
— Стратегия прорыва и точки роста
— AI & тренды

Cпикеры: Сбер, Финам, Rostics, Мегафон, OKKO, Персона, Ростех, ВК и другие.

На конференции вы увидите рыночные тренды, узнаете, как другие встраивают ИИ в продукты, команды и бизнес-процессы и переосмыслите свой продукт в контексте ИИ, найдя новые точки для его роста.

👉 Подать заявку на участие

Для обеспечения качественного нетворкинга и сильное окружения, все участники проходят модерацию.

Промокод на скидку 15% для подписчиков канала: PF15RUSPM.

RevenueCat опубликовали ежегодное исследование рынка подписок

Внутри много всего, из интересного:

– Жёсткие пейволлы превосходят фримиум по конверсии: приложения, требующие оплаты сразу, конвертируют пользователей в 5 раз эффективнее, чем модели фримиум (10,7% против 2,1%). Однако в долгосрочной перспективе это преимущество исчезает и спустя год показатели удержания пользователей (retention) для обеих моделей становятся практически идентичными.

– Приложения сокращают пробные периоды вопреки статистике: пробные периоды длительностью от 17 дней обеспечивают конверсию на 70% выше, чем короткие триалы (42,5% против 25,5%). Тем не менее, разработчики продолжают переходить на 3-дневные пробные версии. Сегодня почти половина всех приложений предлагает пробные периоды длительностью не более четырех дней, тем самым, возможно, упуская значительную часть потенциальной конверсии.

– 55% всех отмен 3-дневных пробных периодов происходит в «нулевой день» (день установки приложения). Битва за подписчика выигрывается или проигрывается уже во время первой сессии, что вынуждает разработчиков мгновенно создавать для пользователя тот самый aha-moment.

— Почти треть всех отмен подписок в Google Play происходит не по воле пользователя, а из-за сбоев при списании средств — этот показатель вдвое больше аналогичный показатель в App Store (14%).

– ИИ помогает продавать, но не удерживать: приложения на базе ИИ приносят на 41% больше выручки в пересчёте на одного платящего пользователя, однако отток аудитории в них происходит на 30% быстрее.

3,000 лет д.н.э: Проект-менеджмент
1855: Структура ж/д компании
2026: Структура ИИ-агентов

В 1855 году у Нью-Йоркско-Эрийской железнодорожной компании возникла проблема. Железнодорожный транспорт в то время представлял собой крупнейшую в истории страны структуру по сложности своей организации.

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

Схема представляет собой дерево, корни которого символизировали президента и совет директоров. Ветви – пять оперативных подразделений и сервисных отделов (ремонт локомотивов, автомобили, телеграф, типографию, а также казначейство и секретариат. Листья же обозначали местных агентов по продаже билетов, грузоперевозкам и экспедированию грузов, подчиненных руководителей, поездные бригады, бригадиров и так далее.

Одной из отличительных особенностей схемы Маккаллума для Эри является то, что она функционирует одновременно и как карта и как организационная схема. Вы можете видеть как структуру всей железной дороги и расположение её подразделений, так и организационную структуру каждого подразделения.

На схеме Маккаллума самые высокопоставленные руководители компании расположены внизу, что противоречит современному пониманию иерархических организационных схем.

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

Несмотря на достижения МакКаллума в конце XIX века, организационные схемы получили широкое распространение лишь спустя почти сто лет, с появлением бизнес-школ в США. До этого момента организационные схемы появлялись в исторических документах лишь в контексте военных действий.

P.S. Маккаллум просто скопировал всё с языка Кипу эпохи среднего горизонта (периода до инков), в котором цифры завязывали узелками и могли использовать для учёта расходов и доходов. Некоторые из узлов так же, как другие особенности, такие как цвет, представляют нечисловую информацию, которая до сих пор ещё не была расшифрована.

В 2006 году американский исследователь Гари Уртон обнаружил, что в узелках Кипу заложен код, напоминающий двоичную систему. 3,000 лет до нашей эры. Заложен код.

Trello, Jira, Notion, Obsidain? А может, лучше Настя Кипу?

Всем пятницы и выходных!

Subagents vs. Agent Teams: в чём между ними разница + 5 паттернов оркестрации

Субагенты – это параллелизм через изоляцию

Субагент – это специализированный экземпляр в Claude/ChatGPT, работающий в собственном изолированном окне контекста. Представьте, что вы выступаете руководителем исследовательской группы. Вы не читаете каждый первоисточник лично, а делегируете конкретные вопросы исследователям, они возвращаются к вам с квинтэссенцией полученных данных, и вы синтезируете всё это в единый, связный результат. Именно так работает механика с субагентами.

Каждый субагент получает:

– Собственный системный промпт, определяющий его специализацию.
– Конкретный набор инструментов, к которым он имеет доступ.
– Чистое, изолированное окно контекста.
– Одну конкретную задачу для выполнения.

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

Смысл использования субагентов заключается не только в параллелизме, но и в компрессии. Вы дистиллируете огромный объём поисковой активности в чистый сигнал, не засоряя контекст родительского агента информационным шумом.

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

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

Команды ИИ-агентов – это координация через коммуникацию

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

Команда агентов состоит из трёх ключевых компонентов:

– Лидер команды, который координирует работу, распределяет задачи и обобщает результаты.

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

– Общий список задач, в котором отслеживается статус каждой задачи, а также зависимости между задачами.

Главное отличие от субагентов заключается в прямом взаимодействии по принципу «от равного к равному». Участники команды могут обмениваться сообщениями, делиться результатами, выявлять препятствия и вести переговоры, не пропуская всё через родительского ИИ-агента руководителя.

Вот как следует подходить к выбору между этими двумя подходами:

1) Суб-агенты работают по принципу «запустил и забыл». Вы ставите им задачу, они её выполняю и отчитываются о результате. Никакого взаимодействия или диалога между агентами. Ни общей памяти, ни сохранения текущего состояния, потому что жизненный цикл каждого суб-агента ограничен рамками одной сессии.

2) Команды ИИ-агентов работают на принципах сотрудничества, сохраняют своё состояние и накапливают контекст с течением времени. Результаты, полученные в процессе выполнения любой задачи, мгновенно становятся доступны ИИ-коллегам по команде.

Используйте суб-агентов, когда ваша работа допускает «параллельное» выполнение: независимые потоки исследований, изучение кодовой базы или поиск информации, когда родительскому агенту требуется лишь краткая сводка результатов.

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

Как там дела у Фигмы после IPO

1. Тул #1 для UX/UI/дизайна
2. Отказ от поглощения Adobe, компенсация в $1B
3. Скандал вокруг прав на слова dev mode и Config
4. Выход на IPO
4. 6-ти месячный lock-up акций после IPO
5. Акции упали на 80% (на языке биржи они превратились в мусор)
>> Figma сейчас здесь <<

Figma в 2026 году убыточна на -120% (они тратят $220 чтобы заработать $100), а рост выручки замедлился до 30%, что по стандартам компаний стартапов её уровня считается весьма слабым результатом.

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

Ко всему прочему, Фигме на хвост наступают конкуренты типа https://penpot.app (рекомендую изучить как альтернативу Фигме, есть self-hosted и тот же MCP для фронтов) и, в целом, вся ИИ индустрия, готовая в любой день выкатить и выкатывающая очередной уникальный ИИ-тул для создания уникального дизайна и интерфейсов.

Я это всё плавно подвожу к тому, что эпоха SaaS с приходом ИИ ОЧЕНЬ сильно изменилась и рыночек в лице акций самого популярного инструмента для создания интерфейсов тому наглядный пример.

И подкидывая дров в печку AI Free Zone, скажу, что self-hosted продукты в эпоху ИИ рулят по 3 главным причинам:

– с self-hosted вы перестаёте зависеть от хотелок продактов условных Figma/Notion в эпоху ИИ-хайпа;

– с self-hosted вы платите $50/m за машину на DO вместо того, чтобы платить тысячи $ за каждого сотрудника Figma/Notion/Slack за... а за что мы платим им тысячи долларов?

– вы не кормите чужой ИИ своими данными.

И для меня приятным удивлением в этом году было обнаружить https://anytype.io для ведения тасочек и доков. Русские ребята в Швейцарии пилят удобную self-hosted замену Ношена/Обсидиана, в которой есть всё что надо от таск-менеджера и Слака, плюс шифрование ✨ В общем – make it yours.

Возвращаясь к Фигме, предположу, что её всё же выкупят и это будет OpenAI/Claude. Или, может быть, опять Adobe за... миллиард?

Что такое вайбкодинг и почему о нём так много говорят?

Битрикс24 выпустил бесплатный курс для гуманитариев из 11 уроков, где простым языком разбирают вайбкодинг и показывают, как делать первые проекты с ИИ без знания языков программирования.

Курс будет полезен руководителям, маркетологам, HR, менеджерам — всем, кому интересна тема. Формат практический: минимум теории, первые проекты, разбор ошибок, работа со структурой и сценариями.

Пройти курс можно на любой платформе:
YouTube / VK / RuTube

Каждая фича старого SaaS теперь переосмыслена ИИ

Подумай же и ты об этом:

– Old school SaaS полагался на жёсткие предопределённые правила и данные. Теперь ИИ заменяет их контекстной логикой.

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

– Workflows раньше строились руками менеджеров и разрабов как цепочки «If-This-Then-That», где люди проектировали каждый шаг. Теперь ты описываешь всё текстом и ИИ собирает и проводит процессы.

– Импорт данных раньше был по жёстким шаблонам CSV, который ломался на любой ошибочной строке и приходилось тратить часы на её поиск и исправление. Теперь ИИ ест данные за минуты.

– Поиск внутри продукта... Помню, на заре 2010-ых был целый сегмент продуктов по поиску внутри продуктов. Где они сейчас, где будут завтра?

– Обучение/документация были протухшей базой знаний FAQ. С ИИ документация жива и актуальна.

– Аналитика была взглядом на месячную задержку данных. ИИ анализирует онлайн.

– Дизайн был делом вкуса и времени. Теперь с ИИ остался только вкус.

– Старый спам уведомлений. ИИ-саммари и группировка.

– Онбординг? ИИ-адаптация!

– API? MCP!

– SaaS теперь источник данных для ИИ.

– Новые фичи = интеграция данных, а не фич

– Новый UI/UX = голос-чат

Мой старый знакомый не смог пройти мимо и прислал такой коммент к предыдущему посту. С его разрешения, дополняю пост своим ответом и накину на вентилятор свежей аналитеки от a16z (TLDR между строк: сокращайте операционку всех ещё сильнее)

>>>

Привет. Огромное спасибо за столь развернутый комментарий :) Дело в том, что я с ним и согласен и не согласен одновременно. Объясню почему.

Разрабы сейчас и разрабы пару лет назад — совершенно разные специалисты.

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

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

Сейчас с ИИ всё меняется (люди и процессы).

Те разрабы, кто оказался не такими и сохранили и пронесли до эпохи ИИ в себе немного пользовательской эмпатии, они поняли, что теперь с ИИ и агентами они могут СОЗДАВАТЬ продукты для пользователей, а не просто писать код для продуктов.

И такие спецы выстраивают вокруг себя на работе целую сеть из ИИ-агентов, которые работают и кодят и проверяют за них (и это видит руководство), либо... они уже пилят свои продукты. Самые хитрые делают и то и другое. А те, кто этого ещё не понял и кто по старинке с самодовольным видом пытается кодить код, их, к сожалению, оптимизируют.

А с корпами просто – в корпах всегда всё было сломано: здравый смысл, процессы, стратегия, псевдо-культура, даже монетизация и та через одно место из-за влияния фондового рынка, инвестиций, кокаинума и оторванного от реальности восприятия мира вокруг (я не говорю уже о том, что мира внутри продукта под названием пользователи и их лояльность для корпы не существует в природе). Так задумано, в этом "дух" корпы.

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

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

А значит их самодурство и недальновидность будут иметь место и дальше и будут только лишь усиливаться и одобряться ИИ. Просто потому что ИИ всегда говорит им «да».

И в один момент, ИИ+консультанты скажут "настало время управления с ИИ". и они согласятся, потому что: а) это легко/удобно/контролируемо; б) это выгодно; в) их ИИ не будет заменять (но это не точно, читай меж строк аналитику a16z про оптимизацию уровней + там ещё и статейка хорошая на десерт в ретвите).

А системы всегда стремятся к максимальному упрощению, строгости и автоматизации. Не просто же так в Матрице Архитектор сидит один в комнате 👨🏼‍💻

Вкус. Видение. ИИ

Вещи, которые должен уметь игнорировать продакт для сохранения своего внимания, видения и намерения (времени-энергии):

0. 100%-ый перфекционизм
1. Дословные требования пользователей
2. Громкость голосов стейкхолдеров
3. Авторитет "экспертных" мнений
4. Блеск фич и метрик конкурентов
5. Нужда совещаний и ответов
6. Просто срочность
7. Ожидание момента
8. Мнимая определённость планов
9. Запрос на определённости извне
10. Одержимость рационализаций
11. Процесс ради процесса
12. Потребность в одобрении командой
13. Стремление к консенсусу со всем(и)
14. Шёпот. Шум рыночного хайпа
15. Страх от признания пустых работ
16. Чувство вины за фичи (те работы)
17. Сравнение себя с другими
18. Свой собственный "успех"

Безупречность не про идеальность

Бэдтрип эпохи Web 2.0

Поймал вчера короткий бэдтрип в попытке начать работать с чистым Wordpress. В сознании сразу пронеслась куча воспоминаний из эпохи web 2.0, когда всё делалось руками: от контента до кода. А бэдтрип возник даже не из-за боязни чистого листа или сложности с кодом, нет (нет ничего прекраснее чем чистый белый лист).

Устанавливая нулёвую сборку WP, вдруг осознал (вспомнил), что большинство продуктов эпохи 2.0 характерны одним свойством – структурностью и ограниченностью во всём: от кода до механик работы с данными, которая лишала нас, как пользователей, той «магии» ПО и данных, на которую, на самом деле, они способны. И нам приходилось всё допиливать руками разработчиков, постоянно выслушивая сначала про те или иные технические ограничения тех времён, а после них и просто про ограничения времени.

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

Традиционным продуктам 2.0 не хватало внутренней и внешней свободы механик и данных и UGC, которую даёт (и так жаждет) ИИ.

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

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

...Основная бизнес-модель контента.
Миллионное комьюнити.
20+ лет развития продукта.
Решений нет...

...ИИ написала плагин с моих слов за 5 минут.

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

Проверка идей, развитие продуктов и написание кода в стиле 2.0 – это не просто медленно. Это, blyat, очень медленно.

(Фух, отпустило)

Конференции про лидерство смотрю уже не первый год, субботняя Dream → Teamlead на прошлой неделе не стала исключением. Больше всего зашли два доклада: про стресс и лидерство.

Из интересного:

Евгений Антонов, ведущий технический менеджер проектов в Yandex Infrastructure, объяснил, что тимлидер(ство) – это сначала про стек навыков по управлению собой, и только потом про управление командой. При этом нужно комбинировать в себе все виды лидерства в зависимости от КОН-ТЕ-КСТА. Контекст – король. Таким образом, научившись управлять собой, научишься тимлидству как профессии.

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

Всё втекает и вытекает из другого. И в этом вся сложность и простота одновременно ☯️

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

Полезный совет – рост тимлида часто происходит по фидбеку команды. Спросите коллег: а) что они в тебе как лидере видят; б) чего им в тебе не хватает.

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

👆 P.S. И да, о чём бы с удовольствием подискутировал про стресс в айтишке с молекулярным биологом Сергеем Харитоновым:

– Яркое холодное освещение ночью и блэкаут днём – самое плохое решение для "ночных тимлидов" какое может быть, и такой подход лишь усугубляет негативные ощущения, что, собственно, Сергей и подтвердил в конце – оно не работает на долгосрок (в отличии от тимлидов).

Долгосрок – темнота и свеча рядом с экраном/ноутом (само собой, яркость которого ночью на минимум), блики света от огня на стене которой идеально заменяют естественный(!) свет Солнца, которого нет ночью и успокаивают глаза-мозг. Просто потому что в свете Солнца много есть чего. Оно же есть в огне. Смотри в огонь, будь сам огнём, Огонь-Внутри-Тебя 🔥

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

– Спать можно дважды в сутки по 4 часа без вреда для здоровья. Говорю об этом как практик с 10+ летним опытом стабильной работы с полуночи и до 8 утра. Со здоровьем всё в порядке (тьфу х3). Спать 10+ часов я тоже могу и люблю, при правильном мышлении и подходе, переключение между режимами вообще не чувствуется, потому что режимов-не-существует.

– Пить магний вредно, как и пить любые витамины. Пить витамины – это дисбаланс. Лучше витамины есть органикой через постоянно полезную пищу и пить через травы/ягоды/коренья/этовсё, качая то самое "нейробиотическое чувство" (но я называю это по-другому).

А магний лучше всего усваивается нервами через кожу водой в ванне с английской солью, которая его и содержит (рекомендую миксовать с розовой гималайской). Добавь темноту и снова огонь, и вот уже эффект Х10.

– Физические тренировки и мышцы – очень тонкая тема в контексте разгрузки ими от стресса. Знаю много случаев, когда под воздействием стресса физическое переходило в фанатическое и люди гробили своё пошатнувшееся здоровье ещё больше с мыслью "сожгу стресс спортом". В итоге, выгорание и стресс уходят на более глубокий ментально-физиологический уровень и бетонируются там тренировками.

Ключ в медитации, дыхании и фасциях. Баланс и Тишина внутри тебя 😌

Ты слышишь? Дайджест мартовских постов перетекает в воздухе деревьев

– Почему время то летит, то ползёт
– Почему сильные команды посредственны
– Почему все встречи назначаются на час
– Что продакту включить в игнор

– Три уровня познания исследований
– Инкрементальность продуктовой разработки
– Обзор любого рынка 360
– The Company Graph

– Google Search Console для исследований
– 800 инструментов для исследований
– CIRCLES для продуктовых кейсов

– Джуны не нужны
– GitHub для продакта
– Продакты-решалы
– Когда менеджер должен вмешиваться

– Как понятно объяснять свои мысли
– Даём обратную связь по BOFF
– Насмотренность — ловушка
– Subagents vs. Agent Teams

– Что происходит с AI от a16z
– Грамотность пользователей с ИИ
– ИИ лишь увеличивает количество работы

– Ваш проект умрёт не из-за разработки
– Смерть отслеживания задач
– О ясности и сложности
– Идея множественности «Я»

🏔️ Gorillaz - The Mountain, The Moon Cave and The Sad God

Вайбкодинг продукта глазами продакта

Продолжаю кодить создавать некий-довольно-объемный по продуктовым и техническим меркам продукт с Claude, поделюсь наблюдениями:

– Не парь себе и ИИ мозги, не пиши на вайбе продукт с нуля, юзай опенсорс/CMS с уже: а) продуманной; б) раздельной архитектурой.

Мой случай – Wordpress, в котором есть ядро и есть отдельно /plugins и /themes. Ядро постоянно, стабильно и ИИ его не трогает, вся работа по разработке продукта ведётся через плагины (бэк) и темы (фронт). Всё ограничено, порционно, версионно и контролируемо. Сэкономишь ИИ мозги и себе токены и не будешь тратить 80% времени/нервов/токенов на ненужную проверку и переписывание одного и того же места (ядра) ради мелких фиксов по сто раз.

– Смотри в сторону Single Page Application с раздельными .js под каждую фичу/"страницу". Это снова про ограниченность, версионность и контроль работы для тебя и ИИ. Плюс, так снова правильно для архитектуры, когда приложения общаются между собой раздельно, а не один .js управляет всем и сразу (создавая конфликты и глюки сразу во всём).

– 1 фича-апдейт = 1 чат в рамках 1 проекта и не будет никаких галлюцинаций. Апгрейдишь фичу – в первом промпте прикладывай архив с исходником последней stable версии фичи с прода (или коннекть GitHub). Апгрейднул – CHANGELOG - чат закончен.

Иначе уже спустя 2 часа чата машина начинает путаться в данных/коде и любая попытка разрулить лишь закапывает её и тебя в галлюцинации и баги ещё больше.

– Фиксы/баги можно объединять в одном чате, ИИ лучше видит контекст и находит связи между ними, но лучше тоже не копить и делить по stable версиям.

– Объясняй всё для ИИ наглядным языком, уточняй контекст, расшифровывай механики, стейты и позиционирование объектов на странице c их идентификацией.

Помогает: а) единый словарь терминов и понятий для фич/механик в твоём продукте (определимся с терминами и понятиями, классика, 2018 год); б) через Console смотреть на название их css-стилей. Потому что даже одна оговорка или размытое понятие может быть непонятно для ИИ и она начнёт додумывать его за тебя, что приведет её к галлюцинации.

Твой промпт = тех. задание, "нет ТЗ = результат ХЗ", ещё одна классика середины нулевых передаёт привет из прошлого.

– Прикладывай к промптам скрины с выделенными ошибками, поясняя текстом что на скринах. Несколько раз Claude сама нашла на скрине места с дублирующейся багой, которые я проглядел, поняла их и это помогло ей пофиксить 2+ баги разом.

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

– Для сложных фич/механик вначале проси у ИИ описание двух вариантов возможных решений, потом проси третий вариант, потом проси придумать оптимальное и подходящее решение на основе этих трёх. У меня во всех случаях ИИ выбирала третий вариант и с первой итерации писала его без серьёзных ошибок, имея на руках полный контекст что ей делать и что не делать.

– CHANGELOG MD – ключ и мост между релизами. После каждого успешного апдейта (чата) проси ИИ писать: а) интро проекта с точки зрения обновлённого кода/архитектуры; б) выжимку по изменениям и включай их в него, прикладывая в новом чате и прося читать все изменения для понимания контекста.

Потому что ИЗМЕНЕНИЯ = КОНТЕКСТ. Веди его ручками, чтобы не жечь лишний раз каждым апдейтом токены на разрастающийся док (старую инфу можно нужно подчищать).

– Скиллы и прочие "ты в роли" зашей в CHANGELOG один раз, а не в системный промпт/скилс, чтобы не вызывать их скрыто в каждом промпте, прожигая твои токены (ты же не Ланнистер).

– Слышал, что рефакторить код лучше через разные модели, устраивать оркестрации, подключать тулзы и прочее. Я до этого ещё не дошел, Claude отлично справляется со всем своим добром сама прямо через окно чата и обмен файлами контекстом.

В общем, как-то так. Впервые столкнулся с тем, что код и прод убегают вперёд дизайна. Думаю скоро подрубить github, а там и до VS Code + copilot не за горами. Я знал, что рано или поздно мы перейдем и на эту дрянь.

Эпоха SaaS меняется, а вместе с ней и роль тех, кто управляет её решениями

Мы видим, что происходит с теми же Figma и Notion – ИИ-индустрия автоматизирует создание интерфейсов и функционала сервисов (и сами сервисы) за считанные дни, поэтому растет ценность специалистов, способных проектировать сложную простую логику процессов и управлять продуктом как Системой.

Чтобы стать тем самым «оператором-оркестратором», особенно в ИИ-сфере, нужны передовые знания и много практики.

22 апреля в 19:00 мск на онлайн-дне открытых дверей магистратуры «Управление продуктом в цифровом бизнесе» ИТМО в партнерстве с Яндекс Практикумом будут обсуждать, как собрать необходимые специалисту навыки системно.

👉 Зарегистрироваться на встречу

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

Новая структура любого отдела в компании

Всего 3 типа живых участников:

0. ИИ-агент

1. Архитектор

Те, кто разрабатывают операционные ИИ-процедуры, которые обучают и задают принципы ИИ-работы процессов в продукте и для команды.

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

2. Оператор

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

3. General Manager

Тот-Кто-Отвечает-За-Продукт. Вкус, Видение, Свет.

Два пути, Семь врат

⛩️Путь внедрения новых функций

1. Архитектор определяет задачу как структурированное задание с полным набором: 1) контекста (данных/метрик/кода/отзывов/чего угодно); 2) целями; 3) ограничениями.

↓

2. ИИ-агент декомпозирует задачу, планирует реализацию, пишет код и генерирует собственные тесты.

↓

3. Создаётся запрос на слияние (PR). Он проходит три этапа проверки Claude. Оператор проверяет всё на краткосрочные/долгосрочные риски, а не просто корректность ответов ИИ.

↓

4. CI проверяет типизацию, линтинг, модульные тесты, интеграционные тесты, сквозные тесты.

↓

5. Очередь слияния выполняет перебазирование и выполняет слияние, если оно успешно.

↓

6. Включается контроль функциональности для команды. Постепенное развёртывание в процентах. Мониторинг метрик и обратной связи. Шестифазный конвейер развёртывания продвигает проект по всем этапам исследования/дизайна/разработки/производства с тестированием на каждом этапе.

↓

7. Доступен аварийный выключатель в случае ухудшения работы и автоматический откат для серьёзных проблем.

⛩️Путь исправления ошибок =

1. CloudWatch и Sentry обнаруживают ошибки.

↓

2. Система сортировки Claude оценивает серьёзность, создаёт линейную задачу с полным контекстом расследования.

↓

3. Оператор проводит собственное расследование.

↓

4. ИИ уже провёл ИИ-диагностику и предложил исправления. Оператор проверяет и внедряет исправление.

↓

5. Тот же процесс проверки, развёртывания и мониторинга.

↓

6. Система обработки запросов повторно проверяет ошибку.

↓

7. Если проблема решена, заявка автоматически закрывается.

Оба пути используют один и тот же конвейер. Одна система. Один стандарт.


∞ Петля самовосстановления на основе обратной связи ∞

Это – центральный элемент системы.

1. Каждое утро запускается автоматизированный процесс проверки работоспособности. Claude Sonnet опрашивает CloudWatch, анализирует паттерны (ошибок) во всех сервисах и формирует сводный отчёт о состоянии системы, который отправляется команде через мессенджер (и никому не приходится запрашивать его вручную).

↓

2. Час спустя запускается механизм триажа (система ИИ, которая автоматически оценивает и распределяет поступающие задачи по приоритету, важности или срочности).

↓

3. Он кластеризует ошибки, возникшие в production-среде (на основе данных из CloudWatch и Sentry), оценивает каждый кластер по девяти критериям критичности и автоматически создает тикеты на расследование в системе Linear.

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

↓

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

↓

5. Когда инженер отправляет исправление (fix), его обработку выполняет тот же самый конвейер. Три итерации проверки с участием Claude оценивают запрос на слияние (PR). Система CI выполняет валидацию.

6. После завершения развертывания механизм триажа повторно проверяет данные в CloudWatch.

7. Если исходные ошибки устранены, соответствующий тикет в Linear закрывается автоматически.

Так семиэтапный конвейер развёртывания последовательно продвигает изменения через среды разработки и production, выполняя тестирование на каждом этапе.

⚠️ Каждый ИИ-инструмент отвечает за выполнение лишь одной конкретной фазы и ни один инструмент не пытается взять на себя абсолютно всё.

Этот ежедневный цикл формирует "петлю самовосстановления", в рамках которой ошибки выявляются, проходят триаж, исправляются и верифицируются с минимальным участием человека.

«ИИ будет создавать запросы на слияние, а человеку останется лишь просматривать их, чтобы убедиться в отсутствии каких-либо рисков».

Входите тесными вратами, потому что широки́ врата и пространен путь, ведущие в погибель, и многие идут ими; потому что тесны́ врата и узок путь, ведущие в жизнь, и немногие находят их.