ИИ для продакта & CPO | Влад Прошинский
Как управлять 20 ИИ‑агентами без хаоса Вы уже запустили первого агента. Потом второго. А через месяц — пять VPS, три локальных модели и куча API‑ключей в разных файлах. Гемор, да? В 2026 году компании внедряют ИИ‑агентов поэтапно: пилот за 3–6 месяцев, затем…
↓↓↓
Кто-то уже использует управление ИИ агентами?
В интервью, чувак управляет командой, на длинной дистанции в Devin .
harness решает. Больше не нужно самому что-то настраивать/переключать.
роутинг решает (cursor выпустили роутер, -50% token saving)
Кто-то уже использует управление ИИ агентами?
В интервью, чувак управляет командой, на длинной дистанции в Devin .
harness решает. Больше не нужно самому что-то настраивать/переключать.
роутинг решает (cursor выпустили роутер, -50% token saving)
YouTube
Most Valuable Skill of 2026: Managing AI Agents
I welcome Ryan Carson back to the show to turn anyone into a world-class agent operator. Ryan spent 25 years founding companies, scaled Treehouse to around 110 employees and a million learners, and now runs Untangle, an AI divorce agent for family law firms…
👍1
Практический гайдбук для AI PM-ов
В 2026 году РМ полностью контролирует процесс оценки, начиная с определения критериев и заканчивая защитой ее результатов.
Переосмысление UX: доверие — это показатель, который никто не измеряет.
В 2026 году РМ полностью контролирует процесс оценки, начиная с определения критериев и заканчивая защитой ее результатов.
Переосмысление UX: доверие — это показатель, который никто не измеряет.
👍5
Новый агент Buzz прекрасен
UI как у Slack, где раньше ты переписывался с коллегами, а сейчас – ставишь задачи ИИ агентам.
Большой плюс: можно выбирать harness, кроме LLM (Claude Code, Buzz, Codex,
Они могут создавать проекты, ветки, у них тесная интеграция с Git, поэтому могут сами делать PR.
Под капотом — журнал событий, написан на Rust.
🔗 https://github.com/block/buzz
=======
+ большой плюс — децентрализованный протокол Nostr , как использовать:
Это очень простой пример, но вы видите как они прокладывают суть к настоящей открытости и возможностям открытых и локальных моделей.
UI как у Slack, где раньше ты переписывался с коллегами, а сейчас – ставишь задачи ИИ агентам.
Большой плюс: можно выбирать harness, кроме LLM (Claude Code, Buzz, Codex,
Они могут создавать проекты, ветки, у них тесная интеграция с Git, поэтому могут сами делать PR.
Под капотом — журнал событий, написан на Rust.
=======
+ большой плюс — децентрализованный протокол Nostr , как использовать:
Вы хотите свой OpenSource LLM (Kimi K3 например), но чтобы его установить, нужно очень дорогое железо, которое вам не по карману. Вы можете собраться с друзьями, купить железо → подключаетесь → делитесь вычислительными ресурсами, и все вы можете использовать одну модель на одном устройстве, даже если общаетесь с разных устройств.
Это очень простой пример, но вы видите как они прокладывают суть к настоящей открытости и возможностям открытых и локальных моделей.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Исследование роли Product в эпоху AI (матрица навыков)
У Миши Карпова вышло крутое исследование по AI скиллам РМ
https://drive.google.com/file/d/1BYiJxIvuEiKYZ6qBeNQfo5GMrziIPqwA/
У Миши Карпова вышло крутое исследование по AI скиллам РМ
https://drive.google.com/file/d/1BYiJxIvuEiKYZ6qBeNQfo5GMrziIPqwA/
5 типов личностей по ур. готовности к внедрению ИИ
Анализ 5 ключевых аспектов, влияющих на готовность людей к интеграции искусственного интеллекта в рабочую среду.
- AI enthusiasts (энтузиасты ИИ)
- Мотивированы инновациями, эффективностью, конкурентным преимуществом
- Активно хотят внедрять и использовать ИИ
- Часто становятся внутренними драйверами (champions)
- AI curious (любопытные к ИИ)
- Интерес есть, но без слепой веры
- Ждут доказательств, ответов на практические вопросы
- Готовы пробовать, но в безопасной среде (sandbox)
- AI cautious (осторожные)
- Думают про риски: безопасность данных, этика, влияние на людей
- Хотят контроль и участие человека (human-in-the-loop)
- Не против ИИ, но только при строгих ограничениях
- AI sceptics (скептики)
- Не верят хайпу, требуют доказательств эффективности
- Опираться будут на эмпирику (A/B тесты, сравнения)
- Часто это рациональные и опытные специалисты
- AI opposed (противники)
- Сильное сопротивление из-за страхов (потеря работы, контроль, слежка)
- Могут полностью отказываться использовать ИИ
- Требуют работы с глубинными тревогами
---
Интерпретация (для продукта/внедрения):
- Это сегментация пользователей по readiness, а не по роли
- Основной барьер — психология и доверие, а не технология
- Внедрение ИИ = change management + behavioral design
Анализ 5 ключевых аспектов, влияющих на готовность людей к интеграции искусственного интеллекта в рабочую среду.
- AI enthusiasts (энтузиасты ИИ)
- Мотивированы инновациями, эффективностью, конкурентным преимуществом
- Активно хотят внедрять и использовать ИИ
- Часто становятся внутренними драйверами (champions)
- AI curious (любопытные к ИИ)
- Интерес есть, но без слепой веры
- Ждут доказательств, ответов на практические вопросы
- Готовы пробовать, но в безопасной среде (sandbox)
- AI cautious (осторожные)
- Думают про риски: безопасность данных, этика, влияние на людей
- Хотят контроль и участие человека (human-in-the-loop)
- Не против ИИ, но только при строгих ограничениях
- AI sceptics (скептики)
- Не верят хайпу, требуют доказательств эффективности
- Опираться будут на эмпирику (A/B тесты, сравнения)
- Часто это рациональные и опытные специалисты
- AI opposed (противники)
- Сильное сопротивление из-за страхов (потеря работы, контроль, слежка)
- Могут полностью отказываться использовать ИИ
- Требуют работы с глубинными тревогами
---
Интерпретация (для продукта/внедрения):
- Это сегментация пользователей по readiness, а не по роли
- Основной барьер — психология и доверие, а не технология
- Внедрение ИИ = change management + behavioral design
👍1
bluedoor — API для доступа к вакансиями по всему миру realtime
1,921,813 вакансий. 60,631 работодателей.
Берем готовый промпт и вставляем в claude code и создаем artifacts
Free API key на 100 запросов в сек.:
Авторизация автоматически придет на имейл
1,921,813 вакансий. 60,631 работодателей.
Берем готовый промпт и вставляем в claude code и создаем artifacts
Free API key на 100 запросов в сек.:
# bluedoor Job Postings API — get a free API key (100 requests/sec, burst of 500).
# 1. Request a one-time code, sent to your email:
curl -X POST "https://api.bluedoor.sh/job-postings/v1/auth/otp" \
-H "content-type: application/json" \
-d '{"email": "YOUR_EMAIL"}'
# 2. Verify the 6-digit code from the email and create a key in one step:
curl -X POST "https://api.bluedoor.sh/job-postings/v1/auth/verify" \
-H "content-type: application/json" \
-d '{"email": "YOUR_EMAIL", "code": "CODE_FROM_EMAIL", "create_key": true, "label": "my key"}'
# The response includes api_key. Send it on every request as:
# Authorization: Bearer <api_key>
Авторизация автоматически придет на имейл
👍4
Кто составит компанию?
3 дня, 17-19 ноября, B2B аудитория:
руководители, основатели и инвесторы
🔗 ссылка
Вот ещё мощнее: Dubai AI festival
🔗 ссылка
26-27 October 2026
===
3 дня, 17-19 ноября, B2B аудитория:
руководители, основатели и инвесторы
🔗 ссылка
Вот ещё мощнее: Dubai AI festival
🔗 ссылка
26-27 October 2026
===
Дубайский саммит по искусственному интеллекту находится в самом центре Всемирной выставки технологий искусственного интеллекта в Дубае — корпоративного, ориентированного на бизнес мероприятия, созданного для тех, кому необходимо перейти от любопытства к ИИ к результатам. Вместо абстрактной теории программа построена вокруг реальных внедрений, измеримых результатов и связей, которые превращают идеи в проекты. Если вы искали информацию о Саммите по искусственному интеллекту в Дубае или Саммите по искусственному интеллекту в ОАЭ, это флагманское мероприятие, которое обязательно нужно включить в свой календарь на 2026 год.
В рамках мероприятия, включающего в себя основные доклады, панельные дискуссии, прикладные сессии, выставку инноваций и специальный саммит для предпринимателей и инвесторов, каждый потраченный вами час будет направлен на достижение бизнес-результата — включение поставщика в шорт-лист, заключение партнерского соглашения, уточнение стратегии или начало переговоров об инвестициях.
👍1
Перевел кодинг агенты на DeepSeek-v4-Flash-0731
Он шустрый, дешевый и не хуже Kimi K3 или Fable.
Модель уровня GLM-5.2 / Opus 4.8 / GPT-5.5, то есть лучшее что было доступно в мире на апрель 2026 года, но по цене в $0.28 за миллион токенов, то есть в ~100 раз дешевле.
Теперь буду бесконечно гонять pipeline /goal в VS code (GLM 5.2 быстро улетал).
Он шустрый, дешевый и не хуже Kimi K3 или Fable.
Модель уровня GLM-5.2 / Opus 4.8 / GPT-5.5, то есть лучшее что было доступно в мире на апрель 2026 года, но по цене в $0.28 за миллион токенов, то есть в ~100 раз дешевле.
Теперь буду бесконечно гонять pipeline /goal в VS code (GLM 5.2 быстро улетал).
Ещё обновил 95% всех своих SKILL-s под Opus 5
Официальный migration guide Anthropic прямо указывает:
У меня в PersonalOS = 198 скиллов, 185 скиллов попало под апдейт.
Выявленные legacy-паттерны:
1. Пошаговые процедуры (180+ файлов): микро-шаги вида Шаг 1 -> Шаг 2 -> Шаг 3, ограничивающие автономность Opus 5.
2. Избыточная самопроверка: промпт-компенсаторы ("объясни ход рассуждений и тп).
3. Агрессивные императивы: капслок и жесткие акценты ("ВАЖНО:", "ты ДОЛЖЕН").
4. Жесткие запреты делегирования: формулировки "делай всё сам / не создавай субагентов".
и т.п.
Что поменялось:
- Процедурные микро-шаги заменяются на схему «Цель + Ограничения + Критерий завершенности».
- Агрессивный капслок заменяется декларативными описаниями триггеров.
- Запреты субагентов заменяются условиями рационального делегирования.
- Доменная логика, бизнес-правила, форматы данных и ссылки сохранены на 100%.
- Удаление императивов и давления: формулировки ВАЖНО: ты ДОЛЖЕН...
- Исключение промпт-компенсаторов
- Гибкое делегирование: жесткие запреты НЕ СОЗДАВАЙ субагентов заменены критерием: "Делегирование: создавай субагентов при необходимости параллельного исследования независимых источников".
- Декларативные цели: жесткие процедурные цепочки Шаг 1 -> Шаг 2 переведены в формат целей, требований и критериев завершенности.
Промпт для агента
Официальный migration guide Anthropic прямо указывает:
старые инструкции по верификации и пошаговые процедуры, написанные для Opus 4.x, могут ухудшать качество вывода на новых моделях, потому что модель теперь справляется с этим сама. Это не гипотеза и не маркетинг сторонних блогов — формулировка взята из раздела "Recommended changes" официального migration guide.
У меня в PersonalOS = 198 скиллов, 185 скиллов попало под апдейт.
Выявленные legacy-паттерны:
1. Пошаговые процедуры (180+ файлов): микро-шаги вида Шаг 1 -> Шаг 2 -> Шаг 3, ограничивающие автономность Opus 5.
2. Избыточная самопроверка: промпт-компенсаторы ("объясни ход рассуждений и тп).
3. Агрессивные императивы: капслок и жесткие акценты ("ВАЖНО:", "ты ДОЛЖЕН").
4. Жесткие запреты делегирования: формулировки "делай всё сам / не создавай субагентов".
и т.п.
Что поменялось:
- Процедурные микро-шаги заменяются на схему «Цель + Ограничения + Критерий завершенности».
- Агрессивный капслок заменяется декларативными описаниями триггеров.
- Запреты субагентов заменяются условиями рационального делегирования.
- Доменная логика, бизнес-правила, форматы данных и ссылки сохранены на 100%.
- Удаление императивов и давления: формулировки ВАЖНО: ты ДОЛЖЕН...
- Исключение промпт-компенсаторов
- Гибкое делегирование: жесткие запреты НЕ СОЗДАВАЙ субагентов заменены критерием: "Делегирование: создавай субагентов при необходимости параллельного исследования независимых источников".
- Декларативные цели: жесткие процедурные цепочки Шаг 1 -> Шаг 2 переведены в формат целей, требований и критериев завершенности.
Промпт для агента
Задача: аудит и переписывание всех скиллов в папке под новую модель (Opus 5, было Opus 4.x).
Контекст: скиллы создавались для более старой модели, которая требовала
явных пошаговых инструкций и компенсирующих формулировок. Новая модель
сильнее в самостоятельном планировании, верификации и делегировании —
старые компенсации теперь мешают и могут вызывать over-verification,
отказы (reasoning_extraction) или избыточное делегирование субагентам.
Шаг 1. Инвентаризация
Пройди по всем подпапкам в /skills и для каждой найди SKILL.md.
Составь список: путь к файлу, размер, дата последнего изменения.
Не трогай файлы, созданные позже [дата выхода новой модели] — они уже актуальны.
Шаг 2. Grep-аудит триггерных фраз
В каждом SKILL.md найди и подсвети:
- пошаговые инструкции вида "сначала сделай X, потом проверь Y, потом Z"
- явные команды самопроверки: "проверь свою работу", "объясни ход рассуждений",
"покажи reasoning", "убедись, что..."
- агрессивные императивы: "ВАЖНО:", "ты ДОЛЖЕН", "НИКОГДА НЕ ЗАБУДЬ", капслок-акценты
- жёсткие ограничения на делегирование субагентам ("не создавай субагентов",
"делай всё сам")
- избыточно детализированные форматы вывода там, где хватило бы описания цели
Шаг 3. Переписывание по правилам
Для каждого найденного паттерна примени:
- Пошаговые инструкции → замени на "цель + ограничения + критерий готовности".
Убери промежуточные шаги, которые модель может спланировать сама.
- Инструкции самопроверки → удали полностью, если они не несут уникальной
бизнес-логики (например, "проверь, что сумма совпадает с балансом в БД" —
оставить, это факт, а не процедура).
- Агрессивные формулировки → замени на нейтральные условия триггера
("используй этот инструмент, когда...").
- Ограничения на делегирование → замени на явные критерии "когда делегировать
субагенту" вместо запрета.
- Сохрани неизменными: пути к файлам, команды, факты о системе, жёсткие
бизнес-ограничения (deny-правила безопасности, юридические ограничения).
Шаг 4. Формат вывода
Для каждого скилла выведи:
1. Путь к файлу
2. Список найденных проблемных фраз (цитата + причина)
3. Диff: было → стало
4. Итоговую переписанную версию SKILL.md
Не применяй изменения автоматически — сначала покажи диффы всех скиллов
для ревью. После моего подтверждения — перезапиши файлы.
Шаг 5. Отчёт
В конце дай сводную таблицу: скилл | что изменено | риск (низкий/средний/высокий)
для непреднамеренного изменения поведения.
🔥3
Graph Engineering. Anthropic починили главный баг мульти-агентов
Графы агентов — новый стандарт. Быстрее, масштабнее, умнее.
Но есть проблема: один сбой в ноде → портит весь результат. И вы даже не понимаете где именно.
Если вы уже пробовали multi-agent пайплайны — вы это видели.
Что происходит под капотом
Раньше: loop engineering
- Один агент
- Линейный процесс
- Шаг → проверка → следующий шаг
Теперь: graph engineering
- Десятки агентов параллельно
- Каждая нода — отдельная задача
- Скорость выше, покрытие лучше
Но как всегда платим мы за этот праздник. Цена выполнены задачи на круг выше.
- Токены улетают быстрее
- Дебаг почти невозможен
- Ошибка масштабируется на весь граф
Ключевой инсайт Anthropic
Проблема не в графах.
Проблема — в валидации.
Если проверка слабая → граф деградирует экспоненциально.
Что они сделали (и что стоит повторить)
1) Разделили валидацию на типы
- Standalone — глубокая проверка финального результата (thermo-nuclear-code-quality-review)
- Embedded — проверка внутри каждого шага
- Second opinion — независимая ревизия без контекста
- использовать Chrome headless вместо тестов в обычном Chrome, так как это дороже в токенах.
Команды:
/verify (анализирует код от начала до конца и подтверждает, что он работает)
toolchain – цепочка инструментов, которая подтверждает.
/review skill для проверки кода
2) Добавили orchestration layer
- Один skill управляет всеми проверками
- Запускает их параллельно
- Собирает единый отчёт
3) Критический момент: модель для проверки
- Дешёвые модели → больше ложных ошибок
- Дорогие модели → меньше, но точнее
- Экономия здесь = деградация всей системы
Реальный кейс:
Haiku нашёл "много багов" → половина ложные
Opus нашёл меньше → но релевантно
Вывод: дешёвая проверка = двойная работа
Практическое применение
Где это даёт максимум ROI:
- Генерация кода → проверка архитектуры + тесты
- Контент-пайплайны → фактчекинг + стиль
- Data pipelines → валидация данных на каждом этапе
- AI-ассистенты → контроль галлюцинаций
Фреймворк, который можно забрать
- Разбей задачу на ноды
- Добавь embedded проверку в каждую
- Повесь second opinion на критические шаги
- Сделай orchestrator skill
- Самую сильную модель — только на проверку
===
В графах выигрывает не тот, у кого больше агентов.
А тот, у кого лучше система валидации.
И это уже не про промпты.
Это про архитектуру.
🎞 Подробнее в видео
Графы агентов — новый стандарт. Быстрее, масштабнее, умнее.
Но есть проблема: один сбой в ноде → портит весь результат. И вы даже не понимаете где именно.
Если вы уже пробовали multi-agent пайплайны — вы это видели.
Что происходит под капотом
Раньше: loop engineering
- Один агент
- Линейный процесс
- Шаг → проверка → следующий шаг
Теперь: graph engineering
- Десятки агентов параллельно
- Каждая нода — отдельная задача
- Скорость выше, покрытие лучше
Но как всегда платим мы за этот праздник. Цена выполнены задачи на круг выше.
- Токены улетают быстрее
- Дебаг почти невозможен
- Ошибка масштабируется на весь граф
Ключевой инсайт Anthropic
Проблема не в графах.
Проблема — в валидации.
Если проверка слабая → граф деградирует экспоненциально.
Что они сделали (и что стоит повторить)
1) Разделили валидацию на типы
- Standalone — глубокая проверка финального результата (thermo-nuclear-code-quality-review)
- Embedded — проверка внутри каждого шага
- Second opinion — независимая ревизия без контекста
- использовать Chrome headless вместо тестов в обычном Chrome, так как это дороже в токенах.
Команды:
/verify (анализирует код от начала до конца и подтверждает, что он работает)
toolchain – цепочка инструментов, которая подтверждает.
/review skill для проверки кода
2) Добавили orchestration layer
- Один skill управляет всеми проверками
- Запускает их параллельно
- Собирает единый отчёт
3) Критический момент: модель для проверки
- Дешёвые модели → больше ложных ошибок
- Дорогие модели → меньше, но точнее
- Экономия здесь = деградация всей системы
Реальный кейс:
Haiku нашёл "много багов" → половина ложные
Opus нашёл меньше → но релевантно
Вывод: дешёвая проверка = двойная работа
Практическое применение
Где это даёт максимум ROI:
- Генерация кода → проверка архитектуры + тесты
- Контент-пайплайны → фактчекинг + стиль
- Data pipelines → валидация данных на каждом этапе
- AI-ассистенты → контроль галлюцинаций
Фреймворк, который можно забрать
- Разбей задачу на ноды
- Добавь embedded проверку в каждую
- Повесь second opinion на критические шаги
- Сделай orchestrator skill
- Самую сильную модель — только на проверку
===
В графах выигрывает не тот, у кого больше агентов.
А тот, у кого лучше система валидации.
И это уже не про промпты.
Это про архитектуру.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
n8n VS code
Во 2 полугодии 2026 до сих пор обсуждают насколько нужен n8n , если уже есть готовые и продвинутые AI агенты, которые могут собирать готовые решения. Кто-то говорит что n8n не нужен. В этом🎞 интервью подробно разобрана практическая сторона этого вопроса, потому что обсуждать можно бесконечно, а есть реальные задачи, под которые на практике подбираются свои инструменты. Ведь код тоже бывает разный.
Шпаргалка когда что выбирать:
Выбирай Код если:
- у вас есть сервер чтобы его развернуть
- вам базово неплохо бы понимать код
- вам надо где-то хранить ключи (в gitHub не вариант)
- не безопасно (нужны доп. библиотеки)
- авторизацию и ролевую модель нужно отдельно делать
- вероятность багов выше → нужно отлаживать (80% вашего времени и токенов)
- возня с БД (и понимать какая для чего нужна)
между кодом и n8n есть PaaS платформы типа Railway (у меня там 2 проекта крутится), в целом хорошее решение для чего-то более гибкого
Выбирай n8n если:
- нужно чтобы все было наглядно
- все детерминировано
- процесс последовательный (если есть откат — тебе нужен LangGraph / CrewAI)
- решение можно воспроизвести 1:1
- можно быстро перенести/поделиться рабочим процессом
- есть версионирование
- встроенные простые evals
в корпоративном секторе важна наблюдаемость (observability), безопасность, воспредводимость, масштабиримость.
Во 2 полугодии 2026 до сих пор обсуждают насколько нужен n8n , если уже есть готовые и продвинутые AI агенты, которые могут собирать готовые решения. Кто-то говорит что n8n не нужен. В этом
Шпаргалка когда что выбирать:
Выбирай Код если:
- у вас есть сервер чтобы его развернуть
- вам базово неплохо бы понимать код
- вам надо где-то хранить ключи (в gitHub не вариант)
- не безопасно (нужны доп. библиотеки)
- авторизацию и ролевую модель нужно отдельно делать
- вероятность багов выше → нужно отлаживать (80% вашего времени и токенов)
- возня с БД (и понимать какая для чего нужна)
между кодом и n8n есть PaaS платформы типа Railway (у меня там 2 проекта крутится), в целом хорошее решение для чего-то более гибкого
Выбирай n8n если:
- нужно чтобы все было наглядно
- все детерминировано
- процесс последовательный (если есть откат — тебе нужен LangGraph / CrewAI)
- решение можно воспроизвести 1:1
- можно быстро перенести/поделиться рабочим процессом
- есть версионирование
- встроенные простые evals
в корпоративном секторе важна наблюдаемость (observability), безопасность, воспредводимость, масштабиримость.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1
Ваш ИИ-агент страдает от синдрома "первого правильного ответа" — и это стоит вам денег
Спросите Claude Code или Codex "накидай идеи" — и получите три варианта одной и той же мысли, просто пересказанной другими словами.
Это не баг конкретной модели. Это системная проблема всех LLM-агентов.
Почему агенты не умеют брейнштормить
Модель обучена находить самый частый паттерн в данных. Частый ответ = хороший ответ, так она учится. Поэтому при ideation агент выдает "безопасный" вариант — тот, что видел чаще всего.
Хуже того: все идеи прокручиваются в одном контекстном окне. Они смешиваются друг с другом, контекст забивается шумом, и качество мышления падает вместо того, чтобы расти.
Агент физически не может оценить идеи отдельно друг от друга. Отсюда и три варианта одной формулировки.
Решение — дать агенту ADHD
Звучит странно, но именно рассеянное внимание оказалось суперспособностью для ИИ-агентов.
Новый skill adhd (уже собрал кучу звезд на GitHub за несколько дней)
По сути он строит tree of thought — дерево мышления:
- Задача разбивается на отдельные ветки
- Каждая ветка — свой агент, свой изолированный контекст, своя "рамка" (frame) для взгляда на проблему
- Агенты не видят друг друга и не влияют друг на друга
- Critic-агент (промпт: "скептический старший инженер") оценивает каждую идею по трем метрикам: novelty (новизна), viability (реализуемость), fit (соответствие задаче)
- Слабые идеи отсеиваются, сильные уходят в шортлист с разбором рисков
Где это реально работает
Тест-кейс 1 — TDD (test-driven development). Обычно агент пишет тесты по тем же паттернам, что и всегда, пропуская edge cases. После запуска skill команда получила отчет с оценками вида N9/V8/F10 (novelty/viability/fit) по трем разным стратегиям тестирования — включая проверки производительности, которые агент в обычном режиме даже не рассматривает.
Тест-кейс 2 — предзапуск фичи на живом продукте с активной базой пользователей. Skill проанализировал приложение, сгенерировал около 30 идей, оставил топ-3 и — что важно — нашел функции, обещанные в PRD, но так и не реализованные. Это баг, который команда бы выкатила в прод и получила отток пользователей.
Важный нюанс
Skill не пишет код и не чинит баги сам. Он выдает стратегию и находки. Реализацию все равно делает ваш агент по вашей команде.
Для продакта это означает: перед стратегическими решениями (архитектура тестов, UX-ревью перед релизом) можно получить веер реально разных вариантов вместо одного "безопасного" — с оценкой рисков за секунды, а не за часы брейншторма с командой.
Установка:
npx skills add UditAkhourii/adhd
для Claude Code – claude.md , Codex – agents.md и связать 3 файла:
@agents.md
@docs/prd.md
@docs/tech-spec.md
и запустить /adhd
Спросите Claude Code или Codex "накидай идеи" — и получите три варианта одной и той же мысли, просто пересказанной другими словами.
Это не баг конкретной модели. Это системная проблема всех LLM-агентов.
Почему агенты не умеют брейнштормить
Модель обучена находить самый частый паттерн в данных. Частый ответ = хороший ответ, так она учится. Поэтому при ideation агент выдает "безопасный" вариант — тот, что видел чаще всего.
Хуже того: все идеи прокручиваются в одном контекстном окне. Они смешиваются друг с другом, контекст забивается шумом, и качество мышления падает вместо того, чтобы расти.
Агент физически не может оценить идеи отдельно друг от друга. Отсюда и три варианта одной формулировки.
Решение — дать агенту ADHD
Звучит странно, но именно рассеянное внимание оказалось суперспособностью для ИИ-агентов.
Новый skill adhd (уже собрал кучу звезд на GitHub за несколько дней)
Этот скилл предназначен для параллельного нестандартного брейншторминга и поиска архитектурных/продуктовых решений (Parallel Divergent Ideation).
Главная проблема обычных нейросетей — они выдают первыми 3 стандартных «учебниковых» ответа, которые опытный инженер придумывает за 30 секунд. Скилл ADHD заставляет модель намеренно выйти за рамки тривиальных решений в нетривиальную зону, объединяя генерацию из нетипичных уголков с жесткой фильтрацией и критикой.
По сути он строит tree of thought — дерево мышления:
- Задача разбивается на отдельные ветки
- Каждая ветка — свой агент, свой изолированный контекст, своя "рамка" (frame) для взгляда на проблему
- Агенты не видят друг друга и не влияют друг на друга
- Critic-агент (промпт: "скептический старший инженер") оценивает каждую идею по трем метрикам: novelty (новизна), viability (реализуемость), fit (соответствие задаче)
- Слабые идеи отсеиваются, сильные уходят в шортлист с разбором рисков
Где это реально работает
Тест-кейс 1 — TDD (test-driven development). Обычно агент пишет тесты по тем же паттернам, что и всегда, пропуская edge cases. После запуска skill команда получила отчет с оценками вида N9/V8/F10 (novelty/viability/fit) по трем разным стратегиям тестирования — включая проверки производительности, которые агент в обычном режиме даже не рассматривает.
Тест-кейс 2 — предзапуск фичи на живом продукте с активной базой пользователей. Skill проанализировал приложение, сгенерировал около 30 идей, оставил топ-3 и — что важно — нашел функции, обещанные в PRD, но так и не реализованные. Это баг, который команда бы выкатила в прод и получила отток пользователей.
Важный нюанс
Skill не пишет код и не чинит баги сам. Он выдает стратегию и находки. Реализацию все равно делает ваш агент по вашей команде.
Для продакта это означает: перед стратегическими решениями (архитектура тестов, UX-ревью перед релизом) можно получить веер реально разных вариантов вместо одного "безопасного" — с оценкой рисков за секунды, а не за часы брейншторма с командой.
Установка:
npx skills add UditAkhourii/adhd
для Claude Code – claude.md , Codex – agents.md и связать 3 файла:
@agents.md
@docs/prd.md
@docs/tech-spec.md
и запустить /adhd
🔥2
Рост роли «AI Product Builder»
Традиционные PM-роли сокращаются (до 30% в целом и до 70% в SaaS), вместо них растёт гибридная роль Product Builder — человек, который сочетает product thinking, техническую грамотность, дизайн и быстро прототипирует/шиппит с помощью AI.
Количество таких специалистов резко выросло.
Организации перестраивают весь product lifecycle вокруг AI.
В статье Forbes (от 30 июля 2026): «The Rise of the AI Product Builder: The Future of Product Management»
репортят что традиционные product managers будут исчезать к 2030 году. По данным 2026 CPO Impact Report от Products That Count:
- ставки PM сократились на 30% в целом и на 70% в SaaS.
- При этом появилась и быстро растёт новая роль — Product Builder.
Драйверы
Старое ограничение (стоимость и скорость исполнения) исчезло. Новое узкое место — человеческое суждение: что строить, когда строить и как создавать реальную ценность.
ИИ может генерировать требования, прототипы, код, тесты и документацию. Но он не может решить:
- решает ли инициатива значимую проблему клиента
- соответствует ли она стратегии бизнеса
- является ли лучшим использованием ресурсов
===
Большинство компаний просто ускоряют старые процессы с помощью ИИ → получают лишь инкрементальный эффект. Топы перестраивают весь product lifecycle под возможности ИИ.
PM был в основном координатором
Product Builder фокусируется на создании outcomes, используя ИИ
Большинство организаций всё ещё построены вокруг функций (product / design / engineering с разными руководителями, метриками и процессами). Эти границы становятся всё менее оправданными.
Главный вопрос: что происходит, когда важнее становятся capabilities (способности), а не functions (функции)?
Что Builder PM не означает
Это не «один человек делает три работы (product + UX + engineering) за одну зарплату». Это не промоушен, а часто просто cost-cutting под красивой обёрткой. Хорошие инженеры любят инженерию и не хотят становиться PM. Дизайнеры не всегда готовы писать бизнес-кейсы. Ролевая компрессия имеет пределы.
Настоящий Builder PM — это product-менеджер, который умеет использовать ИИ, чтобы стать в разы эффективнее, не отказываясь от того, что делает его ценным. Это не единорог, а 10x PM. Речь о leverage (рычаге), а не о расширении обязанностей.
Правильный reframing
Вопрос не «как мне теперь заменить инженеров с помощью AI-кодинга?».
Вопрос: как использовать ИИ, чтобы стать 3x / 5x / 10x product-менеджером?
ИИ удешевил не только building, но и learning. Побеждает тот, кто быстрее учится (рынок, потребности..)
Discovery нельзя пропускать
Парадокс: в agent-heavy workflow нужно больше живого синхронизирования с инженерами и дизайнерами, а не меньше. Хорошие Builder PM:
- регулярно проводят customer interviews (не только на старте)
- строят постоянные каналы обратной связи
- сознательно защищают время на discovery даже при росте скорости
Главный рычаг — feedback loops
Большинство команд просто «используют AI-инструменты».
Лучшие строят системы, которые сами улучшаются.
Пример: fintech-команда добавила в конец каждого ИИ-ответа вопрос «Это было правильно?». Ответ пользователя сразу шёл в обучение модели. ИИ становился умнее прямо в потоке работы пользователей.
==
💡Задача лидера — не просто решать, куда вставить ИИ в продукт, а спроектировать всю систему product management, где ИИ создаёт рычаг, где риски, и где feedback loops делают систему умнее со временем. Именно так получается 10x.
Традиционные PM-роли сокращаются (до 30% в целом и до 70% в SaaS), вместо них растёт гибридная роль Product Builder — человек, который сочетает product thinking, техническую грамотность, дизайн и быстро прототипирует/шиппит с помощью AI.
Количество таких специалистов резко выросло.
Организации перестраивают весь product lifecycle вокруг AI.
В статье Forbes (от 30 июля 2026): «The Rise of the AI Product Builder: The Future of Product Management»
репортят что традиционные product managers будут исчезать к 2030 году. По данным 2026 CPO Impact Report от Products That Count:
- ставки PM сократились на 30% в целом и на 70% в SaaS.
- При этом появилась и быстро растёт новая роль — Product Builder.
Драйверы
Старое ограничение (стоимость и скорость исполнения) исчезло. Новое узкое место — человеческое суждение: что строить, когда строить и как создавать реальную ценность.
ИИ может генерировать требования, прототипы, код, тесты и документацию. Но он не может решить:
- решает ли инициатива значимую проблему клиента
- соответствует ли она стратегии бизнеса
- является ли лучшим использованием ресурсов
===
Большинство компаний просто ускоряют старые процессы с помощью ИИ → получают лишь инкрементальный эффект. Топы перестраивают весь product lifecycle под возможности ИИ.
PM был в основном координатором
Product Builder фокусируется на создании outcomes, используя ИИ
Большинство организаций всё ещё построены вокруг функций (product / design / engineering с разными руководителями, метриками и процессами). Эти границы становятся всё менее оправданными.
Главный вопрос: что происходит, когда важнее становятся capabilities (способности), а не functions (функции)?
Что Builder PM не означает
Это не «один человек делает три работы (product + UX + engineering) за одну зарплату». Это не промоушен, а часто просто cost-cutting под красивой обёрткой. Хорошие инженеры любят инженерию и не хотят становиться PM. Дизайнеры не всегда готовы писать бизнес-кейсы. Ролевая компрессия имеет пределы.
Настоящий Builder PM — это product-менеджер, который умеет использовать ИИ, чтобы стать в разы эффективнее, не отказываясь от того, что делает его ценным. Это не единорог, а 10x PM. Речь о leverage (рычаге), а не о расширении обязанностей.
Правильный reframing
Вопрос не «как мне теперь заменить инженеров с помощью AI-кодинга?».
Вопрос: как использовать ИИ, чтобы стать 3x / 5x / 10x product-менеджером?
ИИ удешевил не только building, но и learning. Побеждает тот, кто быстрее учится (рынок, потребности..)
Discovery нельзя пропускать
Парадокс: в agent-heavy workflow нужно больше живого синхронизирования с инженерами и дизайнерами, а не меньше. Хорошие Builder PM:
- регулярно проводят customer interviews (не только на старте)
- строят постоянные каналы обратной связи
- сознательно защищают время на discovery даже при росте скорости
Главный рычаг — feedback loops
Большинство команд просто «используют AI-инструменты».
Лучшие строят системы, которые сами улучшаются.
Пример: fintech-команда добавила в конец каждого ИИ-ответа вопрос «Это было правильно?». Ответ пользователя сразу шёл в обучение модели. ИИ становился умнее прямо в потоке работы пользователей.
==
💡Задача лидера — не просто решать, куда вставить ИИ в продукт, а спроектировать всю систему product management, где ИИ создаёт рычаг, где риски, и где feedback loops делают систему умнее со временем. Именно так получается 10x.
🔥1
Миллионом сейчас никого не удивишь 😁
Поделился своим опытом про «новое SEO» — AEO
https://www.rambler.ru/pro/professii/56863720-prodvizhenie-v-neyrosetyah-pravda-o-novoy-professii-i-dohodah-v-ney/
Поделился своим опытом про «новое SEO» — AEO
https://www.rambler.ru/pro/professii/56863720-prodvizhenie-v-neyrosetyah-pravda-o-novoy-professii-i-dohodah-v-ney/
👍1