🤔 Размышление: почему ИИ — это шанс для интровертов в предпринимательстве
Последние дни я много думал о том, почему одни предприниматели легко растут и масштабируются, а другим это даётся гораздо труднее. И пришёл к интересному выводу.
Традиционно предприниматель зарабатывает больше, когда умеет масштабироваться через людей: делегировать, нанимать специалистов, выстраивать коммуникации. В такой модели экстраверты всегда имели преимущество — им проще договариваться, вдохновлять, управлять, держать команду в тонусе.
Но сейчас правила начали меняться.
Я понял, что ИИ стал новым инструментом масштабирования, который не зависит от социальных навыков.
Не нужно проводить собеседования, объяснять задачи десятью способами, учитывать настроение людей или разруливать конфликты. ИИ работает 24/7, делает рутину, пишет код, анализирует, создаёт структуру, генерирует идеи и помогает мыслить системно.
Это новая форма делегирования —
масштабирование через ИИ-агентов,
где ключевым навыком становится не харизма, а умение чётко формулировать задачи и строить процессы.
И в этой модели интроверты неожиданно получают преимущество.
Теперь, чтобы расти, не нужно быть лидером-оратором или социальным «локомотивом». Можно строить систему, где работу выполняют не люди, а ИИ — быстро, точно и без эмоциональных факторов.
По сути, ИИ превращает интровертов в предпринимателей нового типа: тех, кто масштабируется за счёт технологий, а не социальных связей.
И мне кажется, что это только начало большой трансформации.
Последние дни я много думал о том, почему одни предприниматели легко растут и масштабируются, а другим это даётся гораздо труднее. И пришёл к интересному выводу.
Традиционно предприниматель зарабатывает больше, когда умеет масштабироваться через людей: делегировать, нанимать специалистов, выстраивать коммуникации. В такой модели экстраверты всегда имели преимущество — им проще договариваться, вдохновлять, управлять, держать команду в тонусе.
Но сейчас правила начали меняться.
Я понял, что ИИ стал новым инструментом масштабирования, который не зависит от социальных навыков.
Не нужно проводить собеседования, объяснять задачи десятью способами, учитывать настроение людей или разруливать конфликты. ИИ работает 24/7, делает рутину, пишет код, анализирует, создаёт структуру, генерирует идеи и помогает мыслить системно.
Это новая форма делегирования —
масштабирование через ИИ-агентов,
где ключевым навыком становится не харизма, а умение чётко формулировать задачи и строить процессы.
И в этой модели интроверты неожиданно получают преимущество.
Теперь, чтобы расти, не нужно быть лидером-оратором или социальным «локомотивом». Можно строить систему, где работу выполняют не люди, а ИИ — быстро, точно и без эмоциональных факторов.
По сути, ИИ превращает интровертов в предпринимателей нового типа: тех, кто масштабируется за счёт технологий, а не социальных связей.
И мне кажется, что это только начало большой трансформации.
🚀 Обзор Glama AI MCP Servers
Glama AI MCP Servers — крупнейший открытый каталог MCP-серверов, созданный для того, чтобы быстро находить и подключать инструменты, расширяющие возможности языковых моделей. Glama — это не посредник и не интеграционный слой. Это реестр, где собраны тысячи MCP-серверов, которые можно подключать напрямую в Cursor, Claude или ChatGPT.
🔗 Каталог серверов: https://glama.ai/mcp/servers
Что такое MCP
Model Context Protocol — открытый стандарт Anthropic, позволяющий LLM взаимодействовать с внешними сервисами по единому протоколу.
Модель отправляет запрос → MCP-сервер делает реальный вызов к API или данным → возвращает результат обратно модели.
Так модель получает новые функции без ручной интеграции.
Зачем нужен Glama
Glama решает проблему поиска MCP-серверов. В одном месте собраны инструменты, которые:
• дают модели доступ к API и данным
• добавляют новые навыки и функции
• превращают LLM в агента
• упрощают подключение MCP в IDE и ассистентах
Как это работает
1. Открываешь каталог
2. Находишь MCP-сервер
3. Добавляешь его в Cursor, Claude или ChatGPT
После этого модель работает напрямую с выбранным сервером.
Примеры MCP-серверов
DataForSEO
Дает доступ к SERP, ключевым словам, позициям сайтов и конкурентам.
Например: Проверь позиции сайта по запросу Х — сервер делает реальный запрос к поисковой аналитике.
Instantly
Позволяет управлять email-кампаниями: рассылками, лидами, статистикой.
Jira, PostgreSQL, Google Drive, Sentry и другие
После подключения модель может:
• создавать задачи
• читать и изменять данные в базе
• анализировать ошибки
• работать с файлами и документами
Почему это важно
MCP становится стандартом расширения LLM.
Серверы дают модели реальные возможности, а Glama делает их поиск и подключение быстрым и удобным.
Важно о качестве
Экосистема открытая, уровень серверов разный.
Glama ранжирует инструменты по надежности, но перед использованием в критичных задачах стоит проверять исходный код.
Glama AI MCP Servers — крупнейший открытый каталог MCP-серверов, созданный для того, чтобы быстро находить и подключать инструменты, расширяющие возможности языковых моделей. Glama — это не посредник и не интеграционный слой. Это реестр, где собраны тысячи MCP-серверов, которые можно подключать напрямую в Cursor, Claude или ChatGPT.
🔗 Каталог серверов: https://glama.ai/mcp/servers
Что такое MCP
Model Context Protocol — открытый стандарт Anthropic, позволяющий LLM взаимодействовать с внешними сервисами по единому протоколу.
Модель отправляет запрос → MCP-сервер делает реальный вызов к API или данным → возвращает результат обратно модели.
Так модель получает новые функции без ручной интеграции.
Зачем нужен Glama
Glama решает проблему поиска MCP-серверов. В одном месте собраны инструменты, которые:
• дают модели доступ к API и данным
• добавляют новые навыки и функции
• превращают LLM в агента
• упрощают подключение MCP в IDE и ассистентах
Как это работает
1. Открываешь каталог
2. Находишь MCP-сервер
3. Добавляешь его в Cursor, Claude или ChatGPT
После этого модель работает напрямую с выбранным сервером.
Примеры MCP-серверов
DataForSEO
Дает доступ к SERP, ключевым словам, позициям сайтов и конкурентам.
Например: Проверь позиции сайта по запросу Х — сервер делает реальный запрос к поисковой аналитике.
Instantly
Позволяет управлять email-кампаниями: рассылками, лидами, статистикой.
Jira, PostgreSQL, Google Drive, Sentry и другие
После подключения модель может:
• создавать задачи
• читать и изменять данные в базе
• анализировать ошибки
• работать с файлами и документами
Почему это важно
MCP становится стандартом расширения LLM.
Серверы дают модели реальные возможности, а Glama делает их поиск и подключение быстрым и удобным.
Важно о качестве
Экосистема открытая, уровень серверов разный.
Glama ранжирует инструменты по надежности, но перед использованием в критичных задачах стоит проверять исходный код.
Glama
Open-Source MCP Servers – 77,986 in the Glama Registry
Everything MCP – servers updated daily. The most comprehensive registry of Model Context Protocol (MCP) servers, clients, tools, and integrations.
🚀 Обзор MWS AI Agents Platform от МТС
MWS AI Agents Platform — корпоративная платформа для проектирования, запуска и сопровождения ИИ-агентов и копилотов под задачи крупного бизнеса. Система ориентирована на безопасность, наблюдаемость и быстрый вывод решений в продакшн, позволяя компаниям переходить к формату AI-native.
🔗 Официальный сайт: https://mts.ai/ru/product/ai-agents-platform/
Что это за платформа
Платформа закрывает полный цикл работы с корпоративными ИИ-агентами: от визуальной сборки сценариев и дообучения моделей до эксплуатации, мониторинга и масштабирования. Это не разовый инструмент, а фабрика ИИ-решений, нацеленная на системную работу с AI внутри компании.
Ключевые возможности
• Enterprise-готовность: установка в контур заказчика, ролевая модель доступа, наблюдаемость, безопасность, управление версиями, автомасштабирование, алерты.
• Vendor-agnostic: встроенные модели Cotype и возможность подключать собственные и внешние LLM.
• Low-code: визуальный конструктор бизнес-логики и мультиагентных сценариев.
• Multi-user: десятки пользователей могут работать над проектами параллельно.
• Среда экспериментов: быстрые A/B-тесты и проверка гипотез.
Встроенные модули
• LLM: Cotype Pro 2.5, Cotype VL и другие модели по запросу.
• Конструктор ИИ-агентов и мультиагентных систем.
• AutoRAG для поиска по корпоративным базам знаний.
• LabelX для разметки текста, аудио, видео и изображений.
• AutoML для дообучения моделей на небольших датасетах.
• NER-инструменты для извлечения сущностей.
• OPS Level: LLMOps, MLOps, AgentOps и интеграционный хаб для подключения к корпоративным системам.
Готовые копилоты
Из коробки доступны ассистенты под типовые роли:
• Корпоративный copilot: ответы по базе знаний, документы, суммаризация переписки и встреч.
• HR-copilot: тексты вакансий, отбор резюме, первичные интервью, онбординг, аналитика HR.
• Copilot колл-центра: 24/7 ответы пользователям, маршрутизация, подсказки оператору, речевая и текстовая аналитика.
• Аналитик-copilot: ответы на вопросы по данным, отчёты и дашборды, подключение к БД и BI-системам.
• Copilot программиста: генерация кода, unit-тестов, поиск ошибок, документация.
Где применять
Платформа рассчитана на крупные компании во всех ключевых функциях: HR, производство, продажи, финансы, закупки, маркетинг, клиентский сервис, поддержка руководителей. Сценарии охватывают автоматизацию документооборота, кадровых процессов, клиентских обращений и аналитики 24/7.
Заявленные эффекты
По данным МТС, использование платформы позволяет в 2 раза сократить time-to-market ИИ-решений, уменьшить затраты на разработку до 90 процентов и запустить рабочие копилоты всего за 3 дня благодаря переиспользованию компонентов и готовых ассистентов.
MWS AI Agents Platform — корпоративная платформа для проектирования, запуска и сопровождения ИИ-агентов и копилотов под задачи крупного бизнеса. Система ориентирована на безопасность, наблюдаемость и быстрый вывод решений в продакшн, позволяя компаниям переходить к формату AI-native.
🔗 Официальный сайт: https://mts.ai/ru/product/ai-agents-platform/
Что это за платформа
Платформа закрывает полный цикл работы с корпоративными ИИ-агентами: от визуальной сборки сценариев и дообучения моделей до эксплуатации, мониторинга и масштабирования. Это не разовый инструмент, а фабрика ИИ-решений, нацеленная на системную работу с AI внутри компании.
Ключевые возможности
• Enterprise-готовность: установка в контур заказчика, ролевая модель доступа, наблюдаемость, безопасность, управление версиями, автомасштабирование, алерты.
• Vendor-agnostic: встроенные модели Cotype и возможность подключать собственные и внешние LLM.
• Low-code: визуальный конструктор бизнес-логики и мультиагентных сценариев.
• Multi-user: десятки пользователей могут работать над проектами параллельно.
• Среда экспериментов: быстрые A/B-тесты и проверка гипотез.
Встроенные модули
• LLM: Cotype Pro 2.5, Cotype VL и другие модели по запросу.
• Конструктор ИИ-агентов и мультиагентных систем.
• AutoRAG для поиска по корпоративным базам знаний.
• LabelX для разметки текста, аудио, видео и изображений.
• AutoML для дообучения моделей на небольших датасетах.
• NER-инструменты для извлечения сущностей.
• OPS Level: LLMOps, MLOps, AgentOps и интеграционный хаб для подключения к корпоративным системам.
Готовые копилоты
Из коробки доступны ассистенты под типовые роли:
• Корпоративный copilot: ответы по базе знаний, документы, суммаризация переписки и встреч.
• HR-copilot: тексты вакансий, отбор резюме, первичные интервью, онбординг, аналитика HR.
• Copilot колл-центра: 24/7 ответы пользователям, маршрутизация, подсказки оператору, речевая и текстовая аналитика.
• Аналитик-copilot: ответы на вопросы по данным, отчёты и дашборды, подключение к БД и BI-системам.
• Copilot программиста: генерация кода, unit-тестов, поиск ошибок, документация.
Где применять
Платформа рассчитана на крупные компании во всех ключевых функциях: HR, производство, продажи, финансы, закупки, маркетинг, клиентский сервис, поддержка руководителей. Сценарии охватывают автоматизацию документооборота, кадровых процессов, клиентских обращений и аналитики 24/7.
Заявленные эффекты
По данным МТС, использование платформы позволяет в 2 раза сократить time-to-market ИИ-решений, уменьшить затраты на разработку до 90 процентов и запустить рабочие копилоты всего за 3 дня благодаря переиспользованию компонентов и готовых ассистентов.
Почему в enterprise всё меньше говорят про RAG и всё больше — про агентов
RAG не умер.
Он просто перестал быть центром архитектуры.
Раньше всё выглядело просто:
документы → эмбеддинги → векторная БД → ответ модели.
Для демо и чат-ботов с базой знаний этого хватало.
Но в реальном enterprise быстро выяснилось, что проблемы совсем другие:
— права доступа и аудит
— актуальность данных и версии документов
— объяснимость: откуда взялся ответ
— необходимость не «поговорить», а действовать в системах
В этот момент фокус и сместился.
Сегодня всё чаще строят агентные архитектуры, где модель:
— планирует шаги
— выбирает источник (поиск, API, БД, документы)
— выполняет действия
— и лишь иногда использует retrieval
Ключевой момент:
retrieval никуда не делся.
Он стал одним из инструментов, а не архитектурным центром.
Что это меняет:
Для бизнеса
→ ценность смещается от «умных ответов» к выполнению задач, управлению рисками и ответственности
Для команд
→ важнее становятся оркестрация, наблюдаемость, контроль доступа и источники истины
Для архитектуры
→ меньше логики «запихнуть всё в вектора», больше:
— tool-first подхода
— hybrid search
— runtime-доступа к системам
— агентных ограничений и журналов действий
Отсюда и ощущение, что «RAG исчез».
На самом деле исчез наивный RAG как универсальный рецепт.
Ближайшие 1–3 года будут не про то, какая модель умнее,
а про то, кто лучше встроил ИИ в реальные процессы —
с правами, стоимостью, ответственностью и предсказуемым поведением.
RAG не умер.
Он просто перестал быть центром архитектуры.
Раньше всё выглядело просто:
документы → эмбеддинги → векторная БД → ответ модели.
Для демо и чат-ботов с базой знаний этого хватало.
Но в реальном enterprise быстро выяснилось, что проблемы совсем другие:
— права доступа и аудит
— актуальность данных и версии документов
— объяснимость: откуда взялся ответ
— необходимость не «поговорить», а действовать в системах
В этот момент фокус и сместился.
Сегодня всё чаще строят агентные архитектуры, где модель:
— планирует шаги
— выбирает источник (поиск, API, БД, документы)
— выполняет действия
— и лишь иногда использует retrieval
Ключевой момент:
retrieval никуда не делся.
Он стал одним из инструментов, а не архитектурным центром.
Что это меняет:
Для бизнеса
→ ценность смещается от «умных ответов» к выполнению задач, управлению рисками и ответственности
Для команд
→ важнее становятся оркестрация, наблюдаемость, контроль доступа и источники истины
Для архитектуры
→ меньше логики «запихнуть всё в вектора», больше:
— tool-first подхода
— hybrid search
— runtime-доступа к системам
— агентных ограничений и журналов действий
Отсюда и ощущение, что «RAG исчез».
На самом деле исчез наивный RAG как универсальный рецепт.
Ближайшие 1–3 года будут не про то, какая модель умнее,
а про то, кто лучше встроил ИИ в реальные процессы —
с правами, стоимостью, ответственностью и предсказуемым поведением.
Anti‑Hype Framework: как отсекать ИИ‑фанатизм
В 2026 проблема бизнеса не в том, что «мы не используем ИИ».
Проблема в том, что ИИ внедряют без механизма остановки.
Я всё чаще вижу один и тот же паттерн:
— PoC работает
— команда в восторге
— бюджет растёт
— ценность не появляется
Поэтому для себя я использую простой anti‑hype framework — набор фильтров, через которые должна пройти любая ИИ‑инициатива.
Если проект не проходит фильтр — он закрывается. Без обсуждений.
⸻
1. Pre‑filter: запрет на вход
ИИ‑инициатива даже не рассматривается, если:
— цель формулируется как «внедрить ИИ / LLM / быть AI‑driven»
— нет владельца процесса и P&L
— ИИ «помогает», но ничего не меняет
— отсутствует сценарий выключения
Если ИИ нельзя выключить — это не инновация, а зависимость.
⸻
1. Процесс, а не технология
Ключевой вопрос:
что перестаёт делать человек?
Не:
— «ИИ ассистирует»
— «ИИ рекомендует»
А:
— какой шаг процесса исчезает
— где раньше было решение человека и кто принимает его теперь
Плохой процесс + ИИ = дорогой плохой процесс.
⸻
2. Экономическая гипотеза
ИИ запрещён без чёткой экономики.
Формат простой:
если ИИ работает, мы
— уменьшаем FTE на X
— или сокращаем цикл на Y%
— или снижаем ошибку с A до B
Если единственная метрика — «экономия времени»,
значит стоимость просто уехала в другое место.
⸻
3. Контур контроля и ответственности
Обязательно должны быть ответы:
— где human‑in‑the‑loop и зачем
— есть ли fallback без ИИ
— кто отвечает за ошибки (не «модель»)
— логируются ли решения, а не только ответы
Если нельзя ответить на вопрос:
«кто проснётся ночью из‑за ошибки ИИ»,
проект не готов.
⸻
4. Масштаб и стоимость
PoC — не аргумент.
Нужно честно ответить:
— что будет со стоимостью при ×10 нагрузке
— где bottleneck: модель, данные или люди
— что дороже: ошибка или задержка
Большинство ИИ‑проектов ломается именно здесь.
⸻
5. Kill‑metrics
У каждого ИИ‑проекта должны быть метрики смерти.
Например:
— cost per task выше baseline
— растёт доля human review
— падает SLA
— пользователи делают обходные манёвры
Если kill‑metrics нет — проект нельзя закрыть.
А значит, его нельзя запускать.
⸻
Главный вывод
ИИ с реальной ценностью можно выключить без боли.
ИИ‑фанатизм — нет.
Самый важный навык компаний в 2026 —
не «внедрять ИИ»,
а уметь честно сказать: здесь ИИ не нужен.
⸻
Практика
Чтобы не держать этот фреймворк в голове, я собрал отдельный GPT, который:
— прогоняет ИИ-проекты через anti-hype фильтры
— подсвечивает слабые места в экономике, ответственности и масштабе
— помогает честно ответить на вопрос «стоит ли это запускать»
Использую его как быстрый sanity-check для идей и PoC.
Ссылка: https://chatgpt.com/g/g-6941678ac1088191a449a73ad994289a-ai-anti-hype-evaluator
В 2026 проблема бизнеса не в том, что «мы не используем ИИ».
Проблема в том, что ИИ внедряют без механизма остановки.
Я всё чаще вижу один и тот же паттерн:
— PoC работает
— команда в восторге
— бюджет растёт
— ценность не появляется
Поэтому для себя я использую простой anti‑hype framework — набор фильтров, через которые должна пройти любая ИИ‑инициатива.
Если проект не проходит фильтр — он закрывается. Без обсуждений.
⸻
1. Pre‑filter: запрет на вход
ИИ‑инициатива даже не рассматривается, если:
— цель формулируется как «внедрить ИИ / LLM / быть AI‑driven»
— нет владельца процесса и P&L
— ИИ «помогает», но ничего не меняет
— отсутствует сценарий выключения
Если ИИ нельзя выключить — это не инновация, а зависимость.
⸻
1. Процесс, а не технология
Ключевой вопрос:
что перестаёт делать человек?
Не:
— «ИИ ассистирует»
— «ИИ рекомендует»
А:
— какой шаг процесса исчезает
— где раньше было решение человека и кто принимает его теперь
Плохой процесс + ИИ = дорогой плохой процесс.
⸻
2. Экономическая гипотеза
ИИ запрещён без чёткой экономики.
Формат простой:
если ИИ работает, мы
— уменьшаем FTE на X
— или сокращаем цикл на Y%
— или снижаем ошибку с A до B
Если единственная метрика — «экономия времени»,
значит стоимость просто уехала в другое место.
⸻
3. Контур контроля и ответственности
Обязательно должны быть ответы:
— где human‑in‑the‑loop и зачем
— есть ли fallback без ИИ
— кто отвечает за ошибки (не «модель»)
— логируются ли решения, а не только ответы
Если нельзя ответить на вопрос:
«кто проснётся ночью из‑за ошибки ИИ»,
проект не готов.
⸻
4. Масштаб и стоимость
PoC — не аргумент.
Нужно честно ответить:
— что будет со стоимостью при ×10 нагрузке
— где bottleneck: модель, данные или люди
— что дороже: ошибка или задержка
Большинство ИИ‑проектов ломается именно здесь.
⸻
5. Kill‑metrics
У каждого ИИ‑проекта должны быть метрики смерти.
Например:
— cost per task выше baseline
— растёт доля human review
— падает SLA
— пользователи делают обходные манёвры
Если kill‑metrics нет — проект нельзя закрыть.
А значит, его нельзя запускать.
⸻
Главный вывод
ИИ с реальной ценностью можно выключить без боли.
ИИ‑фанатизм — нет.
Самый важный навык компаний в 2026 —
не «внедрять ИИ»,
а уметь честно сказать: здесь ИИ не нужен.
⸻
Практика
Чтобы не держать этот фреймворк в голове, я собрал отдельный GPT, который:
— прогоняет ИИ-проекты через anti-hype фильтры
— подсвечивает слабые места в экономике, ответственности и масштабе
— помогает честно ответить на вопрос «стоит ли это запускать»
Использую его как быстрый sanity-check для идей и PoC.
Ссылка: https://chatgpt.com/g/g-6941678ac1088191a449a73ad994289a-ai-anti-hype-evaluator
ChatGPT
ChatGPT - AI Anti-Hype Evaluator
ChatGPT helps you get answers, find inspiration, and be more productive.
🟢 Когда процессы перестают быть сценариями
Речь не про ИИ как технологию.
И даже не про автоматизацию.
Речь о том, что процессы больше не являются последовательностями шагов.
И большинство компаний продолжают управлять ими так, будто этого не произошло.
⸻
Как мы управляли процессами раньше
Классическая логика BPM / ITSM:
• процесс = вход → шаги → роли → правила → выход
• автоматизация = ускорить или удешевить шаг
• интеллект = человек или жёстко прописанные правила
Процесс можно было:
• полностью описать,
• утвердить,
• контролировать исполнение.
⸻
Что изменилось за последние 1–2 года
Внутрь процессов вошли модели.
Не как «ещё один инструмент», а как участники принятия решений.
Теперь внутри процесса есть агент, который:
• интерпретирует входные данные,
• работает с неопределённостью,
• выбирает действия,
• может менять порядок шагов,
• обрабатывает кейсы, которых не было в регламенте.
Интеллект перестал быть детерминированным.
👉 Управление сместилось
от контроля шагов — к контролю рамок и последствий.
Это не апгрейд BPM.
Это другая онтология процесса.
⸻
Ключевой сдвиг, который многие не заметили
Процессы больше нельзя спроектировать полностью заранее.
И это ломает:
• BPM-нотации,
• регламенты,
• RACI,
• привычные SLA,
• классическое понимание process ownership.
Процесс больше не сценарий.
Процесс — это поле допустимых решений.
⸻
Практические последствия для бизнеса
Старый вопрос:
«Как автоматизировать процесс X?»
Новый реальный вопрос:
• где ИИ может действовать сам;
• где цена ошибки допустима;
• где обязателен человек;
• сколько стоит одно решение, а не шаг.
KPI смещаются:
• от скорости и времени
• к quality of outcome,
• variance,
• cost per decision,
• escalation rate.
📌 Именно поэтому всё чаще слышно:
«ИИ отлично работает в пилоте, но ломает бизнес при масштабе»
Потому что пилот не проверяет вариативность и последствия.
⸻
Что происходит с ролями в командах
Тихо, но необратимо:
• Process Owner → Decision Boundary Owner
• Аналитик описывает шаги → задаёт пространство решений
• QA проверяет сценарии → проверяет поведение и отклонения
• PM управляет roadmap → управляет рисками автономии
Большинство команд этого не сделали.
Они просто «прикрутили LLM» к старой логике.
⸻
Небольшое личное наблюдение
Я довольно глубоко погружён в эту тему сейчас — в том числе на своём проекте SmartSupport.
И чем дальше, тем больше убеждаюсь: пытаться строить AI-системы в логике классического BPM — это гарантированно нарастить технический и управленческий долг.
Мы изначально проектируем систему не как «процесс с ИИ», а как систему управляемых решений:
с границами автономии, эскалацией, деградацией и возможностью выключить ИИ без остановки бизнеса.
Я довольно подробно фиксирую эти размышления и архитектурные решения в хандбуке проекта:
https://gitlab.vadimevgrafov.ru/it-sprint/wiki-smart-support/-/wikis/home
⸻
Главные иллюзии
❌ «Это просто умная автоматизация»
Нет. Автоматизация усиливает детерминизм. ИИ вносит вариативность.
❌ «Сначала опишем процесс, потом подключим ИИ»
ИИ меняет саму структуру процесса. Идеального описания больше не будет.
❌ «Контроль = логирование»
Контроль в AI-процессах — это:
• пороги,
• обратная связь,
• выборочные проверки,
• intentional friction.
⸻
Куда всё движется в ближайшие 1–3 года
• от процессов → к системам решений
• от регламентов → к рамкам
• от ownership шагов → к ownership рисков
• от оптимизации времени → к оптимизации последствий
Маркер зрелости компании простой:
Если они могут ответить:
• какие решения ИИ принимает сам;
• какова цена его ошибки;
• когда и как он эскалирует;
• кто владеет этими рамками —
они поняли сдвиг.
Если нет —
они всё ещё живут в старой парадигме BPM, просто с чат-ботом.
⸻
🟢 ИИ — не стратегический актив.
Стратегический актив — способность выключить ИИ без ущерба бизнесу.
Речь не про ИИ как технологию.
И даже не про автоматизацию.
Речь о том, что процессы больше не являются последовательностями шагов.
И большинство компаний продолжают управлять ими так, будто этого не произошло.
⸻
Как мы управляли процессами раньше
Классическая логика BPM / ITSM:
• процесс = вход → шаги → роли → правила → выход
• автоматизация = ускорить или удешевить шаг
• интеллект = человек или жёстко прописанные правила
Процесс можно было:
• полностью описать,
• утвердить,
• контролировать исполнение.
⸻
Что изменилось за последние 1–2 года
Внутрь процессов вошли модели.
Не как «ещё один инструмент», а как участники принятия решений.
Теперь внутри процесса есть агент, который:
• интерпретирует входные данные,
• работает с неопределённостью,
• выбирает действия,
• может менять порядок шагов,
• обрабатывает кейсы, которых не было в регламенте.
Интеллект перестал быть детерминированным.
👉 Управление сместилось
от контроля шагов — к контролю рамок и последствий.
Это не апгрейд BPM.
Это другая онтология процесса.
⸻
Ключевой сдвиг, который многие не заметили
Процессы больше нельзя спроектировать полностью заранее.
И это ломает:
• BPM-нотации,
• регламенты,
• RACI,
• привычные SLA,
• классическое понимание process ownership.
Процесс больше не сценарий.
Процесс — это поле допустимых решений.
⸻
Практические последствия для бизнеса
Старый вопрос:
«Как автоматизировать процесс X?»
Новый реальный вопрос:
• где ИИ может действовать сам;
• где цена ошибки допустима;
• где обязателен человек;
• сколько стоит одно решение, а не шаг.
KPI смещаются:
• от скорости и времени
• к quality of outcome,
• variance,
• cost per decision,
• escalation rate.
📌 Именно поэтому всё чаще слышно:
«ИИ отлично работает в пилоте, но ломает бизнес при масштабе»
Потому что пилот не проверяет вариативность и последствия.
⸻
Что происходит с ролями в командах
Тихо, но необратимо:
• Process Owner → Decision Boundary Owner
• Аналитик описывает шаги → задаёт пространство решений
• QA проверяет сценарии → проверяет поведение и отклонения
• PM управляет roadmap → управляет рисками автономии
Большинство команд этого не сделали.
Они просто «прикрутили LLM» к старой логике.
⸻
Небольшое личное наблюдение
Я довольно глубоко погружён в эту тему сейчас — в том числе на своём проекте SmartSupport.
И чем дальше, тем больше убеждаюсь: пытаться строить AI-системы в логике классического BPM — это гарантированно нарастить технический и управленческий долг.
Мы изначально проектируем систему не как «процесс с ИИ», а как систему управляемых решений:
с границами автономии, эскалацией, деградацией и возможностью выключить ИИ без остановки бизнеса.
Я довольно подробно фиксирую эти размышления и архитектурные решения в хандбуке проекта:
https://gitlab.vadimevgrafov.ru/it-sprint/wiki-smart-support/-/wikis/home
⸻
Главные иллюзии
❌ «Это просто умная автоматизация»
Нет. Автоматизация усиливает детерминизм. ИИ вносит вариативность.
❌ «Сначала опишем процесс, потом подключим ИИ»
ИИ меняет саму структуру процесса. Идеального описания больше не будет.
❌ «Контроль = логирование»
Контроль в AI-процессах — это:
• пороги,
• обратная связь,
• выборочные проверки,
• intentional friction.
⸻
Куда всё движется в ближайшие 1–3 года
• от процессов → к системам решений
• от регламентов → к рамкам
• от ownership шагов → к ownership рисков
• от оптимизации времени → к оптимизации последствий
Маркер зрелости компании простой:
Если они могут ответить:
• какие решения ИИ принимает сам;
• какова цена его ошибки;
• когда и как он эскалирует;
• кто владеет этими рамками —
они поняли сдвиг.
Если нет —
они всё ещё живут в старой парадигме BPM, просто с чат-ботом.
⸻
🟢 ИИ — не стратегический актив.
Стратегический актив — способность выключить ИИ без ущерба бизнесу.
GitLab
Home · Wiki · IT sprint / wiki-smart-support · GitLab
GitLab Community Edition
Как проектировать процессы в новых условиях (когда есть ИИ)
⸻
1) Сначала — переосмысление: что такое «процесс» теперь
Старое мышление (его нужно отбросить)
Процесс =
→ последовательность шагов
→ роли
→ регламент
→ контроль исполнения
Это работало, пока все решения принимали люди по правилам.
⸻
Новое мышление
Процесс =
набор решений, которые нужно принимать в потоке событий
Шаги — вторичны.
Главное — кто, как и с какой ценой ошибки принимает решения.
⸻
2) Новый базовый вопрос проектирования
Раньше спрашивали:
«Какие шаги должны быть в процессе?»
Теперь правильный вопрос:
«Какие решения здесь принимаются?»
И это ключевой сдвиг.
⸻
Пример (support в SaaS)
Вместо:
• принять тикет
• классифицировать
• назначить приоритет
• ответить
• закрыть
Мы спрашиваем:
• это вообще support-запрос или нет?
• срочно или может подождать?
• можно ли отвечать автоматически?
• если ошибёмся — что будет?
• когда нужен человек?
⸻
3) Практический фреймворк проектирования (по шагам)
Шаг 1. Выписать все решения в процессе
Берём процесс и честно отвечаем:
Где кто-то думает, а не просто выполняет?
Для support это, например:
• что хочет клиент?
• это баг или вопрос?
• насколько это срочно?
• можно ли закрыть без человека?
📌 Если есть выбор — это решение.
⸻
Шаг 2. Для каждого решения определить цену ошибки
Цена ошибки — самое важное.
Вопросы, которые нужно задать:
• что будет, если ИИ ошибётся?
• можно ли быстро исправить?
• заметит ли клиент?
• есть ли юридические последствия?
Результат:
• низкая цена ошибки
• средняя
• высокая
⸻
Шаг 3. Разделить решения по уровням автономии
Автономия — насколько самостоятельно может действовать ИИ.
Простой язык:
Уровень Что это значит
0 Только человек
1 ИИ советует
2 ИИ действует, человек может отменить
3 ИИ действует сам
📌 Чем выше цена ошибки — тем ниже автономия.
⸻
Шаг 4. Проектировать не шаги, а границы
Вместо:
• «ИИ отвечает на вопросы FAQ»
Проектируем:
• где ИИ имеет право действовать
• где он обязан эскалировать (передать человеку)
• при какой уверенности он останавливается
Это называется guardrails — ограничители.
⸻
4) Как выглядит процесс на практике (без BPM-диаграмм)
Было:
Стало:
Это петля, а не линия.
⸻
5) Что проектировать вместо регламентов
Раньше проектировали:
• инструкции
• чек-листы
• исключения
⸻
Теперь проектируют:
1. Контекст
• какую информацию получает ИИ
2. Пороги
• при какой уверенности можно действовать
3. Эскалации
• когда звать человека
4. Деградацию
• что делать, если ИИ не справляется
5. Обратную связь
• как система узнаёт, что решение было плохим
⸻
6) Как меняются роли людей
Роль человека теперь не «исполнять»
Человек:
• владеет риском
• проверяет спорные случаи
• улучшает рамки решений
Новая неформальная роль:
владелец границ решений
⸻
7) Частая ошибка мышления
«Давайте сначала опишем идеальный процесс, потом автоматизируем»
В новых условиях это невозможно.
Почему:
• ИИ меняет поведение системы
• процесс эволюционирует
• заранее всё не описать
Правильнее:
• запускать ограниченную автономию
• наблюдать последствия
• корректировать границы
⸻
8) Мини-чеклист: что значит «хорошо спроектированный процесс»
Ты можешь ответить:
• какие решения принимает ИИ
• где он может ошибаться
• как быстро ошибка обнаруживается
• кто отвечает за последствия
• как система становится лучше со временем
Если на эти вопросы нет ответов —
процесс не спроектирован, даже если есть схема.
⸻
9) Главное резюме
• Процесс = система решений
• Проектирование = дизайн границ и последствий
• ИИ = не исполнитель, а источник вариативности
• Человек = не оператор, а владелец риска
⸻
1) Сначала — переосмысление: что такое «процесс» теперь
Старое мышление (его нужно отбросить)
Процесс =
→ последовательность шагов
→ роли
→ регламент
→ контроль исполнения
Это работало, пока все решения принимали люди по правилам.
⸻
Новое мышление
Процесс =
набор решений, которые нужно принимать в потоке событий
Шаги — вторичны.
Главное — кто, как и с какой ценой ошибки принимает решения.
⸻
2) Новый базовый вопрос проектирования
Раньше спрашивали:
«Какие шаги должны быть в процессе?»
Теперь правильный вопрос:
«Какие решения здесь принимаются?»
И это ключевой сдвиг.
⸻
Пример (support в SaaS)
Вместо:
• принять тикет
• классифицировать
• назначить приоритет
• ответить
• закрыть
Мы спрашиваем:
• это вообще support-запрос или нет?
• срочно или может подождать?
• можно ли отвечать автоматически?
• если ошибёмся — что будет?
• когда нужен человек?
⸻
3) Практический фреймворк проектирования (по шагам)
Шаг 1. Выписать все решения в процессе
Берём процесс и честно отвечаем:
Где кто-то думает, а не просто выполняет?
Для support это, например:
• что хочет клиент?
• это баг или вопрос?
• насколько это срочно?
• можно ли закрыть без человека?
📌 Если есть выбор — это решение.
⸻
Шаг 2. Для каждого решения определить цену ошибки
Цена ошибки — самое важное.
Вопросы, которые нужно задать:
• что будет, если ИИ ошибётся?
• можно ли быстро исправить?
• заметит ли клиент?
• есть ли юридические последствия?
Результат:
• низкая цена ошибки
• средняя
• высокая
⸻
Шаг 3. Разделить решения по уровням автономии
Автономия — насколько самостоятельно может действовать ИИ.
Простой язык:
Уровень Что это значит
0 Только человек
1 ИИ советует
2 ИИ действует, человек может отменить
3 ИИ действует сам
📌 Чем выше цена ошибки — тем ниже автономия.
⸻
Шаг 4. Проектировать не шаги, а границы
Вместо:
• «ИИ отвечает на вопросы FAQ»
Проектируем:
• где ИИ имеет право действовать
• где он обязан эскалировать (передать человеку)
• при какой уверенности он останавливается
Это называется guardrails — ограничители.
⸻
4) Как выглядит процесс на практике (без BPM-диаграмм)
Было:
Шаг 1 → Шаг 2 → Шаг 3 → Шаг 4Стало:
Событие → Оценка → Решение → Последствие → Обратная связьЭто петля, а не линия.
⸻
5) Что проектировать вместо регламентов
Раньше проектировали:
• инструкции
• чек-листы
• исключения
⸻
Теперь проектируют:
1. Контекст
• какую информацию получает ИИ
2. Пороги
• при какой уверенности можно действовать
3. Эскалации
• когда звать человека
4. Деградацию
• что делать, если ИИ не справляется
5. Обратную связь
• как система узнаёт, что решение было плохим
⸻
6) Как меняются роли людей
Роль человека теперь не «исполнять»
Человек:
• владеет риском
• проверяет спорные случаи
• улучшает рамки решений
Новая неформальная роль:
владелец границ решений
⸻
7) Частая ошибка мышления
«Давайте сначала опишем идеальный процесс, потом автоматизируем»
В новых условиях это невозможно.
Почему:
• ИИ меняет поведение системы
• процесс эволюционирует
• заранее всё не описать
Правильнее:
• запускать ограниченную автономию
• наблюдать последствия
• корректировать границы
⸻
8) Мини-чеклист: что значит «хорошо спроектированный процесс»
Ты можешь ответить:
• какие решения принимает ИИ
• где он может ошибаться
• как быстро ошибка обнаруживается
• кто отвечает за последствия
• как система становится лучше со временем
Если на эти вопросы нет ответов —
процесс не спроектирован, даже если есть схема.
⸻
9) Главное резюме
• Процесс = система решений
• Проектирование = дизайн границ и последствий
• ИИ = не исполнитель, а источник вариативности
• Человек = не оператор, а владелец риска
👍1
Как на самом деле работает AI-система управления процессами
Часто ИИ в продуктах представляют как «умного бота, который всё решает сам».
В проекте SmartSupport, над которым мы работаем это не так.
Наша модель выглядит иначе.
1️⃣ Всё начинается не с сообщения, а с события
Сообщение (письмо, чат, пост) — это просто сырой вход.
Процесс запускается только тогда, когда система распознала событие: проблему, запрос, инцидент, сигнал.
2️⃣ Процесс — это цепочка решений, а не набор шагов
Каждый процесс — это ответы на вопросы:
• что это за ситуация?
• можно ли решать автоматически?
• есть ли риск ошибки?
• нужен ли человек?
• требуется ли действие в системе?
Шаги вторичны. Решения — первичны.
3️⃣ ИИ используется точечно, внутри конкретных решений
Не «весь процесс на ИИ», а строго там, где это:
• допустимо,
• экономически оправдано,
• снижает нагрузку.
Классификация, извлечение данных, оценка уверенности, приоритизация — да.
Управление процессом — нет.
4️⃣ ИИ не принимает решений. Он даёт сигналы
Модель может сказать:
• «вероятность 0.62»
• «уверенность низкая»
• «похоже на инцидент»
Но что делать дальше решает система по правилам или человек.
5️⃣ Автоматизация всегда детерминирована
Даже если используется ИИ:
• есть пороги,
• есть правила,
• есть эскалации,
• есть fallback.
Поведение системы воспроизводимо, объяснимо и контролируемо.
6️⃣ Оркестрация — это дирижёр процесса
Отдельный слой управляет:
• последовательностью решений,
• вызовом агентов,
• подключением человека,
• деградацией при сбоях,
• аудитом и логами.
ИИ — инструмент.
Процесс — в центре.
Ответственность — у системы и человека.
Коротко:
Зрелые AI-продукты — это не «умные чаты»,
а системы управления процессами, усиленные ИИ.
Часто ИИ в продуктах представляют как «умного бота, который всё решает сам».
В проекте SmartSupport, над которым мы работаем это не так.
Наша модель выглядит иначе.
1️⃣ Всё начинается не с сообщения, а с события
Сообщение (письмо, чат, пост) — это просто сырой вход.
Процесс запускается только тогда, когда система распознала событие: проблему, запрос, инцидент, сигнал.
2️⃣ Процесс — это цепочка решений, а не набор шагов
Каждый процесс — это ответы на вопросы:
• что это за ситуация?
• можно ли решать автоматически?
• есть ли риск ошибки?
• нужен ли человек?
• требуется ли действие в системе?
Шаги вторичны. Решения — первичны.
3️⃣ ИИ используется точечно, внутри конкретных решений
Не «весь процесс на ИИ», а строго там, где это:
• допустимо,
• экономически оправдано,
• снижает нагрузку.
Классификация, извлечение данных, оценка уверенности, приоритизация — да.
Управление процессом — нет.
4️⃣ ИИ не принимает решений. Он даёт сигналы
Модель может сказать:
• «вероятность 0.62»
• «уверенность низкая»
• «похоже на инцидент»
Но что делать дальше решает система по правилам или человек.
5️⃣ Автоматизация всегда детерминирована
Даже если используется ИИ:
• есть пороги,
• есть правила,
• есть эскалации,
• есть fallback.
Поведение системы воспроизводимо, объяснимо и контролируемо.
6️⃣ Оркестрация — это дирижёр процесса
Отдельный слой управляет:
• последовательностью решений,
• вызовом агентов,
• подключением человека,
• деградацией при сбоях,
• аудитом и логами.
ИИ — инструмент.
Процесс — в центре.
Ответственность — у системы и человека.
Коротко:
Зрелые AI-продукты — это не «умные чаты»,
а системы управления процессами, усиленные ИИ.
Helpflow Manifesto v1.0
В ходе работы над проектом SmartSupport, я столкнулся с проблемой - если "прикручивать" ИИ к классическим процессам, всегда получается либо чат-бот, либо RAG, но ничего более ценного.
В итоге я разработал методологию, а на ее основе даже некую философию - Helpflow
Принципы внедрения ИИ в системы поддержки и обработки обращений
Я считаю, что внедрение ИИ в поддержку —
это не вопрос технологий, автоматизации или скорости ответов.
Это вопрос управляемости, ответственности и последствий решений.
Поэтому я придерживаюсь следующих принципов.
─────
Принципы
• Поддержка — это процесс достижения результата, а не диалог.
Ответ пользователю сам по себе не решает проблему.
Решение определяется последствиями, а не формулировкой.
• Сообщение не равно событию.
Событие должно быть явно зафиксировано и интерпретируемо системой,
а не возникать «по догадке» ИИ.
• Системы поддержки строятся вокруг решений, а не шагов.
Каждое решение имеет цену ошибки
и требует осознанного контроля.
• ИИ не является актором процессов.
ИИ может помогать интерпретировать, предлагать и объяснять,
но не принимать финальные решения и не выполнять действия.
• Ответственность всегда остаётся за человеком.
Ни автоматизация, ни ИИ не снимают ответственности,
а лишь меняют форму её реализации.
• Автоматизация начинается с ограничений.
Если границы не заданы, автоматизация усиливает хаос,
а не эффективность.
• Human-in-the-loop — архитектурная норма, а не аварийный режим.
Участие человека должно быть предусмотрено системой заранее,
а не добавляться постфактум.
• Fallback — штатное состояние системы.
Система должна корректно работать при отказе ИИ,
а не деградировать в ручной хаос.
• Качество решений важнее скорости реакции.
Быстрое неправильное решение хуже,
чем медленное, но контролируемое.
• Автономность должна зарабатываться.
Она вводится поэтапно,
под контролем метрик и последствий.
─────
Эти принципы лежат в основе всех внедрений Helpflow
и определяют, где использование ИИ допустимо, а где — опасно.
Более подробно - helpflow.ru
В ходе работы над проектом SmartSupport, я столкнулся с проблемой - если "прикручивать" ИИ к классическим процессам, всегда получается либо чат-бот, либо RAG, но ничего более ценного.
В итоге я разработал методологию, а на ее основе даже некую философию - Helpflow
Принципы внедрения ИИ в системы поддержки и обработки обращений
Я считаю, что внедрение ИИ в поддержку —
это не вопрос технологий, автоматизации или скорости ответов.
Это вопрос управляемости, ответственности и последствий решений.
Поэтому я придерживаюсь следующих принципов.
─────
Принципы
• Поддержка — это процесс достижения результата, а не диалог.
Ответ пользователю сам по себе не решает проблему.
Решение определяется последствиями, а не формулировкой.
• Сообщение не равно событию.
Событие должно быть явно зафиксировано и интерпретируемо системой,
а не возникать «по догадке» ИИ.
• Системы поддержки строятся вокруг решений, а не шагов.
Каждое решение имеет цену ошибки
и требует осознанного контроля.
• ИИ не является актором процессов.
ИИ может помогать интерпретировать, предлагать и объяснять,
но не принимать финальные решения и не выполнять действия.
• Ответственность всегда остаётся за человеком.
Ни автоматизация, ни ИИ не снимают ответственности,
а лишь меняют форму её реализации.
• Автоматизация начинается с ограничений.
Если границы не заданы, автоматизация усиливает хаос,
а не эффективность.
• Human-in-the-loop — архитектурная норма, а не аварийный режим.
Участие человека должно быть предусмотрено системой заранее,
а не добавляться постфактум.
• Fallback — штатное состояние системы.
Система должна корректно работать при отказе ИИ,
а не деградировать в ручной хаос.
• Качество решений важнее скорости реакции.
Быстрое неправильное решение хуже,
чем медленное, но контролируемое.
• Автономность должна зарабатываться.
Она вводится поэтапно,
под контролем метрик и последствий.
─────
Эти принципы лежат в основе всех внедрений Helpflow
и определяют, где использование ИИ допустимо, а где — опасно.
Более подробно - helpflow.ru
👍1
Мои скилы для codex и cursor- https://gitlab.vadimevgrafov.ru/ai-club/skills-for-ai-agents
Наткнулся на очень сильный open-source проект по AI Engineering — решил поделиться.
Это не очередной курс формата «подключи ChatGPT API», а полноценная инженерная карта:
от математики и нейросетей → до LLM, RAG, MCP, multi-agent систем и production AI-инфраструктуры.
Что особенно понравилось:
— упор на понимание архитектуры AI-систем, а не только на использование готовых инструментов
— обучение через практику и сборку компонентов своими руками
— современный подход к agentic systems и orchestration
— огромный объем материалов и очень грамотная структура
По сути это попытка сформировать новый тип специалиста:
не просто разработчика с AI API, а AI Systems Engineer.
Для меня проект особенно интересен тем, что многое пересекается с тем, как я сам сейчас смотрю на AI:
процессы как цепочки решений, агенты, orchestration, AI как слой управления, а не просто чат-бот.
Если вам интересна тема AI/LLM/агентных систем — очень рекомендую посмотреть:
🌐 https://aiengineeringfromscratch.com
💻 https://github.com/rohitg00/ai-engineering-from-scratch
Это не очередной курс формата «подключи ChatGPT API», а полноценная инженерная карта:
от математики и нейросетей → до LLM, RAG, MCP, multi-agent систем и production AI-инфраструктуры.
Что особенно понравилось:
— упор на понимание архитектуры AI-систем, а не только на использование готовых инструментов
— обучение через практику и сборку компонентов своими руками
— современный подход к agentic systems и orchestration
— огромный объем материалов и очень грамотная структура
По сути это попытка сформировать новый тип специалиста:
не просто разработчика с AI API, а AI Systems Engineer.
Для меня проект особенно интересен тем, что многое пересекается с тем, как я сам сейчас смотрю на AI:
процессы как цепочки решений, агенты, orchestration, AI как слой управления, а не просто чат-бот.
Если вам интересна тема AI/LLM/агентных систем — очень рекомендую посмотреть:
🌐 https://aiengineeringfromscratch.com
💻 https://github.com/rohitg00/ai-engineering-from-scratch
Aiengineeringfromscratch
AI Engineering from Scratch
523 lessons. 20 phases. Write the backprop, the tokenizer, the attention mechanism, and the agent loop by hand.
Тренд, который сейчас хорошо видно по GitHub, open-source и AI-продуктам: эпоха «секретных промптов» постепенно заканчивается.
Раньше вокруг prompt engineering была почти магия:
— «правильный промпт делает модель умнее»
— «секретная роль system prompt»
— «уникальная формула из 3000 символов»
Но современные модели уже находятся на уровне, где они нормально понимают человеческий язык без шаманства.
Если задачу описать:
— понятно,
— структурно,
— с нормальным контекстом,
то GPT, Claude, Gemini и другие модели уже способны решать огромное количество задач без «магических заклинаний».
Поэтому ценность постепенно смещается.
Не в сторону:
❌ «кто написал самый хитрый промпт»
А в сторону:
✅ skills
✅ agent systems
✅ orchestration
✅ context engineering
✅ memory
✅ evaluation
✅ workflow design
Сейчас всё чаще побеждает не giant-prompt, а хорошо спроектированная система навыков.
Например:
— skill анализа обращения
— skill генерации тестов
— skill проверки качества
— skill repair-пайплайна
— skill извлечения событий
— skill принятия решений
То есть AI начинает использоваться не как «чатик с большим промптом», а как набор управляемых интеллектуальных компонентов.
И это очень важный сдвиг.
Потому что обычный промпт:
— плохо тестируется,
— плохо переиспользуется,
— нестабилен,
— зависит от модели,
— тяжело поддерживается.
А skill — это уже почти инженерный модуль:
— с контрактом,
— правилами,
— telemetry,
— validation,
— retries,
— evaluation.
На мой взгляд, умирает не промптинг как таковой.
Умирает идея:
«Главная ценность — секретный промпт».
Промпты просто уходят под капот и становятся частью инфраструктуры AI-систем.
И профессия будущего — это уже не “prompt engineer”.
А:
AI systems engineer
AI architect
Agent engineer
Context engineer
То есть люди, которые умеют проектировать управляемые AI-системы, а не просто писать длинные инструкции для чата.
Раньше вокруг prompt engineering была почти магия:
— «правильный промпт делает модель умнее»
— «секретная роль system prompt»
— «уникальная формула из 3000 символов»
Но современные модели уже находятся на уровне, где они нормально понимают человеческий язык без шаманства.
Если задачу описать:
— понятно,
— структурно,
— с нормальным контекстом,
то GPT, Claude, Gemini и другие модели уже способны решать огромное количество задач без «магических заклинаний».
Поэтому ценность постепенно смещается.
Не в сторону:
❌ «кто написал самый хитрый промпт»
А в сторону:
✅ skills
✅ agent systems
✅ orchestration
✅ context engineering
✅ memory
✅ evaluation
✅ workflow design
Сейчас всё чаще побеждает не giant-prompt, а хорошо спроектированная система навыков.
Например:
— skill анализа обращения
— skill генерации тестов
— skill проверки качества
— skill repair-пайплайна
— skill извлечения событий
— skill принятия решений
То есть AI начинает использоваться не как «чатик с большим промптом», а как набор управляемых интеллектуальных компонентов.
И это очень важный сдвиг.
Потому что обычный промпт:
— плохо тестируется,
— плохо переиспользуется,
— нестабилен,
— зависит от модели,
— тяжело поддерживается.
А skill — это уже почти инженерный модуль:
— с контрактом,
— правилами,
— telemetry,
— validation,
— retries,
— evaluation.
На мой взгляд, умирает не промптинг как таковой.
Умирает идея:
«Главная ценность — секретный промпт».
Промпты просто уходят под капот и становятся частью инфраструктуры AI-систем.
И профессия будущего — это уже не “prompt engineer”.
А:
AI systems engineer
AI architect
Agent engineer
Context engineer
То есть люди, которые умеют проектировать управляемые AI-системы, а не просто писать длинные инструкции для чата.