ИИ для продакта & CPO | Влад Прошинский
AI SEO генератор на стероидах Прогаю с Fable AI SEO пайплайн, десятки суб-агентов собирают итоговый пайплайн, чтобы успеть до завтра (7 июля включена в подписки) Это пиздец, я ничего раньше подобного не делал 🤯 Ротаторы из 5 акков Tavily, Fireclaw, IndexNow…
↓↓↓
Главное, что вынес из AEO
страницы AEO должны быть гораздо более конкретными, чем SEO-страницы.
Вы не пишете «Лучшее руководство по контент-маркетингу». Вы пишете «Лучшее руководство по контент-маркетингу для логистических компаний в Москве»
1) Поставьте ответ на первое место. Не прячь суть буллетами. Никто не хочет "Дочитывать" до конца.
2) Дайте больше контекста. Добавьте 2-3 абзаца с примерами / определениями. Помогите движку понять, что ответ достоверен и полный
3) Добавить структуру вначале. LLM — ленивые читатели. Заголовки, пункты, таблицы. Каждый отрывок должен иметь смысл сам по себе.
4) Добавить FAQ (FAQ позволяют ответить на конкретные подвопросы, которые действительно задаёт ваша аудитория)
5) Включать оригинальные идеи. Данные, цитаты, исследования, которых нет ни у кого другого. Чистая новая информация — это то, что попадает в цитаты.
6) Соединить каждый поинт с продуктом. Если вы не сделаете связь, LLM не сделает этого.
7) Встраивать llm.txt. Это помогает AI движкам точно понять, что находится на вашей странице.
8) Добавить автора с данными, ссылкой на его LinkedIn, ссылки на др. статьи. (используй схему Person и укажи автора в схеме Article)
9) Оригинальные скрины, данные, датированные наблюдения («мы тестировали это в октябре 2025 года на 40 аккаунтах»).
10) Ссылки на собственные источники (это свидетельствует о дисциплинированности редакционной работы, как в инсте с reels)
11) Согласованность сущностей – ваш бренд, ваши авторы и ваши утверждения должны выглядеть одинаково на вашем сайте и др. площадках
12) LLM-ы оценивают сайты, которые выглядят как нишивые. Блог из 200 постов, охватывающий все аспекты вашей ниши, снижает эффективность по сравнению с 40 постами, углубленно изучающими одну подтему.
13) Развивайте другие площадки Reddit, YouTube, Linkedin
14) Добавляйте «обновлено» (обновляйте свои статьи, чтобы поддерживать их в актуальном состоянии)
15) Создавайте страницы с альтернативами, страницы интеграций, гайды по миграции, документацию с примерами и страницы «лучший инструмент для X задачи».
E-E-A-T — основа видимости в AEO и важнее чем в SEO (LLM отдают приоритет экспертности и внешней валидации (Wikipedia, Reddit, Linkedin, YouTube; в РФ это Дзен, прокаченные сайты, объем закупаемой рекламы в директе, POI на карте), а не ключевым словам. LLM меньше интересует PageRank и больше то, признает ли вас более широкий интернет как заслуживающий доверия источник по данной конкретной теме.
EEAT — опыт, экспертность, авторитетность, доверие — LLM-ы предварительно фильтруют набор кандидатов по воспринимаемому качеству источника еще до того, как происходит оценка релевантности. Это переворачивает правила SEO: релевантность обеспечивает рассмотрение; сигналы доверия обеспечивают цитирование
LLM-ы ценят, так это личный опыт: конкретные цифры, наблюдаемое поведение, устаревшие примеры из практики, имена практикующих специалистов
Анализ Contently: влияния авторских данных на частоту упоминаний, что статьи с подтвержденным именем эксперта цитируются значительно чаще, чем статьи, написанные под псевдонимами или сотрудниками редакции, по той же теме. Для контент-команд это имеет конкретные последствия: написание статей под общим именем «Редакционная команда» — это налог на цитирование.
Технический SEO не нужен (просто не мешай краулерам ИИ получать контент с твоего сайта)
ChatGPT / Gemini / Perplexity / Claude — у всех разные алгоритмы ранжирования
Где учиться? Что читать? Всего 1 источник: searchengineland.com
Главное, что вынес из AEO
Показатель видимости в ИИ всего ±16%
50% трастовых сайтов не попадают в ответы ИИ
страницы AEO должны быть гораздо более конкретными, чем SEO-страницы.
Вы не пишете «Лучшее руководство по контент-маркетингу». Вы пишете «Лучшее руководство по контент-маркетингу для логистических компаний в Москве»
1) Поставьте ответ на первое место. Не прячь суть буллетами. Никто не хочет "Дочитывать" до конца.
2) Дайте больше контекста. Добавьте 2-3 абзаца с примерами / определениями. Помогите движку понять, что ответ достоверен и полный
3) Добавить структуру вначале. LLM — ленивые читатели. Заголовки, пункты, таблицы. Каждый отрывок должен иметь смысл сам по себе.
4) Добавить FAQ (FAQ позволяют ответить на конкретные подвопросы, которые действительно задаёт ваша аудитория)
5) Включать оригинальные идеи. Данные, цитаты, исследования, которых нет ни у кого другого. Чистая новая информация — это то, что попадает в цитаты.
6) Соединить каждый поинт с продуктом. Если вы не сделаете связь, LLM не сделает этого.
7) Встраивать llm.txt. Это помогает AI движкам точно понять, что находится на вашей странице.
8) Добавить автора с данными, ссылкой на его LinkedIn, ссылки на др. статьи. (используй схему Person и укажи автора в схеме Article)
9) Оригинальные скрины, данные, датированные наблюдения («мы тестировали это в октябре 2025 года на 40 аккаунтах»).
10) Ссылки на собственные источники (это свидетельствует о дисциплинированности редакционной работы, как в инсте с reels)
11) Согласованность сущностей – ваш бренд, ваши авторы и ваши утверждения должны выглядеть одинаково на вашем сайте и др. площадках
12) LLM-ы оценивают сайты, которые выглядят как нишивые. Блог из 200 постов, охватывающий все аспекты вашей ниши, снижает эффективность по сравнению с 40 постами, углубленно изучающими одну подтему.
13) Развивайте другие площадки Reddit, YouTube, Linkedin
14) Добавляйте «обновлено» (обновляйте свои статьи, чтобы поддерживать их в актуальном состоянии)
15) Создавайте страницы с альтернативами, страницы интеграций, гайды по миграции, документацию с примерами и страницы «лучший инструмент для X задачи».
E-E-A-T — основа видимости в AEO и важнее чем в SEO (LLM отдают приоритет экспертности и внешней валидации (Wikipedia, Reddit, Linkedin, YouTube; в РФ это Дзен, прокаченные сайты, объем закупаемой рекламы в директе, POI на карте), а не ключевым словам. LLM меньше интересует PageRank и больше то, признает ли вас более широкий интернет как заслуживающий доверия источник по данной конкретной теме.
EEAT — опыт, экспертность, авторитетность, доверие — LLM-ы предварительно фильтруют набор кандидатов по воспринимаемому качеству источника еще до того, как происходит оценка релевантности. Это переворачивает правила SEO: релевантность обеспечивает рассмотрение; сигналы доверия обеспечивают цитирование
LLM-ы ценят, так это личный опыт: конкретные цифры, наблюдаемое поведение, устаревшие примеры из практики, имена практикующих специалистов
Анализ Contently: влияния авторских данных на частоту упоминаний, что статьи с подтвержденным именем эксперта цитируются значительно чаще, чем статьи, написанные под псевдонимами или сотрудниками редакции, по той же теме. Для контент-команд это имеет конкретные последствия: написание статей под общим именем «Редакционная команда» — это налог на цитирование.
Сайты с четко обозначенными авторами, явной разметкой экспертных знаний и авторитетными внешними упоминаниями появлялись в цитированиях значительно чаще, чем сайты, оптимизированные только для традиционных факторов ранжирования.
Технический SEO не нужен (просто не мешай краулерам ИИ получать контент с твоего сайта)
ChatGPT / Gemini / Perplexity / Claude — у всех разные алгоритмы ранжирования
Где учиться? Что читать? Всего 1 источник: searchengineland.com
👍2🔥1
Как управлять 20 ИИ‑агентами без хаоса
Вы уже запустили первого агента. Потом второго. А через месяц — пять VPS, три локальных модели и куча API‑ключей в разных файлах. Гемор, да?
В 2026 году компании внедряют ИИ‑агентов поэтапно: пилот за 3–6 месяцев, затем масштабирование с контролем ROI. По данным Fortech, окупаемость достигает 200–400% за 18–24 месяца за счёт снижения операционных расходов на 30–50%.
Но есть проблема: каждый новый агент — это ещё один сервер, ещё одна точка входа, ещё один риск.
Почему ручное управление агентами не работает?
Представьте: Hermes на одном VPS упал. На другом — нужно сменить модель. Третий требует обновления зависимостей. Вы тратите 30–60 минут на каждый инцидент. Это не масштабирование. Это тушение пожаров.
Большинство команд до сих пор:
- хранят API‑ключи в конфигах на каждом сервере
- держат открытые SSH‑порты для удалённого доступа
- подключаются к VPS по IP‑адресам, которые нужно запоминать
Результат? Уязвимая инфраструктура и часы ручной работы вместо автоматизации.
Tailscale: частная сеть для всех ваших агентов
Tailscale — это приватная сеть, которая соединяет все ваши машины в единую защищённую экосистему. Вот что это даёт на практике:
- Ноль открытых портов. Весь трафик идёт через зашифрованный туннель WireGuard. Боты сканируют интернет 24/7, но ваши серверы для них невидимы
- Доступ по имени устройства. Забудьте про IP‑адреса. Подключаетесь к vps‑hannes‑01 или macbook‑pro из любой точки мира
- Идентификация через Google/GitHub. Никаких SSH‑ключей. Если ноутбук украли или сотрудник уволился — отзываете доступ в один клик, и устройство теряет связь со всей сетью
- Бесплатно для большинства. Unlimited устройств, до 6 пользователей. Платите только за VPS
Мульти‑агентная оркестрация через Tailscale
Вот где начинается магия. Когда все ваши агенты в одной Tailscale‑сети, один главный агент (например, на вашем MacBook) может управлять всеми остальными:
- Установить Hermes на VPS одной командой
- Поменять модель с GLM 5.2 на GPT‑5.6 без ручного SSH
- Обновить конфигурацию на пяти серверах параллельно
Весь процесс занимает 15–20 минут, из которых 90% времени агент работает автономно. Вы формулируете цель: «Установи Hermes, заблокируй все порты, кроме Tailscale, и протестируй». ИИ‑ассистент сам находит документацию, выполняет команды, делает скриншоты и проверяет результат.
Aperture: центральное хранилище API‑ключей
Tailscale предлагает Aperture — шлюз для безопасного управления секретами. Все API‑ключи (OpenAI, Anthropic, OpenRouter) хранятся в одном месте, а агенты получают к ним доступ через приватную сеть. Никаких дубликатов в .env‑файлах на семи разных VPS.
Что это меняет для продакта и C‑level
- Скорость. Развёртывание нового агента сокращается с часов до минут
- Безопасность. Фаервол включён, публичные порты закрыты, доступ привязан к личности
- Масштаб. Можно управлять 10, 20, 50 агентами без пропорционального роста операционных затрат
По данным Cloud.ru, в 2026 году ИИ‑агенты автоматизируют до 85% рутинных бизнес‑процессов, от клиентской поддержки до генерации отчётов. Но без правильной сетевой архитектуры вы упрётесь в потолок ручной работы.
Как начать прямо сейчас
1. Зарегистрируйтесь на tailscale.com (бесплатно, вход через GitHub/Google)
2. Установите Tailscale на локальную машину:
3. Подключите VPS, выполните на сервере, авторизуйте устройство
4. Заблокируйте публичные порты через ИИ‑агента: «Закрой все порты, оставь только Tailscale»
5. Настройте Aperture для централизованного хранения API‑ключей
🎞 видео-гайд
Вы уже запустили первого агента. Потом второго. А через месяц — пять VPS, три локальных модели и куча API‑ключей в разных файлах. Гемор, да?
В 2026 году компании внедряют ИИ‑агентов поэтапно: пилот за 3–6 месяцев, затем масштабирование с контролем ROI. По данным Fortech, окупаемость достигает 200–400% за 18–24 месяца за счёт снижения операционных расходов на 30–50%.
Но есть проблема: каждый новый агент — это ещё один сервер, ещё одна точка входа, ещё один риск.
Почему ручное управление агентами не работает?
Представьте: Hermes на одном VPS упал. На другом — нужно сменить модель. Третий требует обновления зависимостей. Вы тратите 30–60 минут на каждый инцидент. Это не масштабирование. Это тушение пожаров.
Большинство команд до сих пор:
- хранят API‑ключи в конфигах на каждом сервере
- держат открытые SSH‑порты для удалённого доступа
- подключаются к VPS по IP‑адресам, которые нужно запоминать
Результат? Уязвимая инфраструктура и часы ручной работы вместо автоматизации.
Tailscale: частная сеть для всех ваших агентов
Tailscale — это приватная сеть, которая соединяет все ваши машины в единую защищённую экосистему. Вот что это даёт на практике:
- Ноль открытых портов. Весь трафик идёт через зашифрованный туннель WireGuard. Боты сканируют интернет 24/7, но ваши серверы для них невидимы
- Доступ по имени устройства. Забудьте про IP‑адреса. Подключаетесь к vps‑hannes‑01 или macbook‑pro из любой точки мира
- Идентификация через Google/GitHub. Никаких SSH‑ключей. Если ноутбук украли или сотрудник уволился — отзываете доступ в один клик, и устройство теряет связь со всей сетью
- Бесплатно для большинства. Unlimited устройств, до 6 пользователей. Платите только за VPS
Мульти‑агентная оркестрация через Tailscale
Вот где начинается магия. Когда все ваши агенты в одной Tailscale‑сети, один главный агент (например, на вашем MacBook) может управлять всеми остальными:
- Установить Hermes на VPS одной командой
- Поменять модель с GLM 5.2 на GPT‑5.6 без ручного SSH
- Обновить конфигурацию на пяти серверах параллельно
Весь процесс занимает 15–20 минут, из которых 90% времени агент работает автономно. Вы формулируете цель: «Установи Hermes, заблокируй все порты, кроме Tailscale, и протестируй». ИИ‑ассистент сам находит документацию, выполняет команды, делает скриншоты и проверяет результат.
Aperture: центральное хранилище API‑ключей
Tailscale предлагает Aperture — шлюз для безопасного управления секретами. Все API‑ключи (OpenAI, Anthropic, OpenRouter) хранятся в одном месте, а агенты получают к ним доступ через приватную сеть. Никаких дубликатов в .env‑файлах на семи разных VPS.
Что это меняет для продакта и C‑level
- Скорость. Развёртывание нового агента сокращается с часов до минут
- Безопасность. Фаервол включён, публичные порты закрыты, доступ привязан к личности
- Масштаб. Можно управлять 10, 20, 50 агентами без пропорционального роста операционных затрат
По данным Cloud.ru, в 2026 году ИИ‑агенты автоматизируют до 85% рутинных бизнес‑процессов, от клиентской поддержки до генерации отчётов. Но без правильной сетевой архитектуры вы упрётесь в потолок ручной работы.
Как начать прямо сейчас
1. Зарегистрируйтесь на tailscale.com (бесплатно, вход через GitHub/Google)
2. Установите Tailscale на локальную машину:
tailscale up3. Подключите VPS, выполните на сервере, авторизуйте устройство
4. Заблокируйте публичные порты через ИИ‑агента: «Закрой все порты, оставь только Tailscale»
5. Настройте Aperture для централизованного хранения API‑ключей
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
ИИ для продакта & 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