Почему это касается не только гиков? Ведь даже Microsoft присматривается к китайцам
Потому что цена решает всё. Если раньше внедрение ИИ в бизнес было дорогим удовольствием, то теперь любой стартап, любая небольшая компания может позволить себе:
1. автоматическую обработку тысяч страниц договоров и контрактов;
2. интеллектуальный поиск по всей внутренней документации;
3. круглосуточный чат-бот с памятью на все диалоги;
4. помощь программистам, которая ускоряет разработку в разы.
И всё это — за копейки. Например, один разработчик выложил скриншот, где он обработал почти 10 миллионов токенов (это примерно 15–20 тысяч страниц текста) и заплатил за это всего 3,16 юаня (около 50 центов). Попробуйте сделать то же самое через Claude — вы отдадите сотни долларов.
В июне 2026 года появилась новость: Microsoft рассматривает возможность подключить DeepSeek V4 к своему корпоративному инструменту Copilot Cowork. Причина банальна — слишком дорого использовать OpenAI и Anthropic, а DeepSeek даёт схожее качество за копейки.
Раньше Microsoft в основном полагалась на OpenAI (в которую вложила миллиарды), но теперь, видимо, даже они поняли, что переплачивать глупо. Это как если бы вы покупали бензин по 5 долларов за литр, а рядом открылась заправка с тем же качеством по 20 центов. Вы бы долго сомневались?
А почему именно Китай?
Многие удивляются: как это стране с «дешёвыми клонами» удаётся делать передовой ИИ? На самом деле, по данным Министерства промышленности Китая, в стране более 9 миллионов разработчиков программного обеспечения — это больше, чем в США, Европе и России вместе взятых. Западные статистики называют цифру около 5,8 млн, но и это огромная армия.
При этом китайские инженеры работают во всех направлениях — от встроенных систем и компьютерного зрения до огромных языковых моделей. Более того, они активно развивают собственное «железо» (чипы Huawei Ascend) и умеют запускать свои модели не только на Nvidia, но и на отечественных процессорах.
Конкуренция внутри Китая тоже бешеная: там десятки ИИ-стартапов, каждый пытается сделать модель дешевле и лучше. В результате цены падают, а качество растёт — быстрее, чем на Западе. Это называется «демпинг инновациями».
Что дальше? Запасаемся попкорном
По оценкам аналитиков, стоимость обработки одного токена падает в 10–100 раз каждый год. Отрыв закрытых топ-моделей от открытых сократился с года до трёх месяцев. Если так пойдёт дальше, то через год-два мы будем смеяться, вспоминая, что платили $200 за месячный доступ к боту, который сейчас доступен бесплатно или за сущие копейки.
Банки и инвесторы уже начали беспокоиться: Deutsche Bank выпустил отчёт, где предупредил, что рынок ИИ может пережить глубокую переоценку, потому что многие компании переплачивают за «статусные» модели, которые по факту не дают реального преимущества.
Так что если вы только начинаете знакомиться с ИИ или просто хотите пользоваться им без разорения — сейчас лучшее время. Не ведитесь на громкие бренды, пробуйте DeepSeek, сравнивайте, экономьте. И помните: сегодняшнее чудо — завтрашняя норма.
Китайцы снова сделали своё дело. Ждём следующего раунда. 🍿
Потому что цена решает всё. Если раньше внедрение ИИ в бизнес было дорогим удовольствием, то теперь любой стартап, любая небольшая компания может позволить себе:
1. автоматическую обработку тысяч страниц договоров и контрактов;
2. интеллектуальный поиск по всей внутренней документации;
3. круглосуточный чат-бот с памятью на все диалоги;
4. помощь программистам, которая ускоряет разработку в разы.
И всё это — за копейки. Например, один разработчик выложил скриншот, где он обработал почти 10 миллионов токенов (это примерно 15–20 тысяч страниц текста) и заплатил за это всего 3,16 юаня (около 50 центов). Попробуйте сделать то же самое через Claude — вы отдадите сотни долларов.
В июне 2026 года появилась новость: Microsoft рассматривает возможность подключить DeepSeek V4 к своему корпоративному инструменту Copilot Cowork. Причина банальна — слишком дорого использовать OpenAI и Anthropic, а DeepSeek даёт схожее качество за копейки.
Раньше Microsoft в основном полагалась на OpenAI (в которую вложила миллиарды), но теперь, видимо, даже они поняли, что переплачивать глупо. Это как если бы вы покупали бензин по 5 долларов за литр, а рядом открылась заправка с тем же качеством по 20 центов. Вы бы долго сомневались?
А почему именно Китай?
Многие удивляются: как это стране с «дешёвыми клонами» удаётся делать передовой ИИ? На самом деле, по данным Министерства промышленности Китая, в стране более 9 миллионов разработчиков программного обеспечения — это больше, чем в США, Европе и России вместе взятых. Западные статистики называют цифру около 5,8 млн, но и это огромная армия.
При этом китайские инженеры работают во всех направлениях — от встроенных систем и компьютерного зрения до огромных языковых моделей. Более того, они активно развивают собственное «железо» (чипы Huawei Ascend) и умеют запускать свои модели не только на Nvidia, но и на отечественных процессорах.
Конкуренция внутри Китая тоже бешеная: там десятки ИИ-стартапов, каждый пытается сделать модель дешевле и лучше. В результате цены падают, а качество растёт — быстрее, чем на Западе. Это называется «демпинг инновациями».
Что дальше? Запасаемся попкорном
По оценкам аналитиков, стоимость обработки одного токена падает в 10–100 раз каждый год. Отрыв закрытых топ-моделей от открытых сократился с года до трёх месяцев. Если так пойдёт дальше, то через год-два мы будем смеяться, вспоминая, что платили $200 за месячный доступ к боту, который сейчас доступен бесплатно или за сущие копейки.
Банки и инвесторы уже начали беспокоиться: Deutsche Bank выпустил отчёт, где предупредил, что рынок ИИ может пережить глубокую переоценку, потому что многие компании переплачивают за «статусные» модели, которые по факту не дают реального преимущества.
Так что если вы только начинаете знакомиться с ИИ или просто хотите пользоваться им без разорения — сейчас лучшее время. Не ведитесь на громкие бренды, пробуйте DeepSeek, сравнивайте, экономьте. И помните: сегодняшнее чудо — завтрашняя норма.
Китайцы снова сделали своё дело. Ждём следующего раунда. 🍿
❤3🤔2
Меня зовут Максим, я CTO и со-основатель стартапа. Это официальный старт моей главной мечты — создать продукт, который сделает логистику по-настоящему интеллектуальной. Мы строим агентно-ориентированную платформу. Это не монолит, а гибкая экосистема, где каждый ИИ-агент решает свою задачу, подстраиваясь под бизнес-процессы клиента.
Технологическое ядро: семантика и мультимодальность
Мы используем связку передовых LLM (Yandex, OpenAI) и собственные доработанные LM-решения. Система построена на семантическом поиске — агенты понимают глубинный смысл запроса, а не просто ключевые слова. Плюс мы поддерживаем мультимодальность: наши модели работают со сканами, фото грузов и рукописными накладными. Это действительно передовой край.
Архитектурный прорыв: MCP и LLM-оркестрация
В основе коммуникации агентов лежит протокол MCP (Model Context Protocol). Для обнаружения и регистрации агентов мы используем централизованный MCP-реестр, а всю оркестрацию (маршрутизацию запросов и управление цепочками задач) берёт на себя LLM-ядро.
Проще говоря, это как умная диспетчерская: LLM решает, какому агенту передать задачу, а MCP помогает агентам находить друг друга и обмениваться контекстом. Этот подход уже применяется в таких компаниях, как Perplexity, но мы переосмыслили его под динамику цепочек поставок. Мы можем «включать» новых агентов на лету, не пересобирая систему.
Ключевая фича: ВЭД и «живая» калькуляция
Особый фокус — внешнеэкономическая деятельность (ВЭД). Логистика пересекает границы, а значит, мы сталкиваемся с плавающими пошлинами, курсами валют и санкционными рисками.
Наш агент по ВЭД производит динамическую калькуляцию стоимости доставки «до двери» в реальном времени, учитывая:
· Актуальные таможенные пошлины и НДС;
· Колебания валют (курс ЦБ);
· Топливные и сезонные сборы;
· Транзитные риски (заторы, перенаправление).
Используя семантический поиск, агент мгновенно парсит изменения в законодательстве. Это позволяет прогнозировать себестоимость груза с погрешностью менее 2%, что критично для внешнеторговых контрактов.
Безопасность и управление доступом
Разумеется, мы с самого начала прорабатываем вопросы безопасности. В основе системы лежит управление доступом через токены и Keycloak. Мы тщательно настроили аутентификацию и авторизацию, чтобы разграничить доступ к данным разных клиентов и гарантировать защиту коммерческой тайны. Это особенно важно, когда речь идёт о внешнеэкономических контрактах.
Архитектура бизнеса, а не просто код
Для нас платформа — это не просто набор микросервисов и моделей. Это архитектура нашего бизнеса. Каждый агент, каждый протокол и каждая точка интеграции отражают философию нашей работы: быть гибкими, прозрачными и клиентоцентричными. Мы строим систему, которая масштабируется вместе с потребностями рынка, а не ломается при первой же перемене правил игры.
Наше видение и статус
Сейчас система внедрена не на 100%, но у нас уже есть боевые прототипы агентов (база знаний, юридический комплаенс, поддержка клиентов).
Мы нацелены на малый и средний бизнес и в ближайшей перспективе хотим, чтобы клиенты управляли агентами через любые удобные каналы: Telegram, почту, а в идеале — даже голосом. Именно здесь наша архитектура на базе LLM-оркестрации и MCP раскрывает свой потенциал — вместо сложных ERP-интерфейсов мы даём простой диалог.
Я реализую себя здесь не только как AI-инженер, но и как стратег, создавая роадмапы и брейнштормя каждую фичу.
Конечно, путь только начинается, и нас ждёт множество вызовов. Но я искренне верю, что это великолепный шанс. Мы будем масштабироваться, искать новые горизонты для сотрудничества и точно не остановимся на достигнутом. Наша команда горит этим делом — и это главное топливо проекта.
Мы ищем пилотных заказчиков и технологических партнёров.
Если ваша компания работает в логистике или ВЭД — приходите на демо. Мы покажем всё «как есть», без прикрас.
Для самых смелых у нас есть предложение: вы можете получить ранний доступ (Early Access) к нашей экосистеме уже сейчас. Это отличная возможность войти в новый технологический уклад на раннем этапе.
Технологическое ядро: семантика и мультимодальность
Мы используем связку передовых LLM (Yandex, OpenAI) и собственные доработанные LM-решения. Система построена на семантическом поиске — агенты понимают глубинный смысл запроса, а не просто ключевые слова. Плюс мы поддерживаем мультимодальность: наши модели работают со сканами, фото грузов и рукописными накладными. Это действительно передовой край.
Архитектурный прорыв: MCP и LLM-оркестрация
В основе коммуникации агентов лежит протокол MCP (Model Context Protocol). Для обнаружения и регистрации агентов мы используем централизованный MCP-реестр, а всю оркестрацию (маршрутизацию запросов и управление цепочками задач) берёт на себя LLM-ядро.
Проще говоря, это как умная диспетчерская: LLM решает, какому агенту передать задачу, а MCP помогает агентам находить друг друга и обмениваться контекстом. Этот подход уже применяется в таких компаниях, как Perplexity, но мы переосмыслили его под динамику цепочек поставок. Мы можем «включать» новых агентов на лету, не пересобирая систему.
Ключевая фича: ВЭД и «живая» калькуляция
Особый фокус — внешнеэкономическая деятельность (ВЭД). Логистика пересекает границы, а значит, мы сталкиваемся с плавающими пошлинами, курсами валют и санкционными рисками.
Наш агент по ВЭД производит динамическую калькуляцию стоимости доставки «до двери» в реальном времени, учитывая:
· Актуальные таможенные пошлины и НДС;
· Колебания валют (курс ЦБ);
· Топливные и сезонные сборы;
· Транзитные риски (заторы, перенаправление).
Используя семантический поиск, агент мгновенно парсит изменения в законодательстве. Это позволяет прогнозировать себестоимость груза с погрешностью менее 2%, что критично для внешнеторговых контрактов.
Безопасность и управление доступом
Разумеется, мы с самого начала прорабатываем вопросы безопасности. В основе системы лежит управление доступом через токены и Keycloak. Мы тщательно настроили аутентификацию и авторизацию, чтобы разграничить доступ к данным разных клиентов и гарантировать защиту коммерческой тайны. Это особенно важно, когда речь идёт о внешнеэкономических контрактах.
Архитектура бизнеса, а не просто код
Для нас платформа — это не просто набор микросервисов и моделей. Это архитектура нашего бизнеса. Каждый агент, каждый протокол и каждая точка интеграции отражают философию нашей работы: быть гибкими, прозрачными и клиентоцентричными. Мы строим систему, которая масштабируется вместе с потребностями рынка, а не ломается при первой же перемене правил игры.
Наше видение и статус
Сейчас система внедрена не на 100%, но у нас уже есть боевые прототипы агентов (база знаний, юридический комплаенс, поддержка клиентов).
Мы нацелены на малый и средний бизнес и в ближайшей перспективе хотим, чтобы клиенты управляли агентами через любые удобные каналы: Telegram, почту, а в идеале — даже голосом. Именно здесь наша архитектура на базе LLM-оркестрации и MCP раскрывает свой потенциал — вместо сложных ERP-интерфейсов мы даём простой диалог.
Я реализую себя здесь не только как AI-инженер, но и как стратег, создавая роадмапы и брейнштормя каждую фичу.
Конечно, путь только начинается, и нас ждёт множество вызовов. Но я искренне верю, что это великолепный шанс. Мы будем масштабироваться, искать новые горизонты для сотрудничества и точно не остановимся на достигнутом. Наша команда горит этим делом — и это главное топливо проекта.
Мы ищем пилотных заказчиков и технологических партнёров.
Если ваша компания работает в логистике или ВЭД — приходите на демо. Мы покажем всё «как есть», без прикрас.
Для самых смелых у нас есть предложение: вы можете получить ранний доступ (Early Access) к нашей экосистеме уже сейчас. Это отличная возможность войти в новый технологический уклад на раннем этапе.
🤔2
Конечно, путь только начинается, и нас ждёт множество вызовов. Но я искренне верю, что это великолепный шанс. Мы будем масштабироваться, искать новые горизонты для сотрудничества и точно не остановимся на достигнутом. Наша команда горит этим делом — и это главное топливо проекта.
Мы ищем пилотных заказчиков и технологических партнёров.
Если ваша компания работает в логистике или ВЭД — приходите на демо. Мы покажем всё «как есть», без прикрас.
Но это ещё не всё. Если у вас уже есть собственные ИИ-агенты или наработки в этой сфере — давайте объединим усилия! Мы открыты к кооперации и готовы предоставить вам автоматизацию на базе нашей платформы.
Для самых смелых у нас есть предложение: вы можете получить ранний доступ (Early Access) к нашей экосистеме уже сейчас. Это отличная возможность войти в новый технологический уклад на раннем этапе.
Записывайтесь на демо-презентацию — мы обсудим детали, ответим на вопросы и расскажем про архитектуру глубже (насколько это позволяют NDA). Мы очень хотим сотрудничать и создавать будущее логистики вместе!
Давайте сделаем это!
Мы ищем пилотных заказчиков и технологических партнёров.
Если ваша компания работает в логистике или ВЭД — приходите на демо. Мы покажем всё «как есть», без прикрас.
Но это ещё не всё. Если у вас уже есть собственные ИИ-агенты или наработки в этой сфере — давайте объединим усилия! Мы открыты к кооперации и готовы предоставить вам автоматизацию на базе нашей платформы.
Для самых смелых у нас есть предложение: вы можете получить ранний доступ (Early Access) к нашей экосистеме уже сейчас. Это отличная возможность войти в новый технологический уклад на раннем этапе.
Записывайтесь на демо-презентацию — мы обсудим детали, ответим на вопросы и расскажем про архитектуру глубже (насколько это позволяют NDA). Мы очень хотим сотрудничать и создавать будущее логистики вместе!
Давайте сделаем это!
✍1👍1
Мне каждый раз кажется, что я видел многое, но каждый раз жизнь открывает передо мной новый уровень дна со словами: «Теперь ты готов познать больше». Сейчас такой период, когда компании думают, что автоматизация позволяет кого‑то заменить и что можно сэкономить, выкинув часть народа на улицу. В основном это компании, которые за 5 лет привыкли к стабильным льготам.
Проблема в том, что искусственный интеллект в том виде, в котором он существует сейчас, не ускоряет разработку так, как обещают. Исследования 2025 года показывают парадокс: разработчики с AI-инструментами тратили на задачи на 19% больше времени, чем без них. При этом они сами были уверены, что стали быстрее на 20%. Ожидание и реальность разошлись кардинально.
Выкидывать людей себе дороже — и это не просто эмоция. Код, написанный с помощью ИИ, требует больше доработок и ревью. Нагрузка ложится на опытных разработчиков: они проверяют на 6.5% больше кода, но их собственная продуктивность падает на 19%. Проще говоря, одни пишут быстрее и грязнее, другие разгребают — и в итоге все медленнее.
А то, что продают как «ускорение», на деле выливается в рост объёма кода. В 2025 году средний разработчик отправлял в репозиторий на 75% больше кода, чем в 2022-м. Но больше кода — не значит быстрее доставка.
Недавно написал сервер с MPC‑скиллами и решил подключить registry для единой точки входа. Два дня потратил на подключение, потому что то он делал на SSE, то не с теми эндпоинтами, и так далее. ИИ здесь не помог — код пришлось писать руками, разбираться с документацией и логикой самому. В итоге я написал текста больше, чем за месяц работы тестировщиков в Acronis.
Плата за обещанное ускорение в том, что мы пишем больше и дольше. Потому что то у нас токены закончились, то VPN не VPN, то план поменяли, то промпты неудачные накатили, то оркестратор начал течь по памяти (бывает и такое, ведь там сервис-воркеры, и они не всегда стабильно закрывают потоки).
И вот тут я вспоминаю 90-е. Когда завезли компьютеры, было модно выгонять на улицы целые НИИ, и люди думали, что Access или FoxPro — это билеты в светлое будущее. Тогда казалось, что технологии всё ускорят и упростят. Но разработка — это постоянное обнуление. В ней нет линейной скорости. На самом деле это про замедление: растёт расход памяти, CPU, появились GPU, сеть, а проблемы те же — как заработать больше, заплатить меньше и не получить очередной иск от ПФР или военкомата за отсутствующую букву в отчётности.
Проблема в том, что искусственный интеллект в том виде, в котором он существует сейчас, не ускоряет разработку так, как обещают. Исследования 2025 года показывают парадокс: разработчики с AI-инструментами тратили на задачи на 19% больше времени, чем без них. При этом они сами были уверены, что стали быстрее на 20%. Ожидание и реальность разошлись кардинально.
Выкидывать людей себе дороже — и это не просто эмоция. Код, написанный с помощью ИИ, требует больше доработок и ревью. Нагрузка ложится на опытных разработчиков: они проверяют на 6.5% больше кода, но их собственная продуктивность падает на 19%. Проще говоря, одни пишут быстрее и грязнее, другие разгребают — и в итоге все медленнее.
А то, что продают как «ускорение», на деле выливается в рост объёма кода. В 2025 году средний разработчик отправлял в репозиторий на 75% больше кода, чем в 2022-м. Но больше кода — не значит быстрее доставка.
Недавно написал сервер с MPC‑скиллами и решил подключить registry для единой точки входа. Два дня потратил на подключение, потому что то он делал на SSE, то не с теми эндпоинтами, и так далее. ИИ здесь не помог — код пришлось писать руками, разбираться с документацией и логикой самому. В итоге я написал текста больше, чем за месяц работы тестировщиков в Acronis.
Плата за обещанное ускорение в том, что мы пишем больше и дольше. Потому что то у нас токены закончились, то VPN не VPN, то план поменяли, то промпты неудачные накатили, то оркестратор начал течь по памяти (бывает и такое, ведь там сервис-воркеры, и они не всегда стабильно закрывают потоки).
И вот тут я вспоминаю 90-е. Когда завезли компьютеры, было модно выгонять на улицы целые НИИ, и люди думали, что Access или FoxPro — это билеты в светлое будущее. Тогда казалось, что технологии всё ускорят и упростят. Но разработка — это постоянное обнуление. В ней нет линейной скорости. На самом деле это про замедление: растёт расход памяти, CPU, появились GPU, сеть, а проблемы те же — как заработать больше, заплатить меньше и не получить очередной иск от ПФР или военкомата за отсутствующую букву в отчётности.
👍1
Управление промптами: почему в 2026 году это уже не «просто текст»
В типовой архитектуре LLM-приложения есть код, описывающий навыки модели, API для доступа к базам знаний, реестр навыков, очереди и прочие компоненты. Вся эта инфраструктура легко автоматизируется: для неё давно написаны статические анализаторы, тесты и линтеры.
Но есть один непредсказуемый элемент — промпт. Это инструкция на естественном языке, которая связывает запрос пользователя с доступными агенту навыками. Именно здесь возникает три базовых operational проблемы:
1. Хранение. Где держать промпты, чтобы они не терялись в коде и не плодили копии?
2. Тестирование и валидация. Как проверить, что изменение одной фразы не сломает поведение системы?
3. Выкатка. Как деплоить новые версии промптов без полного пересборки приложения?
На практике часто используют упрощённый подход: «написали — залили — работает». Это терпимо, пока инструкция проста (например: «ешь кашу, не ругайся матом и слушайся старших»). Но как только вы пытаетесь описать сложную логику — выбор между семантическим и лексическим поиском, обработку аудио, поддержку языков, правила вроде «заваривать кофе, но без сливок» — система начинает трещать по швам.
Во-первых, рост токенов. Чем объемнее промпт, тем сильнее он грузит контекст. А значит, вы платите за каждый входной токен (у разных моделей по-разному: у DeepSeek вход бесплатный, у Minimax — нет). Толстый промпт сложно поддерживать, а слишком упрощённый теряет связь с запросом пользователя.
Во-вторых, непредсказуемость пользовательских запросов. Даже идеально выверенный по форме и объёму промпт не гарантирует, что агент правильно отреагирует на любой запрос. Потому что запросы бывают самыми разными — и они постоянно меняются. Ожидания пользователя не всегда совпадают с тем, что заложено в инструкцию.
Тестирование промптов и сопоставление ожидаемого поведения с реальным — это отдельная большая история. Например, недавно мне пришлось выгрузить 500 текстов реальных переписок клиента с агентом, чтобы вручную разобрать, в каких случаях и как именно система должна реагировать на те или иные сообщения. Без таких данных любые изменения промпта — лотерея.
Для управления этой сложностью существуют специализированные инструменты. Один из них — Langfuse (open-source платформа для observability и управления промптами). Он позволяет:
- версионировать промпты;
- считать эффективность затрат по токенам;
- измерять удовлетворённость ответами;
- связывать промпты с трассировками для анализа по версиям;
- тестировать разные версии промптов на одном датасете и сравнивать результаты side-by-side.
Мы же, стремясь ускорить процессы, пошли дальше и добавили ещё один уровень абстракций — надстройку, которая помогает быстрее переключаться между версиями и A/B-тестировать их.
Важно понимать дилемму. Вы либо миритесь с высоким потреблением токенов (платя за «толстый» и понятный промпт), либо тратите время инженеров на его упрощение, жертвуя качеством сцепки с текстом пользователя. Langfuse помогает отслеживать этот баланс, но не отменяет необходимости выбора: дешёвый контекст против адекватной логики.
Более того, даже выбрав золотую середину по объёму, вы сталкиваетесь с необходимостью постоянно валидировать поведение на живых данных. А это требует сбора репрезентативной выборки диалогов, разметки эталонных ответов и регулярного пересмотра промптов под новые сценарии.
В 2026 году такой процесс — это уже не просто «написать и забыть», а полноценный цикл разработки: промпты версионируются, тестируются на регрессии, выкатываются канареечным способом и мониторятся в проде. Более того, индустрия активно движется в сторону Loop Engineering — когда вы проектируете не один промпт, а систему, которая сама генерирует промпты, проверяет результаты и перезапускает процесс при необходимости.
Идеального решения нет. Но системный подход к версионированию и постоянное тестирование на реальных кейсах (как тот пример с 500 переписками) делают этот компромисс управляемым и прогнозируемым.
В типовой архитектуре LLM-приложения есть код, описывающий навыки модели, API для доступа к базам знаний, реестр навыков, очереди и прочие компоненты. Вся эта инфраструктура легко автоматизируется: для неё давно написаны статические анализаторы, тесты и линтеры.
Но есть один непредсказуемый элемент — промпт. Это инструкция на естественном языке, которая связывает запрос пользователя с доступными агенту навыками. Именно здесь возникает три базовых operational проблемы:
1. Хранение. Где держать промпты, чтобы они не терялись в коде и не плодили копии?
2. Тестирование и валидация. Как проверить, что изменение одной фразы не сломает поведение системы?
3. Выкатка. Как деплоить новые версии промптов без полного пересборки приложения?
На практике часто используют упрощённый подход: «написали — залили — работает». Это терпимо, пока инструкция проста (например: «ешь кашу, не ругайся матом и слушайся старших»). Но как только вы пытаетесь описать сложную логику — выбор между семантическим и лексическим поиском, обработку аудио, поддержку языков, правила вроде «заваривать кофе, но без сливок» — система начинает трещать по швам.
Во-первых, рост токенов. Чем объемнее промпт, тем сильнее он грузит контекст. А значит, вы платите за каждый входной токен (у разных моделей по-разному: у DeepSeek вход бесплатный, у Minimax — нет). Толстый промпт сложно поддерживать, а слишком упрощённый теряет связь с запросом пользователя.
Во-вторых, непредсказуемость пользовательских запросов. Даже идеально выверенный по форме и объёму промпт не гарантирует, что агент правильно отреагирует на любой запрос. Потому что запросы бывают самыми разными — и они постоянно меняются. Ожидания пользователя не всегда совпадают с тем, что заложено в инструкцию.
Тестирование промптов и сопоставление ожидаемого поведения с реальным — это отдельная большая история. Например, недавно мне пришлось выгрузить 500 текстов реальных переписок клиента с агентом, чтобы вручную разобрать, в каких случаях и как именно система должна реагировать на те или иные сообщения. Без таких данных любые изменения промпта — лотерея.
Для управления этой сложностью существуют специализированные инструменты. Один из них — Langfuse (open-source платформа для observability и управления промптами). Он позволяет:
- версионировать промпты;
- считать эффективность затрат по токенам;
- измерять удовлетворённость ответами;
- связывать промпты с трассировками для анализа по версиям;
- тестировать разные версии промптов на одном датасете и сравнивать результаты side-by-side.
Мы же, стремясь ускорить процессы, пошли дальше и добавили ещё один уровень абстракций — надстройку, которая помогает быстрее переключаться между версиями и A/B-тестировать их.
Важно понимать дилемму. Вы либо миритесь с высоким потреблением токенов (платя за «толстый» и понятный промпт), либо тратите время инженеров на его упрощение, жертвуя качеством сцепки с текстом пользователя. Langfuse помогает отслеживать этот баланс, но не отменяет необходимости выбора: дешёвый контекст против адекватной логики.
Более того, даже выбрав золотую середину по объёму, вы сталкиваетесь с необходимостью постоянно валидировать поведение на живых данных. А это требует сбора репрезентативной выборки диалогов, разметки эталонных ответов и регулярного пересмотра промптов под новые сценарии.
В 2026 году такой процесс — это уже не просто «написать и забыть», а полноценный цикл разработки: промпты версионируются, тестируются на регрессии, выкатываются канареечным способом и мониторятся в проде. Более того, индустрия активно движется в сторону Loop Engineering — когда вы проектируете не один промпт, а систему, которая сама генерирует промпты, проверяет результаты и перезапускает процесс при необходимости.
Идеального решения нет. Но системный подход к версионированию и постоянное тестирование на реальных кейсах (как тот пример с 500 переписками) делают этот компромисс управляемым и прогнозируемым.
🤔3
Почему ваш ИИ-разработчик заменил пол-офиса, а продукт всё равно опаздывает на три месяца
Вы чувствуете это каждый спринт. Copilot строчит методы быстрее, чем вы читаете условие задачи. Claude генерирует микросервис по голосовому описанию. Продажники, ошалевшие от демо, уже продали интеллектуальную базу знаний, взяли аванс и поставили дедлайн «вчера». А релиз лежит в ветке и гниёт третью неделю. Коммитов — гора, работающего продукта — ноль. Почему?
Потому что вы ускорили то, что и так не было узким горлышком. А настоящий ад начался именно там, где вы не ждали.
Миф, который стоит миллиарды: код ≠ продукт
Свежайшие данные NBER (2026) на 100 000+ разработчиках GitHub фиксируют реальность, от которой хочется выпить: автодополнение поднимает число коммитов на 40%, интерактивные агенты — на 140%, полностью автономные агенты — на 180%. А рост реальных релизов? Жалкие 30%. Разрыв в шесть раз.
Исследователи называют это «гипотезой слабого звена»: эластичность замещения человека ИИ в реальном цикле поставки ценности — всего 0,25. ИИ и разработчик не заменяют друг друга, они — комплементы, завязанные на одни и те же организационные бутылочные горлышки. Ускоренная генерация кода просто быстрее забивает эти бутылки.
«Сделай красиво» как технический долг
Вы говорите: «Да это всё ерунда, ИИ может автоматизировать и такое». Может. Только он выбирает не то, что вам нужно, а то, что статистически правдоподобно. А чувство прекрасного у заказчика привязано к колоссальному числу ассоциаций. Си шарп дотнет, Астра, Реакт, Флаттер — всё красиво, и всё выглядит убедительно на демо. Продажники под впечатлением от интеллекта и скорости продают эту убедительность, берут аванс, а потом команда месяцами не может сдать продукт. Промпты и ожидания не совпадают, представления об интеллектуальных системах у всех разные, и начинаются переделки. В случае с ИИ их больше, потому что нужна чистка стохастического выхлопа.
METR (2025) измерил это в лоб: разработчики ожидали сокращения времени задач на 24% при использовании ИИ-помощников — получили фактическое увеличение на 19%. Harness (2025) по США, Британии, Франции и Германии: 63% инженеров заявляют об ускорении создания кода, но 45% деплоев с ИИ-кодом приводят к проблемам, 73% предупреждают о расширении зоны поражения. 63% прямо называют «вайб-кодинг» катастрофой.
Так и живём: бизнес по-прежнему делается на вайбе, гибких менеджерах на шарнирах и ТЗ «сделай красиво». А стохастическую систему пытаются заставить работать как детерминированную кнопку.
Кнопка, инпут и проклятие стандартизации
Автор высказывания прав: проще сделать кнопку, инпут и прочее — с ними всё ясно. Но естественный язык сложен для стандартизации, и люди пока не понимают, что ИИ требует реализации скиллов и экономии токенов. Умная система дорогая по обращениям, дешёвая требует харнесса — жёсткой обвязки, валидации, детерминированных предохранителей. Без харнесса получается вот что: GitClear фиксирует увеличение дублирования кода в 8 раз, снижение повторного использования. Сложность кода растёт, число уязвимостей — в 1,5–2 раза, логических ошибок — на 75% чаще. А проверять это всё вы ставите своих самых дорогих людей.
Xu et al. (2026) показали, что опытные разработчики проверяют на 6,5% больше ИИ-сгенерированного кода, и их собственная продуктивность падает на 19%. Ускорили джунов — убили сеньоров.
Вы чувствуете это каждый спринт. Copilot строчит методы быстрее, чем вы читаете условие задачи. Claude генерирует микросервис по голосовому описанию. Продажники, ошалевшие от демо, уже продали интеллектуальную базу знаний, взяли аванс и поставили дедлайн «вчера». А релиз лежит в ветке и гниёт третью неделю. Коммитов — гора, работающего продукта — ноль. Почему?
Потому что вы ускорили то, что и так не было узким горлышком. А настоящий ад начался именно там, где вы не ждали.
Миф, который стоит миллиарды: код ≠ продукт
Свежайшие данные NBER (2026) на 100 000+ разработчиках GitHub фиксируют реальность, от которой хочется выпить: автодополнение поднимает число коммитов на 40%, интерактивные агенты — на 140%, полностью автономные агенты — на 180%. А рост реальных релизов? Жалкие 30%. Разрыв в шесть раз.
Исследователи называют это «гипотезой слабого звена»: эластичность замещения человека ИИ в реальном цикле поставки ценности — всего 0,25. ИИ и разработчик не заменяют друг друга, они — комплементы, завязанные на одни и те же организационные бутылочные горлышки. Ускоренная генерация кода просто быстрее забивает эти бутылки.
«Сделай красиво» как технический долг
Вы говорите: «Да это всё ерунда, ИИ может автоматизировать и такое». Может. Только он выбирает не то, что вам нужно, а то, что статистически правдоподобно. А чувство прекрасного у заказчика привязано к колоссальному числу ассоциаций. Си шарп дотнет, Астра, Реакт, Флаттер — всё красиво, и всё выглядит убедительно на демо. Продажники под впечатлением от интеллекта и скорости продают эту убедительность, берут аванс, а потом команда месяцами не может сдать продукт. Промпты и ожидания не совпадают, представления об интеллектуальных системах у всех разные, и начинаются переделки. В случае с ИИ их больше, потому что нужна чистка стохастического выхлопа.
METR (2025) измерил это в лоб: разработчики ожидали сокращения времени задач на 24% при использовании ИИ-помощников — получили фактическое увеличение на 19%. Harness (2025) по США, Британии, Франции и Германии: 63% инженеров заявляют об ускорении создания кода, но 45% деплоев с ИИ-кодом приводят к проблемам, 73% предупреждают о расширении зоны поражения. 63% прямо называют «вайб-кодинг» катастрофой.
Так и живём: бизнес по-прежнему делается на вайбе, гибких менеджерах на шарнирах и ТЗ «сделай красиво». А стохастическую систему пытаются заставить работать как детерминированную кнопку.
Кнопка, инпут и проклятие стандартизации
Автор высказывания прав: проще сделать кнопку, инпут и прочее — с ними всё ясно. Но естественный язык сложен для стандартизации, и люди пока не понимают, что ИИ требует реализации скиллов и экономии токенов. Умная система дорогая по обращениям, дешёвая требует харнесса — жёсткой обвязки, валидации, детерминированных предохранителей. Без харнесса получается вот что: GitClear фиксирует увеличение дублирования кода в 8 раз, снижение повторного использования. Сложность кода растёт, число уязвимостей — в 1,5–2 раза, логических ошибок — на 75% чаще. А проверять это всё вы ставите своих самых дорогих людей.
Xu et al. (2026) показали, что опытные разработчики проверяют на 6,5% больше ИИ-сгенерированного кода, и их собственная продуктивность падает на 19%. Ускорили джунов — убили сеньоров.
🤔1
Платформенная оркестрация: умножитель проблем, а не решение
Вы думаете, что платформенные сервисы с AI-оркестрацией спасут? Murakkab (MIT CSAIL + Microsoft Azure Research, 2025) зафиксировал: без специальной оптимизации оркестрации переплата достигает 4,3×, энергопотребление — до 3,7×, а задержки непредсказуемы. Каждый дополнительный LLM-вызов в цепочке добавляет латентность и стоимость. Большинство компаний используют «наивные» стратегии маршрутизации, не задумываясь об оптимизации. Результат — счета за API, от которых финансовый отдел падает в обморок, а продукт тормозит.
UX-ловушка: быстрее — не значит лучше
И последний гвоздь. CHI 2026 (Нью-Йоркский университет): ответы ИИ, приходящие за 2 секунды, воспринимаются пользователями как менее продуманные и менее полезные, чем те же ответы, полученные через 9 или 20 секунд. Пауза интерпретируется как признак «думанья». При этом стандартные UX-метрики — SUS, NPS — структурно непригодны для оценки стохастических систем (Vijayakumar 2026). Вы гонитесь за минимальной задержкой, тратите ресурсы, а пользователь считает результат поверхностным. Вы измеряете успех метриками, созданными для детерминированного софта, где одинаковый вход даёт одинаковый выход. Они врут.
Что со всем этим делать?
Tencent доказывает: при тотальной вертикальной интеграции, жёсткой дисциплине, стандартизации и AI-преревью 94% кода можно получить реальные +20% эффективности и снижение багов на 31,5%. Но это исключение. Accenture в Китае показывает: 46% компаний масштабируют GenAI, но только 9% добиваются значимой ценности. Разрыв пятикратный.
Пока бизнес не перестроит свои метрики, процессы и ожидания, ИИ будет ускорять создание проблем, а не их решение. Генерация кода — не bottleneck. Бутылочное горлышко — это то, что между ушами у заказчика, у продажника и у «гибкого менеджера», который не может сформулировать требования иначе как «сделай красиво».
Парадокс продуктивности-надёжности не рассосётся от новой модели GPT. Он зашит в самой природе стохастической системы, которую пытаются втиснуть в детерминированный бизнес-процесс с вайб-культурой управления. Исследования 2025–2026 годов это не опровергают — они это измеряют и документально фиксируют.
Хотите реального ускорения? Возвращайтесь к кнопке и инпуту — и пересобирайте управление продуктом с нуля. Либо готовьтесь платить за иллюзию скорости трижды: токенами, переделками и выгоранием тех, кто этот зоопарк разгребает.
Вы думаете, что платформенные сервисы с AI-оркестрацией спасут? Murakkab (MIT CSAIL + Microsoft Azure Research, 2025) зафиксировал: без специальной оптимизации оркестрации переплата достигает 4,3×, энергопотребление — до 3,7×, а задержки непредсказуемы. Каждый дополнительный LLM-вызов в цепочке добавляет латентность и стоимость. Большинство компаний используют «наивные» стратегии маршрутизации, не задумываясь об оптимизации. Результат — счета за API, от которых финансовый отдел падает в обморок, а продукт тормозит.
UX-ловушка: быстрее — не значит лучше
И последний гвоздь. CHI 2026 (Нью-Йоркский университет): ответы ИИ, приходящие за 2 секунды, воспринимаются пользователями как менее продуманные и менее полезные, чем те же ответы, полученные через 9 или 20 секунд. Пауза интерпретируется как признак «думанья». При этом стандартные UX-метрики — SUS, NPS — структурно непригодны для оценки стохастических систем (Vijayakumar 2026). Вы гонитесь за минимальной задержкой, тратите ресурсы, а пользователь считает результат поверхностным. Вы измеряете успех метриками, созданными для детерминированного софта, где одинаковый вход даёт одинаковый выход. Они врут.
Что со всем этим делать?
Tencent доказывает: при тотальной вертикальной интеграции, жёсткой дисциплине, стандартизации и AI-преревью 94% кода можно получить реальные +20% эффективности и снижение багов на 31,5%. Но это исключение. Accenture в Китае показывает: 46% компаний масштабируют GenAI, но только 9% добиваются значимой ценности. Разрыв пятикратный.
Пока бизнес не перестроит свои метрики, процессы и ожидания, ИИ будет ускорять создание проблем, а не их решение. Генерация кода — не bottleneck. Бутылочное горлышко — это то, что между ушами у заказчика, у продажника и у «гибкого менеджера», который не может сформулировать требования иначе как «сделай красиво».
Парадокс продуктивности-надёжности не рассосётся от новой модели GPT. Он зашит в самой природе стохастической системы, которую пытаются втиснуть в детерминированный бизнес-процесс с вайб-культурой управления. Исследования 2025–2026 годов это не опровергают — они это измеряют и документально фиксируют.
Хотите реального ускорения? Возвращайтесь к кнопке и инпуту — и пересобирайте управление продуктом с нуля. Либо готовьтесь платить за иллюзию скорости трижды: токенами, переделками и выгоранием тех, кто этот зоопарк разгребает.
🤔1
Привет. Я изучил все 787 ваших диалогов с Cline за четыре месяца и готов рассказать, как на самом деле выглядит работа с AI, когда в её основе лежат не хаотичные «вайбы», а дисциплина планирования, исследовательские цепочки мысли и прозрачная система приоритетов.
Начну с цифр:
1. 93,3% задач содержали структурированный план (focus chain) — чек-лист шагов.
2. 82,6% задач были полностью завершены по этому плану.
3. Медианное время активной работы на задачу — 13,8 минут.
4. Медианный интервал между сообщениями — 43 секунды.
5. Средняя стоимость одной задачи — $0,017.
Главное, что опровергает миф о «вайб-кодинге» в моём случае, — статистика focus chain. Практически каждая задача (93,3%) начиналась с создания или активации чек-листа: разбивка на атомарные шаги, дедолжные привязки к бэклогу (TASK-RICE-006 и подобные), явная приоритезация. Модель не просто получала размытое пожелание, а работала в рамках заранее сформулированного плана.
Результат — 82,6% задач доведены до полного выполнения всех пунктов. Оставшиеся 17,4% — это не провалы, а осознанно приостановленные или разбитые на следующие итерации работы. Такой процент завершённости в разработке (да ещё и в соло-режиме) трудно переоценить: он говорит о том, что плановая дисциплина работает, и AI-агент не сходит с рельсов, если рельсы проложены заранее.
Следующий слой — это когнитивный процесс. Я использую агентный подход, в котором модель может находиться в двух режимах: plan (планирование, исследование, рассуждение по цепочке — CoT) и act (непосредственные действия: генерация кода, запуск команд, запись файлов). Суммарно за 787 задач накопилось 37 743 сообщения, из которых 33,1% — plan, а 66,9% — act.
Внимательный взгляд на модели показывает, что это соотношение не случайно, а осознанно управляемо. Там, где нужна глубокая проработка архитектуры или исследование неизвестной территории, я чаще задействую deepseek-chat и deepseek-v4-pro: у них plan составляет 54,6% и 54,2% соответственно. Для быстрых реализаций, когда план уже ясен, идёт MiniMax-M2.7 с 32,7% plan и 67,3% act. Qwen в нескольких задачах отработал исключительно в act — и это были строго очерченные поручения без планирования.
Иными словами, «вайб» не диктует модель, а я выбираю инструмент под фазу задачи. И данные подтверждают, что планирование не потеряно, а занимает ровно столько эфирного времени, сколько требуется, чтобы затем действовать быстро.
Медианный интервал между сообщениями в 43 секунды — это темп реального диалога. Да, среднее время сильно улетает из-за ночных пауз (idle 86% от астрономического времени), но костяк работы — быстрые, сфокусированные переписки. Медианное активное время задачи — 13,8 минут. Половина всех задач уложилась в этот отрезок чистого взаимодействия с агентом.
Средняя стоимость задачи — $0,0166. Основная рабочая лошадка MiniMax-M2.7 обходится в $0,00026 за задачу. Deepseek-chat, который используется для сложных плановых сессий, дороже ($0,134), но применяется дозированно. Я не гоняю дорогие модели на черновую работу, и это видно по распределению: 520 задач на MiniMax-M2.7 и лишь 45 — на deepseek-chat.
Кэширование промптов — ещё одно доказательство эффективности. После исправления бага в скриптах выяснилось, что 63% задач имеют ненулевой cache hit, а общий коэффициент попадания в кэш — 58,3%. Больше половины токенов не требуют повторных вычислений. В комбинации с низкой стоимостью и малым активным временем это означает, что инфраструктура работает с высоким КПД, и я не плачу за воздух.
86,9% задач выполнены с одной моделью. Ещё 10,9% — с двумя, и лишь в 1% случаев задействованы три или четыре модели. Это не «охота за идеальной моделью», а осознанная тактика: например, начать с deepseek для планирования, затем переключиться на MiniMax для реализации. Данные, увы, не фиксируют причину смены, но характер задач и моделей позволяет говорить о целенаправленной маршрутизации, а не о панике.
Что всё это значит для подхода в целом
Начну с цифр:
1. 93,3% задач содержали структурированный план (focus chain) — чек-лист шагов.
2. 82,6% задач были полностью завершены по этому плану.
3. Медианное время активной работы на задачу — 13,8 минут.
4. Медианный интервал между сообщениями — 43 секунды.
5. Средняя стоимость одной задачи — $0,017.
Главное, что опровергает миф о «вайб-кодинге» в моём случае, — статистика focus chain. Практически каждая задача (93,3%) начиналась с создания или активации чек-листа: разбивка на атомарные шаги, дедолжные привязки к бэклогу (TASK-RICE-006 и подобные), явная приоритезация. Модель не просто получала размытое пожелание, а работала в рамках заранее сформулированного плана.
Результат — 82,6% задач доведены до полного выполнения всех пунктов. Оставшиеся 17,4% — это не провалы, а осознанно приостановленные или разбитые на следующие итерации работы. Такой процент завершённости в разработке (да ещё и в соло-режиме) трудно переоценить: он говорит о том, что плановая дисциплина работает, и AI-агент не сходит с рельсов, если рельсы проложены заранее.
Следующий слой — это когнитивный процесс. Я использую агентный подход, в котором модель может находиться в двух режимах: plan (планирование, исследование, рассуждение по цепочке — CoT) и act (непосредственные действия: генерация кода, запуск команд, запись файлов). Суммарно за 787 задач накопилось 37 743 сообщения, из которых 33,1% — plan, а 66,9% — act.
Внимательный взгляд на модели показывает, что это соотношение не случайно, а осознанно управляемо. Там, где нужна глубокая проработка архитектуры или исследование неизвестной территории, я чаще задействую deepseek-chat и deepseek-v4-pro: у них plan составляет 54,6% и 54,2% соответственно. Для быстрых реализаций, когда план уже ясен, идёт MiniMax-M2.7 с 32,7% plan и 67,3% act. Qwen в нескольких задачах отработал исключительно в act — и это были строго очерченные поручения без планирования.
Иными словами, «вайб» не диктует модель, а я выбираю инструмент под фазу задачи. И данные подтверждают, что планирование не потеряно, а занимает ровно столько эфирного времени, сколько требуется, чтобы затем действовать быстро.
Медианный интервал между сообщениями в 43 секунды — это темп реального диалога. Да, среднее время сильно улетает из-за ночных пауз (idle 86% от астрономического времени), но костяк работы — быстрые, сфокусированные переписки. Медианное активное время задачи — 13,8 минут. Половина всех задач уложилась в этот отрезок чистого взаимодействия с агентом.
Средняя стоимость задачи — $0,0166. Основная рабочая лошадка MiniMax-M2.7 обходится в $0,00026 за задачу. Deepseek-chat, который используется для сложных плановых сессий, дороже ($0,134), но применяется дозированно. Я не гоняю дорогие модели на черновую работу, и это видно по распределению: 520 задач на MiniMax-M2.7 и лишь 45 — на deepseek-chat.
Кэширование промптов — ещё одно доказательство эффективности. После исправления бага в скриптах выяснилось, что 63% задач имеют ненулевой cache hit, а общий коэффициент попадания в кэш — 58,3%. Больше половины токенов не требуют повторных вычислений. В комбинации с низкой стоимостью и малым активным временем это означает, что инфраструктура работает с высоким КПД, и я не плачу за воздух.
86,9% задач выполнены с одной моделью. Ещё 10,9% — с двумя, и лишь в 1% случаев задействованы три или четыре модели. Это не «охота за идеальной моделью», а осознанная тактика: например, начать с deepseek для планирования, затем переключиться на MiniMax для реализации. Данные, увы, не фиксируют причину смены, но характер задач и моделей позволяет говорить о целенаправленной маршрутизации, а не о панике.
Что всё это значит для подхода в целом
Мой стиль работы с AI-агентом — это не магия и не «сгенерируй мне приложение». Это task plan-based метод:
1. Формулировка задачи с приоритетом.
2. Создание чек-листа (focus chain) — агент понимает, куда идти.
3. Фаза plan — исследование, CoT, валидация архитектуры.
4. Фаза act — быстрая реализация под присмотром.
5. Итеративная приёмка и движение по чек-листу до 100%.
Цифры показывают, что такой подход даёт предсказуемо высокий процент завершения, ничтожную стоимость, высокий темп итераций и минимальный оверхед на переделку. Конечно, данные не идеальны: метрики churn (реального переписывания файлов) пока не собираются, и без них я не могу утверждать, что модель не переписывает одно и то же. Но косвенные признаки — высокий процент завершённости, быстрые итерации, малое активное время — скорее свидетельствуют о том, что переписываний немного.
Если вы слышите «вайб-кодинг» и представляете хаотичное «сделай красиво», мои 787 задач показывают обратное: за фасадом простого общения с агентом стоит строгая система планирования, приоритезации и рефлексии. Именно она позволяет превратить AI в производительного напарника, который не просто отвлекает, а методично закрывает пункты бэклога — быстро, дёшево и с понятным результатом.
1. Формулировка задачи с приоритетом.
2. Создание чек-листа (focus chain) — агент понимает, куда идти.
3. Фаза plan — исследование, CoT, валидация архитектуры.
4. Фаза act — быстрая реализация под присмотром.
5. Итеративная приёмка и движение по чек-листу до 100%.
Цифры показывают, что такой подход даёт предсказуемо высокий процент завершения, ничтожную стоимость, высокий темп итераций и минимальный оверхед на переделку. Конечно, данные не идеальны: метрики churn (реального переписывания файлов) пока не собираются, и без них я не могу утверждать, что модель не переписывает одно и то же. Но косвенные признаки — высокий процент завершённости, быстрые итерации, малое активное время — скорее свидетельствуют о том, что переписываний немного.
Если вы слышите «вайб-кодинг» и представляете хаотичное «сделай красиво», мои 787 задач показывают обратное: за фасадом простого общения с агентом стоит строгая система планирования, приоритезации и рефлексии. Именно она позволяет превратить AI в производительного напарника, который не просто отвлекает, а методично закрывает пункты бэклога — быстро, дёшево и с понятным результатом.
Парадокс управления при разработке AI-продуктов
Сейчас во все щели и дыры нам пихают ИИ. Мы массово переходим на генеративные инструменты, планируем продукты с GenAI, думаем о том, как сократить, переиспользовать и автоматизировать разработку. Бизнес этого хочет и мечтает. Но стоит нам начать использовать GenAI для общения с самим бизнесом — возникает любопытный парадокс. Нас тут же обвиняют в нейрослопе и brain rot.
За последние восемь месяцев я собрал минимум пять разных кейсов — заказная разработка, fractional CTO, консультации по исследованиям. В сумме с чужими наблюдениями из соцсетей складывается тревожная картина. Мы внедряем AI везде: анализируем ответы клиентов через генеративные модели, генерируем вопросы для коммуникации, работаем с суппортом, пишем тексты, проводим аудиты, создаём отчёты для начальства. Но когда тот же самый бизнес, который требует экономии, скорости и масштабирования, получает от нас AI-сгенерированное сообщение — он чувствует себя оскорблённым. Ему не хватает «человеческого общения».
Заказчик давит на экономию времени, требует ускорения и сокращения издержек. При этом сам же инициирует офлайн-встречи по старинке. И хочет общаться без диктофонов, без транскрибации, без «генеративных сообщений». Почему? Потому что «это уважение».
Я смотрю на стол, где перед каждым лежит телефон. Любой телефон — включённый или выключенный — это микрофон, процессор, хранилище, батарейка и сетевой адаптер. Мы всегда сидим с диктофоном. Приватность разговора, когда у всех на столе гаджеты и любой может начать запись, — оксюморон. Тем не менее иллюзия приватности и «живого» контакта перевешивает здравый смысл.
Тут я вспоминаю принцип Toyota из кайдзен: мы должны сами использовать свой продукт, чтобы прожить боли клиентов и на основе этого анализа улучшать продукт. Если ты строишь бизнес на GenAI-решениях, но тебя тошнит от GenAI-письма — значит, ты отказываешься есть собственную собачью еду. Но почему?
Разгадка, как выясняется, имеет научное обоснование. Свежие исследования 2025–2026 годов вскрывают системный психологический сдвиг.
Во-первых, Coman и Cardon (2026) опросили 1100 профессионалов и выявили «разрыв восприятия». Когда руководитель использует AI в письме с похвалой или обратной связью, сотрудники оценивают его искренность на 40–52% ниже, чем если бы письмо было написано вручную. Но собственное использование AI теми же сотрудниками не вызывает у них сомнений в искренности. Люди думают: «Я-то AI-текст проверяю и вкладываю душу, а руководитель — просто поленился». Двойной стандарт налицо.
Во-вторых, Hunter.io (2025) обнаружили парадокс холодных писем в B2B. 47% профессионалов говорят, что не ответят на письмо, если заподозрят в нём AI. Но 67% тех же самых людей, выступая в роли получателей, признают, что им всё равно, написано письмо AI или человеком, если оно релевантно. Мы боимся, что получатель накажет нас за AI, хотя на деле он наказывает только за плохой контент.
В-третьих, Hajder (2025) экспериментально доказал: сама по себе пометка «создано AI» снижает воспринимаемую подлинность сообщения, даже если получатель отлично знаком с AI и активно им пользуется. Это чистая эмоциональная реакция, которую не снимает рациональное понимание технологии.
Объединим: бизнес видит в нашем AI-письме не результат работы умного инструмента, а сигнал «мы не захотели тратить на тебя своё драгоценное человеческое время». Требуя от нас внедрять AI для экономии, заказчик невольно требует признать, что его собственное время не настолько ценно, чтобы на него тратили живого человека. А с этим смириться невозможно.
Значит ли это, что «есть свой продукт» в эпоху GenAI — утопия? Должны ли мы принять, что AI-коммуникация всегда будет восприниматься как угроза статусу, и оставить людям островок «настоящего» общения, даже если он технологически иллюзорен? Или наша задача — последовательно приучать бизнес к тому, что AI-сообщение — это и есть проявление уважения: мы потратили меньше рутины, чтобы освободить голову для сложных задач?
Что думаете вы? Вам знакомо такое отторжение — и с какой стороны баррикад вы его наблюдали?
Сейчас во все щели и дыры нам пихают ИИ. Мы массово переходим на генеративные инструменты, планируем продукты с GenAI, думаем о том, как сократить, переиспользовать и автоматизировать разработку. Бизнес этого хочет и мечтает. Но стоит нам начать использовать GenAI для общения с самим бизнесом — возникает любопытный парадокс. Нас тут же обвиняют в нейрослопе и brain rot.
За последние восемь месяцев я собрал минимум пять разных кейсов — заказная разработка, fractional CTO, консультации по исследованиям. В сумме с чужими наблюдениями из соцсетей складывается тревожная картина. Мы внедряем AI везде: анализируем ответы клиентов через генеративные модели, генерируем вопросы для коммуникации, работаем с суппортом, пишем тексты, проводим аудиты, создаём отчёты для начальства. Но когда тот же самый бизнес, который требует экономии, скорости и масштабирования, получает от нас AI-сгенерированное сообщение — он чувствует себя оскорблённым. Ему не хватает «человеческого общения».
Заказчик давит на экономию времени, требует ускорения и сокращения издержек. При этом сам же инициирует офлайн-встречи по старинке. И хочет общаться без диктофонов, без транскрибации, без «генеративных сообщений». Почему? Потому что «это уважение».
Я смотрю на стол, где перед каждым лежит телефон. Любой телефон — включённый или выключенный — это микрофон, процессор, хранилище, батарейка и сетевой адаптер. Мы всегда сидим с диктофоном. Приватность разговора, когда у всех на столе гаджеты и любой может начать запись, — оксюморон. Тем не менее иллюзия приватности и «живого» контакта перевешивает здравый смысл.
Тут я вспоминаю принцип Toyota из кайдзен: мы должны сами использовать свой продукт, чтобы прожить боли клиентов и на основе этого анализа улучшать продукт. Если ты строишь бизнес на GenAI-решениях, но тебя тошнит от GenAI-письма — значит, ты отказываешься есть собственную собачью еду. Но почему?
Разгадка, как выясняется, имеет научное обоснование. Свежие исследования 2025–2026 годов вскрывают системный психологический сдвиг.
Во-первых, Coman и Cardon (2026) опросили 1100 профессионалов и выявили «разрыв восприятия». Когда руководитель использует AI в письме с похвалой или обратной связью, сотрудники оценивают его искренность на 40–52% ниже, чем если бы письмо было написано вручную. Но собственное использование AI теми же сотрудниками не вызывает у них сомнений в искренности. Люди думают: «Я-то AI-текст проверяю и вкладываю душу, а руководитель — просто поленился». Двойной стандарт налицо.
Во-вторых, Hunter.io (2025) обнаружили парадокс холодных писем в B2B. 47% профессионалов говорят, что не ответят на письмо, если заподозрят в нём AI. Но 67% тех же самых людей, выступая в роли получателей, признают, что им всё равно, написано письмо AI или человеком, если оно релевантно. Мы боимся, что получатель накажет нас за AI, хотя на деле он наказывает только за плохой контент.
В-третьих, Hajder (2025) экспериментально доказал: сама по себе пометка «создано AI» снижает воспринимаемую подлинность сообщения, даже если получатель отлично знаком с AI и активно им пользуется. Это чистая эмоциональная реакция, которую не снимает рациональное понимание технологии.
Объединим: бизнес видит в нашем AI-письме не результат работы умного инструмента, а сигнал «мы не захотели тратить на тебя своё драгоценное человеческое время». Требуя от нас внедрять AI для экономии, заказчик невольно требует признать, что его собственное время не настолько ценно, чтобы на него тратили живого человека. А с этим смириться невозможно.
Значит ли это, что «есть свой продукт» в эпоху GenAI — утопия? Должны ли мы принять, что AI-коммуникация всегда будет восприниматься как угроза статусу, и оставить людям островок «настоящего» общения, даже если он технологически иллюзорен? Или наша задача — последовательно приучать бизнес к тому, что AI-сообщение — это и есть проявление уважения: мы потратили меньше рутины, чтобы освободить голову для сложных задач?
Что думаете вы? Вам знакомо такое отторжение — и с какой стороны баррикад вы его наблюдали?
🤔2
Почему промпт не заменяет GraphQL, а MCP — не шина данных
Начинать разговор об агентных архитектурах стоит с отрезвляющего тезиса: промпт не является заменой ни агрегирующим запросам, ни GraphQL, ни контекстному поиску. Это распространённое упрощение, которое на практике ведёт к архитектурной деградации.
Промпт — слой интерпретации. Он получает уже собранные и переданные в контекст данные и объясняет модели, что с ними делать. Сам он не умеет обращаться к базе, строить join'ы и резолвить эндпоинты. Путать его со средствами доступа к данным — значит добровольно отказываться от контрактов, строгой схемы и предсказуемости.
Однако возникает закономерный вопрос: если промпт только интерпретирует, то каким образом агент динамически выбирает инструменты и источники? Здесь появляется Model Context Protocol (MCP) — и вместе с ним новая волна заблуждений. MCP-сервер описывают как замену шины данных и GraphQL, что технически некорректно.
MCP — это универсальный адаптер. Он предоставляет агенту стандартизированный интерфейс к трём сущностям: Tools (действия), Resources (данные), Prompts (шаблоны). Но под капотом MCP-сервер вызывает те же REST, GraphQL или SQL, а не подменяет их. Он не занимается трансформацией сообщений, не гарантирует доставку, не обеспечивает транзакционную целостность и, главное, не принимает решений о маршрутизации. Решение о том, какой инструмент вызвать, принимает LLM — недетерминированно, на основе описания.
Именно здесь возникает то самое «поле чудес и русская рулетка», о которых говорилось ранее: агент угадывает инструмент, а результат этого угадывания может быть как точным, так и разрушительным. MCP здесь выполняет роль стандартизированного слоя доступа, но не роль шины данных. Считать «агент + MCP» эволюцией ESB — ошибка. ESB обеспечивает детерминированную маршрутизацию по правилам; MCP обеспечивает стохастический выбор, ограниченный лишь качеством промпта и описаний инструментов.
Практический вывод: антипаттерн «заменили GraphQL промптом» не просто неточен, он опасен. Правильная архитектура подразумевает чёткое разделение: GraphQL и REST — для детерминированной работы с данными, промпты и MCP-адаптеры — для недетерминированного принятия решений. Агент без проверенной API-подложки беспомощен, а его «гибкость» превращается в генератор ошибок.
Начинать разговор об агентных архитектурах стоит с отрезвляющего тезиса: промпт не является заменой ни агрегирующим запросам, ни GraphQL, ни контекстному поиску. Это распространённое упрощение, которое на практике ведёт к архитектурной деградации.
Промпт — слой интерпретации. Он получает уже собранные и переданные в контекст данные и объясняет модели, что с ними делать. Сам он не умеет обращаться к базе, строить join'ы и резолвить эндпоинты. Путать его со средствами доступа к данным — значит добровольно отказываться от контрактов, строгой схемы и предсказуемости.
Однако возникает закономерный вопрос: если промпт только интерпретирует, то каким образом агент динамически выбирает инструменты и источники? Здесь появляется Model Context Protocol (MCP) — и вместе с ним новая волна заблуждений. MCP-сервер описывают как замену шины данных и GraphQL, что технически некорректно.
MCP — это универсальный адаптер. Он предоставляет агенту стандартизированный интерфейс к трём сущностям: Tools (действия), Resources (данные), Prompts (шаблоны). Но под капотом MCP-сервер вызывает те же REST, GraphQL или SQL, а не подменяет их. Он не занимается трансформацией сообщений, не гарантирует доставку, не обеспечивает транзакционную целостность и, главное, не принимает решений о маршрутизации. Решение о том, какой инструмент вызвать, принимает LLM — недетерминированно, на основе описания.
Именно здесь возникает то самое «поле чудес и русская рулетка», о которых говорилось ранее: агент угадывает инструмент, а результат этого угадывания может быть как точным, так и разрушительным. MCP здесь выполняет роль стандартизированного слоя доступа, но не роль шины данных. Считать «агент + MCP» эволюцией ESB — ошибка. ESB обеспечивает детерминированную маршрутизацию по правилам; MCP обеспечивает стохастический выбор, ограниченный лишь качеством промпта и описаний инструментов.
Практический вывод: антипаттерн «заменили GraphQL промптом» не просто неточен, он опасен. Правильная архитектура подразумевает чёткое разделение: GraphQL и REST — для детерминированной работы с данными, промпты и MCP-адаптеры — для недетерминированного принятия решений. Агент без проверенной API-подложки беспомощен, а его «гибкость» превращается в генератор ошибок.
Оркестрация: workflow-движки против LLM-графов
Второй срез, где агентные системы вступают в конфликт с классической инженерией, — оркестрация.
Традиционные workflow-движки (Temporal, Camunda) строятся на жёстких схемах. Шаг A всегда предшествует шагу B, откат идёт по компенсационным транзакциям, идемпотентность гарантирована. Агентная оркестрация устроена иначе. Здесь оркестратором выступает LLM, которая динамически определяет последовательность действий. Паттерны ReAct, Plan-and-Execute, Supervisor + Workers, LangGraph-графы объединяет отказ от заранее заданной схемы в пользу рантайм-планирования.
Это даёт гибкость, недоступную классическим workflow, но плата за неё — потеря предсказуемости. Тот же промпт, тот же контекст — и агент может пойти по разным цепочкам вызовов. Он может зациклиться, выбрать нерелевантный инструмент, сгенерировать галлюцинацию. Метафора «русской рулетки» здесь описывает не эмоции, а реальный инженерный риск: отсутствие гарантий повторяемости.
Что из классики необходимо заимствовать в обязательном порядке:
1. Structured Output (JSON Schema). Без жёсткой валидации выходных данных агента любая последующая детерминированная логика обречена.
2. Hard checkpoints и Human-in-the-Loop. Критические действия — платежи, изменения в production, юридически значимые операции — не должны выполняться без подтверждения человека.
3. Retry с детерминированной логикой. Не всякая ошибка исправляется переспросом LLM; для некоторых операций нужен классический экспоненциальный backoff и fallback.
Отдельного внимания заслуживает попытка применить паттерн Saga к мультиагентным взаимодействиям. Если рассматривать каждое решение агента как событие, которое можно сохранить (Event Sourcing), мы получаем воспроизводимость, аудит и потенциальную возможность отката. Но реализация упирается в недетерминизм повторов (тот же промпт может дать иной результат) и объём данных. Тем не менее без этой базы мы даже не можем установить, почему агент ошибся. Event Sourcing для агентов — не серебряная пуля, а необходимый гигиенический минимум.
Агентный оркестратор, таким образом, не заменяет workflow-движок. Он надстраивается над ним. Сильный инженер оставляет жёсткий детерминированный скелет и позволяет LLM импровизировать только внутри проверенных, валидированных ворот.
Второй срез, где агентные системы вступают в конфликт с классической инженерией, — оркестрация.
Традиционные workflow-движки (Temporal, Camunda) строятся на жёстких схемах. Шаг A всегда предшествует шагу B, откат идёт по компенсационным транзакциям, идемпотентность гарантирована. Агентная оркестрация устроена иначе. Здесь оркестратором выступает LLM, которая динамически определяет последовательность действий. Паттерны ReAct, Plan-and-Execute, Supervisor + Workers, LangGraph-графы объединяет отказ от заранее заданной схемы в пользу рантайм-планирования.
Это даёт гибкость, недоступную классическим workflow, но плата за неё — потеря предсказуемости. Тот же промпт, тот же контекст — и агент может пойти по разным цепочкам вызовов. Он может зациклиться, выбрать нерелевантный инструмент, сгенерировать галлюцинацию. Метафора «русской рулетки» здесь описывает не эмоции, а реальный инженерный риск: отсутствие гарантий повторяемости.
Что из классики необходимо заимствовать в обязательном порядке:
1. Structured Output (JSON Schema). Без жёсткой валидации выходных данных агента любая последующая детерминированная логика обречена.
2. Hard checkpoints и Human-in-the-Loop. Критические действия — платежи, изменения в production, юридически значимые операции — не должны выполняться без подтверждения человека.
3. Retry с детерминированной логикой. Не всякая ошибка исправляется переспросом LLM; для некоторых операций нужен классический экспоненциальный backoff и fallback.
Отдельного внимания заслуживает попытка применить паттерн Saga к мультиагентным взаимодействиям. Если рассматривать каждое решение агента как событие, которое можно сохранить (Event Sourcing), мы получаем воспроизводимость, аудит и потенциальную возможность отката. Но реализация упирается в недетерминизм повторов (тот же промпт может дать иной результат) и объём данных. Тем не менее без этой базы мы даже не можем установить, почему агент ошибся. Event Sourcing для агентов — не серебряная пуля, а необходимый гигиенический минимум.
Агентный оркестратор, таким образом, не заменяет workflow-движок. Он надстраивается над ним. Сильный инженер оставляет жёсткий детерминированный скелет и позволяет LLM импровизировать только внутри проверенных, валидированных ворот.
Гибридный стек и трезвый взгляд на агентные системы
Предыдущие два поста подводят к центральному архитектурному принципу: агентная система должна состоять из двух чётко разделённых слоёв.
Первый — детерминированный скелет. Это код, базы данных, REST/GraphQL API, очереди сообщений, workflow-движки. Всё, что можно протестировать, верифицировать и гарантировать. Второй — недетерминированный мозг. LLM и промпты. Вся вариативность, которую мы допускаем, должна быть ограничена этим слоем, а его выходы обязаны проходить через жёсткие валидационные ворота обратно в скелет.
MCP и A2A в этом стеке — адаптеры, а не замена существующей инфраструктуры. За каждым MCP-сервером стоит проверенный API с контрактом. Агент получает доступ к инструментам, но не подменяет их собой. Ровно так же A2A (Agent-to-Agent) стандартизирует взаимодействие между агентами, но не отменяет необходимости в классических протоколах передачи данных.
Отдельное требование — observability как first-class citizen. К классическому distributed tracing добавляются LLM-специфичные метрики: токсичность, галлюцинации, стоимость задачи, количество вызовов инструментов. Принципиально важно отвечать не только на вопрос «что произошло», но и «почему агент принял такое решение». Без этого инженерная команда остаётся слепа.
HITL в критических точках и Event Sourcing для аудита решений — не опциональные украшения, а страховочные механизмы. Агент может предлагать действие, но не выполнять его без подтверждения, а каждое его решение должно быть сохранено как событие для последующего анализа и, при необходимости, отката.
Итог не новый, но отрезвляющий. Мы знаем, что агентные системы нестабильны, что промпты плывут, MCP-серверы падают, а оркестрация может превратиться в хаос. Однако мы знаем, как это исправить — не магией, а инженерной дисциплиной. Разделение скелета и мозга, валидация выходов, observability, контроль человека, событийный аудит. Это не хайп, это эволюционное расширение проверенных архитектурных паттернов. И именно в этом — зрелость AI-инжиниринга.
Предыдущие два поста подводят к центральному архитектурному принципу: агентная система должна состоять из двух чётко разделённых слоёв.
Первый — детерминированный скелет. Это код, базы данных, REST/GraphQL API, очереди сообщений, workflow-движки. Всё, что можно протестировать, верифицировать и гарантировать. Второй — недетерминированный мозг. LLM и промпты. Вся вариативность, которую мы допускаем, должна быть ограничена этим слоем, а его выходы обязаны проходить через жёсткие валидационные ворота обратно в скелет.
MCP и A2A в этом стеке — адаптеры, а не замена существующей инфраструктуры. За каждым MCP-сервером стоит проверенный API с контрактом. Агент получает доступ к инструментам, но не подменяет их собой. Ровно так же A2A (Agent-to-Agent) стандартизирует взаимодействие между агентами, но не отменяет необходимости в классических протоколах передачи данных.
Отдельное требование — observability как first-class citizen. К классическому distributed tracing добавляются LLM-специфичные метрики: токсичность, галлюцинации, стоимость задачи, количество вызовов инструментов. Принципиально важно отвечать не только на вопрос «что произошло», но и «почему агент принял такое решение». Без этого инженерная команда остаётся слепа.
HITL в критических точках и Event Sourcing для аудита решений — не опциональные украшения, а страховочные механизмы. Агент может предлагать действие, но не выполнять его без подтверждения, а каждое его решение должно быть сохранено как событие для последующего анализа и, при необходимости, отката.
Итог не новый, но отрезвляющий. Мы знаем, что агентные системы нестабильны, что промпты плывут, MCP-серверы падают, а оркестрация может превратиться в хаос. Однако мы знаем, как это исправить — не магией, а инженерной дисциплиной. Разделение скелета и мозга, валидация выходов, observability, контроль человека, событийный аудит. Это не хайп, это эволюционное расширение проверенных архитектурных паттернов. И именно в этом — зрелость AI-инжиниринга.
20 лет в разработке. MBA. «Бауманка». 10 лет в руководстве. И я устал, но...
Не от кода. Не от сложных архитектур. А от вечного «базар-вокзала», который в некоторых компаниях называют «корпоративной культурой».
Особенно там, где вроде бы пытаются сохранить дух стартапа, а сами уже — ентерпрайз на 2500 человек. Митинги ради митингов. Согласования ради согласований. И момент, когда Вася без технического образования вдруг ловит «озарение», как правильно делать авторизацию. Или почему синхронные вызовы — это ад. И ты сидишь и думаешь: «Господи, за что».
Я долго считал, что агентная разработка — это очередной хайп. Ну, такой же фейк, как «мы переходим на Agile» в департаменте из трёх тысяч человек. Но в прошлом году начал погружаться. И понял: не фейк.
Да, работает нестабильно. Примерно так же, как люди. Иногда сотрудники приходят на работу пьяными или под грибами — и ничего, терпим. LLM тоже глючит, галлюцинирует, путает языки. Но есть одно критическое различие.
Нет подковёрных решений.
С LLM ты хотя бы точно знаешь её особенности и пределы непредсказуемости. Она не играет в политику. Не копит обиду. Не «забывает» предупредить о риске, потому что «ну, я думал, это и так понятно». С ней ты — дирижёр. Или, если угодно, Аид. Подземный Зевс. Тот, кто не просто управляет, а властвует над самими основами процесса. Гефест куёт свои механизмы, а ты — решаешь, как они будут работать, без оглядки на чьё-то эго.
Я как архитектор хочу одного: свести дебильное общение к минимуму. Оставить только суть. И вот тут AI-агенты дают то, чего не даёт ни одна org structure: прозрачность без политики и исполнительность без переработок.
В моей текущей системе агент закрывает роли разработчика, ревьюера, девопса и даже продакт-менеджера. Я лишь задаю направление. И главное — больше никаких «озарений» от Васи. Есть зафиксированные правила, архитектурные решения и автоматический аудит того, что раньше приходилось вылавливать руками.
Это не волшебная таблетка. Это архитектура. Методология. Её нужно правильно выстроить, но когда она работает — ты перестаёшь быть пожарным и становишься создателем.
Если вам тоже надоел базар-вокзал и хочется обсудить, как перевести рутину на агентов, а себе оставить стратегию и архитектуру — напишите в личные сообщения. Я расскажу, с чего начать и какие грабли я уже собрал за вас.
Не от кода. Не от сложных архитектур. А от вечного «базар-вокзала», который в некоторых компаниях называют «корпоративной культурой».
Особенно там, где вроде бы пытаются сохранить дух стартапа, а сами уже — ентерпрайз на 2500 человек. Митинги ради митингов. Согласования ради согласований. И момент, когда Вася без технического образования вдруг ловит «озарение», как правильно делать авторизацию. Или почему синхронные вызовы — это ад. И ты сидишь и думаешь: «Господи, за что».
Я долго считал, что агентная разработка — это очередной хайп. Ну, такой же фейк, как «мы переходим на Agile» в департаменте из трёх тысяч человек. Но в прошлом году начал погружаться. И понял: не фейк.
Да, работает нестабильно. Примерно так же, как люди. Иногда сотрудники приходят на работу пьяными или под грибами — и ничего, терпим. LLM тоже глючит, галлюцинирует, путает языки. Но есть одно критическое различие.
Нет подковёрных решений.
С LLM ты хотя бы точно знаешь её особенности и пределы непредсказуемости. Она не играет в политику. Не копит обиду. Не «забывает» предупредить о риске, потому что «ну, я думал, это и так понятно». С ней ты — дирижёр. Или, если угодно, Аид. Подземный Зевс. Тот, кто не просто управляет, а властвует над самими основами процесса. Гефест куёт свои механизмы, а ты — решаешь, как они будут работать, без оглядки на чьё-то эго.
Я как архитектор хочу одного: свести дебильное общение к минимуму. Оставить только суть. И вот тут AI-агенты дают то, чего не даёт ни одна org structure: прозрачность без политики и исполнительность без переработок.
В моей текущей системе агент закрывает роли разработчика, ревьюера, девопса и даже продакт-менеджера. Я лишь задаю направление. И главное — больше никаких «озарений» от Васи. Есть зафиксированные правила, архитектурные решения и автоматический аудит того, что раньше приходилось вылавливать руками.
Это не волшебная таблетка. Это архитектура. Методология. Её нужно правильно выстроить, но когда она работает — ты перестаёшь быть пожарным и становишься создателем.
Если вам тоже надоел базар-вокзал и хочется обсудить, как перевести рутину на агентов, а себе оставить стратегию и архитектуру — напишите в личные сообщения. Я расскажу, с чего начать и какие грабли я уже собрал за вас.
Не ИИ, а «Емели»: почему деградация менеджмента разрушает индустрию (программисты тут ни при чём)
В русском фольклоре есть персонаж Емеля — парень, который лежит на печи и ждёт, что всё сделается само, по щучьему велению. Сегодня это архетип целого класса IT-менеджеров. Они не умеют управлять скоупом, не считают экономику, не понимают инженерной культуры. Но главное — они ищут не экспертизу, а «вайб» или «мэтч», веря, что правильная энергия и культурное совпадение важнее профессиональных навыков.
Этот тип массово захватил управленческие позиции, и у него появилось новое оружие — ИИ. Не против инженеров, а против самой инженерии.
ИИ как «щучье веление»
Данные не подтверждают истерику о том, что ИИ заменяет программистов. SignalFire (2026): инженеры — 55% новых наймов в тех-гигантах, исторический максимум. Спрос на квалифицированных разработчиков растёт. Дженсен Хуанг, CEO Nvidia, сказал прямо: «Маловероятно, что вас заменит ИИ. Вас обойдёт человек, который умеет его использовать».
Проблема не в технологии. Проблема в том, как её использует Емеля. Для него ИИ — та самая волшебная щука, которая должна исполнить любое желание без его участия. А раз так, зачем вообще напрягаться?
Атака на джуниоров: «печь» стала уже
Логика Емели-менеджера проста: «Сеньор с ИИ делает задачу джуниора за часы. Зачем нам джуниор?» И он прав — сегодня. Завтра станет некому стать тем самым сеньором.
Цифры жёсткие: в США количество junior-позиций рухнуло вдвое от пика 2022-го. Занятость разработчиков 22–25 лет упала на 20% (Stanford). Буткемпы, обещавшие 72% трудоустройства, скатились к 18%. Емеля не экономит — он уничтожает лестницу, по которой инженер годами карабкался от простых задач к архитектурным решениям.
Сеньор как надсмотрщик вместо мастера
Оставшихся сеньоров Емеля превращает в надзирателей ИИ-кода. Вместо созидания — бесконечный надзор за генерацией, которая «выглядит правильно, но ошибается». Сеньор-ремесленник становится конвейерным контролёром. Ирония: именно его глубокая экспертиза позволяет замечать эти ошибки, но использовать её по назначению ему больше не дают.
По данным Gartner (2025), CEO активно ищут способы сократить средний менеджмент с помощью ИИ. AI берёт на себя рутину, но не делает Емелю умнее. Напротив, теперь один Емеля с хорошим «вайбом» может управлять ещё большей командой, вообще не понимая, что происходит.
«Вайб» и «мэтч» против экспертизы
Это ключевой сдвиг. Емели нанимают и продвигают не тех, кто доказал свои компетенции, а тех, с кем «совпали по вайбу». Техническое собеседование заменяется вопросами про «культурный фит», а глубокая экспертиза воспринимается как угроза — слишком сложно, слишком непонятно, «ты просто не мэтчишься с командой».
Так управленческий класс замыкается в аквариуме с комфортной водой, где нет неудобных вопросов, нет архитектурных споров, нет критериев качества — только ощущение, что «мы классно вибрируем». Результат: решения принимаются не на основе данных и опыта, а на основе того, насколько идея «заходит» эмоционально.
Замкнутый круг деградации
Цепочка неумолима:
1. Емеля не разбирается в инженерии и ищет «мэтч», а не навыки.
2. Он убирает джуниоров — потому что «сеньор с ИИ дешевле и не спорит».
3. Сеньоры перестают строить и становятся контролёрами машин.
4. Новых сеньоров неоткуда взяться — джуниоров не обучают, «вайб» не растит экспертизу.
5. Качество падает, а ИИ продолжает генерировать код, ошибки в котором способен заметить только опытный глаз — и которого скоро не будет.
Индустрия, где управленцы — Емели, а инженерная культура подменена «вайбом» и верой в волшебного ИИ, через пять-десять лет окажется без тех, кто умеет строить. Это не прогноз, это данные 2025–2026 годов. Программисты тут ни при чём. Вирус — в менеджменте.
В русском фольклоре есть персонаж Емеля — парень, который лежит на печи и ждёт, что всё сделается само, по щучьему велению. Сегодня это архетип целого класса IT-менеджеров. Они не умеют управлять скоупом, не считают экономику, не понимают инженерной культуры. Но главное — они ищут не экспертизу, а «вайб» или «мэтч», веря, что правильная энергия и культурное совпадение важнее профессиональных навыков.
Этот тип массово захватил управленческие позиции, и у него появилось новое оружие — ИИ. Не против инженеров, а против самой инженерии.
ИИ как «щучье веление»
Данные не подтверждают истерику о том, что ИИ заменяет программистов. SignalFire (2026): инженеры — 55% новых наймов в тех-гигантах, исторический максимум. Спрос на квалифицированных разработчиков растёт. Дженсен Хуанг, CEO Nvidia, сказал прямо: «Маловероятно, что вас заменит ИИ. Вас обойдёт человек, который умеет его использовать».
Проблема не в технологии. Проблема в том, как её использует Емеля. Для него ИИ — та самая волшебная щука, которая должна исполнить любое желание без его участия. А раз так, зачем вообще напрягаться?
Атака на джуниоров: «печь» стала уже
Логика Емели-менеджера проста: «Сеньор с ИИ делает задачу джуниора за часы. Зачем нам джуниор?» И он прав — сегодня. Завтра станет некому стать тем самым сеньором.
Цифры жёсткие: в США количество junior-позиций рухнуло вдвое от пика 2022-го. Занятость разработчиков 22–25 лет упала на 20% (Stanford). Буткемпы, обещавшие 72% трудоустройства, скатились к 18%. Емеля не экономит — он уничтожает лестницу, по которой инженер годами карабкался от простых задач к архитектурным решениям.
Сеньор как надсмотрщик вместо мастера
Оставшихся сеньоров Емеля превращает в надзирателей ИИ-кода. Вместо созидания — бесконечный надзор за генерацией, которая «выглядит правильно, но ошибается». Сеньор-ремесленник становится конвейерным контролёром. Ирония: именно его глубокая экспертиза позволяет замечать эти ошибки, но использовать её по назначению ему больше не дают.
По данным Gartner (2025), CEO активно ищут способы сократить средний менеджмент с помощью ИИ. AI берёт на себя рутину, но не делает Емелю умнее. Напротив, теперь один Емеля с хорошим «вайбом» может управлять ещё большей командой, вообще не понимая, что происходит.
«Вайб» и «мэтч» против экспертизы
Это ключевой сдвиг. Емели нанимают и продвигают не тех, кто доказал свои компетенции, а тех, с кем «совпали по вайбу». Техническое собеседование заменяется вопросами про «культурный фит», а глубокая экспертиза воспринимается как угроза — слишком сложно, слишком непонятно, «ты просто не мэтчишься с командой».
Так управленческий класс замыкается в аквариуме с комфортной водой, где нет неудобных вопросов, нет архитектурных споров, нет критериев качества — только ощущение, что «мы классно вибрируем». Результат: решения принимаются не на основе данных и опыта, а на основе того, насколько идея «заходит» эмоционально.
Замкнутый круг деградации
Цепочка неумолима:
1. Емеля не разбирается в инженерии и ищет «мэтч», а не навыки.
2. Он убирает джуниоров — потому что «сеньор с ИИ дешевле и не спорит».
3. Сеньоры перестают строить и становятся контролёрами машин.
4. Новых сеньоров неоткуда взяться — джуниоров не обучают, «вайб» не растит экспертизу.
5. Качество падает, а ИИ продолжает генерировать код, ошибки в котором способен заметить только опытный глаз — и которого скоро не будет.
Индустрия, где управленцы — Емели, а инженерная культура подменена «вайбом» и верой в волшебного ИИ, через пять-десять лет окажется без тех, кто умеет строить. Это не прогноз, это данные 2025–2026 годов. Программисты тут ни при чём. Вирус — в менеджменте.
19 года в IT: как опыт, который не помещается в резюме, стал моим главным активом
С 2007 года я работаю в индустрии. За это время сменил несколько доменов - EdTech, FinTech, Mobility, AI, GameDev, Logistics - и накопил набор компетенций, который сложно описать одной строчкой. Продажи, юриспруденция, кибербезопасность, MBA, инженерная и продуктовая практика - навыки, которые вызывают разумное сомнение у HR при первой встрече вместе с некоторым сомнением в моей целеустремленности.
Последние 7 лет мне постоянно приходится кромсать свой опыт, так как большинство вакансий требуют либо «AI-разработчика», либо «продакта в FinTech», либо «методолога EdTech». А что делать, если в понедельник ты проектируешь агентную CRM, во вторник считаешь юнит-экономику AI-функций для образовательной платформы, в среду разбираешь legal design требований 152-ФЗ, а в четверг применяешь кейсы из Mobility, чтобы найти архитектурное решение? Ведь именно такие кейсы встречаются в стартапах и компаниях до 200 человек.
Сейчас я занимаю позицию учредителя, генерального и технического директора в компании, разрабатывающей AI-решения. Поэтому при работе с клиентом приходится управлять полным циклом: от бюджета в 638 млн рублей и безопасности до людей и продукта. Недавно как fractional-CTO я взял кейс: десять B2B-контрактов находились на грани расторжения. Чтобы сохранить шесть из них, требовалось одновременно:
- разговаривать с заказчиками на языке бизнеса (переговоры и MBA),
- оценивать обязательства и риски (юридический бэкграунд),
- перестраивать оркестрацию агентов в ERP через MCP-серверы и промпт-инжиниринг (инженерная и AI-экспертиза),
- закладывать архитектуру, которая выдержит промышленную эксплуатацию (кибербезопасность и продуктовое мышление).
Ни одна из этих компетенций по отдельности не решила бы задачу быстро, так как потребовались бы доп люди и раздувание ФОТ. Сработала именно их синергия.
Дальше — выход из кризиса поставки: мы прошли путь от нуля до регулярных релизов. Я нанял двух ключевых инженеров (управленческий навык), провёл технический аудит и встроил контроль качества там, где его раньше не существовало: версионирование промптов, аналитика поведения агентов, юнит-экономика. Попутно сократили количество контейнеров на 60% и снизили расходы на токены. Параллельно готовили продукт к запуску: платёжные шлюзы, нагрузочное тестирование, анализ безопасности — области, в которых опыт FinTech и юридической практики оказался незаменимым.
Проекты последних месяцев были очень разными: agentic CRM для строительной отрасли, RAG-система семантического поиска для лингвистов, рекомендательные сервисы для EdTech, Low-Code / No-Code агентная сеть. И в каждом случае помогала не абстрактная «технологическая эрудиция», а насмотренность, накопленная в Mobility, FinTech и образовательных продуктах. AI — сквозной инструмент, но отраслевая память превращает его из прототипа в рабочий сервис, который приносит деньги.
Именно эта гремучая смесь вывела меня в эксперта по созданию курсов по ИИ для руководителей. Потому что захотелось преподавать и потому что через меня прошёл поток реальных внедрений. Теперь я упаковываю этот опыт в образовательные траектории для топ-менеджмента — EdTech, выросший из FinTech, Mobility и AI. Такой гибрид сложно отразить в резюме, но именно за ним обращаются клиенты.
Я до сих пор не знаю, как упаковать этот путь так, чтобы он корректно считывался автоматическими фильтрами карьерных платформ. Вероятно, никак. Но рынок — особенно в турбулентное время — платит не за умение точно попасть в ключевые слова, а за способность удерживать картину целиком: от бэкенда до бюджета, от безопасности до отраслевой специфики, от инженерной детали до продажи.
Мой опыт - попытка выживания в 90х и 2000х из самоучки в технического эксперта, который в нужный момент позволяет решать задачи любой сложности за короткий промежуток времени. Если вы тоже чувствуете, что ваш профессиональный путь шире стандартных описаний, - давайте обсуждать. Возможно, проблема не в нас, а в слишком узких рамках, которые пока не учитывают мультиролевых специалистов.
С 2007 года я работаю в индустрии. За это время сменил несколько доменов - EdTech, FinTech, Mobility, AI, GameDev, Logistics - и накопил набор компетенций, который сложно описать одной строчкой. Продажи, юриспруденция, кибербезопасность, MBA, инженерная и продуктовая практика - навыки, которые вызывают разумное сомнение у HR при первой встрече вместе с некоторым сомнением в моей целеустремленности.
Последние 7 лет мне постоянно приходится кромсать свой опыт, так как большинство вакансий требуют либо «AI-разработчика», либо «продакта в FinTech», либо «методолога EdTech». А что делать, если в понедельник ты проектируешь агентную CRM, во вторник считаешь юнит-экономику AI-функций для образовательной платформы, в среду разбираешь legal design требований 152-ФЗ, а в четверг применяешь кейсы из Mobility, чтобы найти архитектурное решение? Ведь именно такие кейсы встречаются в стартапах и компаниях до 200 человек.
Сейчас я занимаю позицию учредителя, генерального и технического директора в компании, разрабатывающей AI-решения. Поэтому при работе с клиентом приходится управлять полным циклом: от бюджета в 638 млн рублей и безопасности до людей и продукта. Недавно как fractional-CTO я взял кейс: десять B2B-контрактов находились на грани расторжения. Чтобы сохранить шесть из них, требовалось одновременно:
- разговаривать с заказчиками на языке бизнеса (переговоры и MBA),
- оценивать обязательства и риски (юридический бэкграунд),
- перестраивать оркестрацию агентов в ERP через MCP-серверы и промпт-инжиниринг (инженерная и AI-экспертиза),
- закладывать архитектуру, которая выдержит промышленную эксплуатацию (кибербезопасность и продуктовое мышление).
Ни одна из этих компетенций по отдельности не решила бы задачу быстро, так как потребовались бы доп люди и раздувание ФОТ. Сработала именно их синергия.
Дальше — выход из кризиса поставки: мы прошли путь от нуля до регулярных релизов. Я нанял двух ключевых инженеров (управленческий навык), провёл технический аудит и встроил контроль качества там, где его раньше не существовало: версионирование промптов, аналитика поведения агентов, юнит-экономика. Попутно сократили количество контейнеров на 60% и снизили расходы на токены. Параллельно готовили продукт к запуску: платёжные шлюзы, нагрузочное тестирование, анализ безопасности — области, в которых опыт FinTech и юридической практики оказался незаменимым.
Проекты последних месяцев были очень разными: agentic CRM для строительной отрасли, RAG-система семантического поиска для лингвистов, рекомендательные сервисы для EdTech, Low-Code / No-Code агентная сеть. И в каждом случае помогала не абстрактная «технологическая эрудиция», а насмотренность, накопленная в Mobility, FinTech и образовательных продуктах. AI — сквозной инструмент, но отраслевая память превращает его из прототипа в рабочий сервис, который приносит деньги.
Именно эта гремучая смесь вывела меня в эксперта по созданию курсов по ИИ для руководителей. Потому что захотелось преподавать и потому что через меня прошёл поток реальных внедрений. Теперь я упаковываю этот опыт в образовательные траектории для топ-менеджмента — EdTech, выросший из FinTech, Mobility и AI. Такой гибрид сложно отразить в резюме, но именно за ним обращаются клиенты.
Я до сих пор не знаю, как упаковать этот путь так, чтобы он корректно считывался автоматическими фильтрами карьерных платформ. Вероятно, никак. Но рынок — особенно в турбулентное время — платит не за умение точно попасть в ключевые слова, а за способность удерживать картину целиком: от бэкенда до бюджета, от безопасности до отраслевой специфики, от инженерной детали до продажи.
Мой опыт - попытка выживания в 90х и 2000х из самоучки в технического эксперта, который в нужный момент позволяет решать задачи любой сложности за короткий промежуток времени. Если вы тоже чувствуете, что ваш профессиональный путь шире стандартных описаний, - давайте обсуждать. Возможно, проблема не в нас, а в слишком узких рамках, которые пока не учитывают мультиролевых специалистов.
Я забанил все вакансии Сбера. И вот почему
Недавно я вбил в поиске «Сбер» и просто скрыл каждую их позицию. Не потому что не хочу там работать, а потому что устал разговаривать с ботами — в Telegram, который, как говорят, заблокирован, но для этого, видимо, нет.
За последнее время я прошёл около 100 виртуальных интервью. Сценарий везде один: чат-бот задаёт вопросы, я отвечаю, а в конце — тишина. Бот не пишет «всё». Он просто ставит в графе «дополнительные вопросы» прочерк или «не было». Меня не спросили — за меня задокументировали молчание, которого я не давал. Приходит сухая отбивка, что диалог окончен, и ты даже не знаешь, на каком ответе отвалился.
Простая математика: 30 минут × 20 таких бесед = 600 минут, 10 часов жизни. За это время можно покрасить стену в три слоя, собрать два шкафа, написать двух агентов, сверстать 4 лендинга или сделать Telegram-бота. Вместо этого я пытался угодить алгоритму.
Но главная проблема не в потраченном времени. В живой беседе мы считываем эмоции, интуитивно кросс-валидируем, понимаем промежуточный статус, добираем недостающее. В чате с ботом этого нет. Бот вырывает слова из контекста, а ты пытаешься дать ответ, который одновременно пройдёт ATS и понравится живому человеку. Это шизофрения: ты играешь против правил, которые нигде не прописаны.
Раньше всё было иначе. С 2012 года меня пытались схантить в Сбер каждый год. У меня своё ООО, я совмещаю роли — обычно красный флаг для финтеха, но тогда это никого не останавливало. Видели живые глаза, слышали реальный опыт. Сейчас, после внедрения ИИ-воронок, я перестал доходить до живых собесов. Моя суперспособность — быстро адаптироваться к новому стеку, предметной области, нырять в хаос и выплывать — LLM не видит. Алгоритм ищет формальные паттерны, а не гибкость ума. При этом в общении с людьми (HR, карьерные консультанты) и даже с нейросетями вроде DeepSeek я стабильно получаю обратную связь: «редкий эксперт». Парадокс.
В какой-то момент я перестал играть. Забанил Сбер — и выдохнул. Потом перестал делать бесконечные тестовые задания, высасывающие методологию, и отвечать на запросы «скиньте ваш опыт». Я начал воспринимать «пульс Сбера» и подобные роботизированные отказы просто как шум, не имеющий отношения к моей квалификации. И это сработало: я стал доходить до реальных разговоров там, где удавалось пробиться к живому человеку. И там меня слышали.
Вопрос к бигтеху и его менеджерам.
Осознаёте ли вы, что ваши ИИ-фильтры отсекают не «неподходящих», а тех, кто не укладывается в шаблон? Что конвейер, созданный ради оптимизации, фабрикует выгоревших кандидатов и рождает ощущение «мёртвого рынка»? Редкие эксперты — это не идеальные резюме, это люди с нестандартным бэкграундом, чья ценность не считывается текстовыми ботами, ставящими прочерк в графе «вопросов нет».
Вы строите будущее на технологиях, но теряете способность разглядеть уникальность. Может, пора вернуть в найм немного человеческого касания? Иначе лучшие кадры просто забанят вас, и вы об этом даже не узнаете.
Делитесь в комментариях: какие выводы сделали вы при поиске работы? Что посоветовали бы HR-департаментам бигтеха?
Недавно я вбил в поиске «Сбер» и просто скрыл каждую их позицию. Не потому что не хочу там работать, а потому что устал разговаривать с ботами — в Telegram, который, как говорят, заблокирован, но для этого, видимо, нет.
За последнее время я прошёл около 100 виртуальных интервью. Сценарий везде один: чат-бот задаёт вопросы, я отвечаю, а в конце — тишина. Бот не пишет «всё». Он просто ставит в графе «дополнительные вопросы» прочерк или «не было». Меня не спросили — за меня задокументировали молчание, которого я не давал. Приходит сухая отбивка, что диалог окончен, и ты даже не знаешь, на каком ответе отвалился.
Простая математика: 30 минут × 20 таких бесед = 600 минут, 10 часов жизни. За это время можно покрасить стену в три слоя, собрать два шкафа, написать двух агентов, сверстать 4 лендинга или сделать Telegram-бота. Вместо этого я пытался угодить алгоритму.
Но главная проблема не в потраченном времени. В живой беседе мы считываем эмоции, интуитивно кросс-валидируем, понимаем промежуточный статус, добираем недостающее. В чате с ботом этого нет. Бот вырывает слова из контекста, а ты пытаешься дать ответ, который одновременно пройдёт ATS и понравится живому человеку. Это шизофрения: ты играешь против правил, которые нигде не прописаны.
Раньше всё было иначе. С 2012 года меня пытались схантить в Сбер каждый год. У меня своё ООО, я совмещаю роли — обычно красный флаг для финтеха, но тогда это никого не останавливало. Видели живые глаза, слышали реальный опыт. Сейчас, после внедрения ИИ-воронок, я перестал доходить до живых собесов. Моя суперспособность — быстро адаптироваться к новому стеку, предметной области, нырять в хаос и выплывать — LLM не видит. Алгоритм ищет формальные паттерны, а не гибкость ума. При этом в общении с людьми (HR, карьерные консультанты) и даже с нейросетями вроде DeepSeek я стабильно получаю обратную связь: «редкий эксперт». Парадокс.
В какой-то момент я перестал играть. Забанил Сбер — и выдохнул. Потом перестал делать бесконечные тестовые задания, высасывающие методологию, и отвечать на запросы «скиньте ваш опыт». Я начал воспринимать «пульс Сбера» и подобные роботизированные отказы просто как шум, не имеющий отношения к моей квалификации. И это сработало: я стал доходить до реальных разговоров там, где удавалось пробиться к живому человеку. И там меня слышали.
Вопрос к бигтеху и его менеджерам.
Осознаёте ли вы, что ваши ИИ-фильтры отсекают не «неподходящих», а тех, кто не укладывается в шаблон? Что конвейер, созданный ради оптимизации, фабрикует выгоревших кандидатов и рождает ощущение «мёртвого рынка»? Редкие эксперты — это не идеальные резюме, это люди с нестандартным бэкграундом, чья ценность не считывается текстовыми ботами, ставящими прочерк в графе «вопросов нет».
Вы строите будущее на технологиях, но теряете способность разглядеть уникальность. Может, пора вернуть в найм немного человеческого касания? Иначе лучшие кадры просто забанят вас, и вы об этом даже не узнаете.
Делитесь в комментариях: какие выводы сделали вы при поиске работы? Что посоветовали бы HR-департаментам бигтеха?
🚀 Меня зовут Максим Богуславский. Я проектирую AI-системы, которые приносят деньги, а не хайп.
19 лет в IT: от монтажника и самоучки до CTO и основателя AI-компании. За спиной — MBA, юриспруденция, инженерный бэкграунд и десятки живых проектов в FinTech, EdTech, Logistics и Mobility.
Что я умею такого, чего не умеет обычный разработчик или консультант:
1. Вижу картину целиком: от безопасности и бюджета до архитектуры и переговоров с заказчиком.
2. Строю агентные системы по принципу «скелет + мозг» — предсказуемый детерминированный каркас и управляемый LLM-слой.
3. Считаю деньги: мои клиенты сокращают расходы на API-токены и инфраструктуру на 20–60% без потери качества.
4. Работаю по модели fractional CTO: включаюсь в кризисные проекты и довожу до результата без раздувания штата.
Почему я один:
Я проповедую принцип «есть свою собачью еду». Все мои советы по оптимизации сначала проверены на себе. В моей компании нет раздутого ФОТ, офиса и «менеджеров по вайбу» — только я, мои AI-агенты и точечно привлекаемые спецы под задачу. Это даёт вам скорость и честную цену.
Здесь я пишу о:
1. архитектуре агентных систем (MCP, оркестрация, промпт-инжиниринг),
2. реальной экономике AI (цифры, кейсы, грабли),
3. управлении проектами без «базар-вокзала».
Если у вас:
• проект буксует, а AI-подрядчик не вывозит,
• счета за API пугают, а результат не радует,
• нужно спроектировать агентную систему с нуля или вытащить из кризиса текущую - напишите мне в личные сообщения. Разберём вашу ситуацию.
19 лет в IT: от монтажника и самоучки до CTO и основателя AI-компании. За спиной — MBA, юриспруденция, инженерный бэкграунд и десятки живых проектов в FinTech, EdTech, Logistics и Mobility.
Что я умею такого, чего не умеет обычный разработчик или консультант:
1. Вижу картину целиком: от безопасности и бюджета до архитектуры и переговоров с заказчиком.
2. Строю агентные системы по принципу «скелет + мозг» — предсказуемый детерминированный каркас и управляемый LLM-слой.
3. Считаю деньги: мои клиенты сокращают расходы на API-токены и инфраструктуру на 20–60% без потери качества.
4. Работаю по модели fractional CTO: включаюсь в кризисные проекты и довожу до результата без раздувания штата.
Почему я один:
Я проповедую принцип «есть свою собачью еду». Все мои советы по оптимизации сначала проверены на себе. В моей компании нет раздутого ФОТ, офиса и «менеджеров по вайбу» — только я, мои AI-агенты и точечно привлекаемые спецы под задачу. Это даёт вам скорость и честную цену.
Здесь я пишу о:
1. архитектуре агентных систем (MCP, оркестрация, промпт-инжиниринг),
2. реальной экономике AI (цифры, кейсы, грабли),
3. управлении проектами без «базар-вокзала».
Если у вас:
• проект буксует, а AI-подрядчик не вывозит,
• счета за API пугают, а результат не радует,
• нужно спроектировать агентную систему с нуля или вытащить из кризиса текущую - напишите мне в личные сообщения. Разберём вашу ситуацию.
❤🔥1👍1
Реальный AI: от теории к практике pinned «🚀 Меня зовут Максим Богуславский. Я проектирую AI-системы, которые приносят деньги, а не хайп. 19 лет в IT: от монтажника и самоучки до CTO и основателя AI-компании. За спиной — MBA, юриспруденция, инженерный бэкграунд и десятки живых проектов в FinTech,…»