Компании раздают своим инженерам ИИ-агентов. Cursor, Copilot, корпоративный ChatGPT, доступ к Claude через API. Сначала это работает: код пишется быстрее, релизы чаще, задачи закрываются за дни, а не недели. Скорость поставки растёт. Все довольны.

Через полгода руководство собирается на квартальную ретроспективу, анализируют конверсию, удержание пользователя: не выросло. Выручка идёт по плану, который выверяли ещё до внедрения ИИ. Технический директор разводит руками: «Ребята, мы выкатили в два раза больше задач». Гендир смотрит на цифры и не понимает: а где та самая ожидаемая польза от ИИ?

Инструменты есть. Инженеры быстры, как никогда. Код пишется мгновенно. А бизнес-результата нет.

Почему так?

Узкое место — не там, где мы привыкли его искать. Не в скорости написания кода. Оно сместилось.

И сместилось туда, куда легко не посмотреть. Потому что эта зона не выглядит как «техническая проблема» — а значит, в ИИ-стратегии компании она не упоминается. Она выглядит как «обычная работа продакт-менеджеров», и кажется, что её всё это ИИ-движение обходит стороной.

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

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

Где находится новое узкое место продуктового менеджмента

Раньше скорость продукта упиралась в разработчиков. Перед ними был огромный бэклог. А задача проходила множство этапов: написать код, прогнать тесты, пройти ревью, выкатить — это занимало недели. Планирование спринта, грумминг, ежедневные митапы, демо, ретро — ритуалы скрама и канбана строилась вокруг одного факта: инженерное звено необходимо поддерживать и систематизировать.

Узкое место всегда было «справа». Любой продакт-менеджер старше тридцати помнит наизусть фразы из чата с разрабом: «Это в бэклоге», «Возьмём в следующий спринт», «У команды нет времени до следующего квартала».

С ИИ-агентами это перестало быть правдой.

Прототип, который раньше собирала команда из 5 инженеров за 2–3 спринта, теперь делается одним инженером с Cursor за день. Иногда — продактом самостоятельно за вечер. Я сам видел, как студенты на наших интенсивах за двухчасовой урок собирают рабочую версию того, что в их компаниях стояло в плане на несколько дней.

А что осталось не ускоренным?

Решение «что именно строить». Кому это нужно. Какую проблему мы решаем. Какой рынок. Какая фича первой даст результат, а какая — провалится. Эту работу делает продакт. И эта работа не ускорилась — потому что она не про скорость набора кода. Она про скорость качественных решений.

В моих командах я видел одну и ту же картину: разработчики с агентами сидят и ждут, пока продакт принесёт следующую гипотезу. Раньше было наоборот — продакт ждал инженеров, торговался за приоритеты в бэклоге. Теперь продакт просто не успевает.

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

Когда в системе исчезает самое узкое звено, узким автоматически становится следующее. Это базовая теория ограничений, которой почему-то не учат на продуктовых курсах. Зато её хорошо знают operations-менеджеры на заводах: убрав одно бутылочное горлышко, ты не разрушаешь систему — ты переносишь ограничение на следующий участок производственной линии.

С продуктовой работой то же самое. ИИ убрал узкое место в звене разработки. Следующее звено — продакт.

Почему компании этого не видят

Стартуем с парадокса в цифрах.

McKinsey в свежем отчёте «State of AI 2025» показывает: 88% организаций используют ИИ хотя бы в одной бизнес-функции. По данным «Якова и Партнёров» совместно с Яндексом — 71% российских компаний интегрировали GenAI хотя бы куда-то. Год назад это было 78% и 54% соответственно. Темпы роста — десятки процентов за 12 месяцев.

Внедрение есть. Все его прошли, а результата — нет.

McKinsey считает «AI high performers» — компании, у которых ИИ дал больше 5% прироста к EBIT. Их 5,5%. Из 88% внедривших — только каждый шестнадцатый получает реальный финансовый эффект. Остальные 82,5% потратили деньги, ресурсы, время — и не получили того, ради чего затевалась вся эта история.

Куда же деваются эти десятки процентов?

Ответ — там же, где сидит наше узкое место. Компании ускоряют разработчиков, потому что инженерное ускорение легко измерить и легко продать как «ИИ-проект»: раздали Copilot, замерили скорость поставки, написали отчёт «задачи закрываются на 30% быстрее». Готово, ИИ работает, открываем шампанское.

А решение «что строить» — не ускоряют. Оно осталось в 2019-м: те же спринты, те же ТЗ, та же интуиция продакта на основе двух пользовательских интервью. И весь выигрыш в скорости кода превращается в более быстрое строительство неправильных вещей.

Тот же отчёт McKinsey подтверждает диагноз: 73% компаний не используют ИИ-агентов в продуктовой разработке. Не там, где принимаются решения «что строить». Только в бэкофисе, маркетинге, поддержке — там, где автоматизация рутинных процессов даёт быстрые KPI и понятную отчётность.

Тот же отчёт McKinsey подтверждает диагноз: 73% компаний не используют ИИ-агентов в продуктовой разработке. Не там, где принимаются решения «что строить». Только в бэкофисе, маркетинге, поддержке — там, где автоматизация рутинных процессов даёт быстрые KPI и понятную отчётность.

В России картина такая же. По газете «Ведомости» и тем же «Яков и Партнёры», только 26% компаний с ИИ-бюджетом имеют стратегию. Остальные 74% внедряют ИИ инструментально — точечно, без системы. Покупают подписки, обучают сотрудников, и считают, что задача решена.

Получается смешная картина. Разработчики пишут код в два раза быстрее, который продакт выбрал «по-старому» — на основе той же интуиции, тех же грумингов, тех же ТЗ-документов из 2019-го. Скорость есть, направление — старое.

А потом руководство удивляется, почему квартальная ретроспектива не показывает прироста.

Что делает прокачанный продакт с ИИ

Когда продакт владеет ИИ-агентами на высшем уровне — а именно этому мы учим на интенсивах startend.ru — его работа меняется в трёх местах.

Эндрю Ын: 1 продакт на 0,5 разработчика

В том же выступлении на Y Combinator Ын упомянул интересную вещь. В одной из его команд соотношение продактов к разработчикам — 1 к 0,5. То есть продактов вдвое больше.

В классическом соотношении это 1 к 4. Разница в восемь раз.

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

Это значит другое. Продуктовая работа стала тяжелее. На одного инженера, которого ускорил ИИ, приходится больше требований к качеству и скорости решений «что делать». Раньше один продакт работал с четырьмя инженерами, потому что узким местом были они — продакт успевал думать за всех. Теперь узкое место сместилось, и один продакт уже не успевает поднимать гипотезы для двух ускоренных инженеров.

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

Пример процесса сбора прототипа для Продакта с ИИ-агентами

Что теряют команды без прокачанных продактов

Возьмём типичную картину в крупной компании. У разработчиков уже есть Copilot, кто-то освоил Claude Code — выкатывают фичи быстрее. скорость растёт. Продакты заметили ускорение и сделали логичный, на первый взгляд, шаг: запихнули в спринт больше задач. И всё.

Цикл от идеи до проверки гипотезы остался прежним — те же 2–4 недели:

• Неделя — собрать требования, написать ТЗ, согласовать с архитектурой.
• Неделя — планирование спринта, разработка, ревью, баги.
• Неделя — тестирование, регресс, регресс-тестирование, релиз.
• Неделя — ждать, пока пользователи попробуют, пока соберётся аналитика, пока команда успеет посмотреть метрики.

Где здесь могло бы быть ускорение?

Только если продакт сам соберёт прототип на втором-третьем дне после идеи и протащит через пять реальных пользователей за неделю. Тогда «правильность гипотезы» становится видна до того, как инженеры начали кодить — и они кодят уже верное. Не теоретическое ТЗ, а задание, в котором уже зашиты правки от первого живого тестирования.

Без прокачанного продакта ИИ-агенты сидят «в ожидании ТЗ». Разработчик с Claude Code мог бы и сам за полдня собрать прототип — но ему не на что опереться: ТЗ ещё пишется, требования обсуждаются, JIRA-задача в статусе «Новая». Самый ценный ресурс компании — внимание инженера с агентом — простаивает.

На наших интенсивах startend.ru мы видим эту трансформацию буквально за 3-4 недели. Продакт, который до интенсива писал тикеты в Jira и ждал ответа от тимлида, через 8 уроков приходит на standup с собранным прототипом — и команда меняет режим работы за один спринт. Не потому что «продакт забрал работу у инженеров». Потому что убрал из процесса самое дорогое — ожидание.

Где границы между продактом и инженером после ИИ

В такой парадигме работа разработчиков становится тоньше, но не меньше. И стоить хороший разработчик начинает дороже.

За ним остаются три зоны, которые ИИ-агент в одиночку не закрывает.

Архитектура. Прототип, собранный за день, отлично работает на 100 пользователях. На миллионе — рассыпается. Базы данных не выдерживают, кэширование настроено криво, очереди забиваются. Спрос на инженеров, которые умеют переводить «работающий прототип» в «работающий прод», растёт быстрее, чем падает спрос на тех, кто пишет шаблонный CRUD. Это не уход профессии — это её фокусировка.

Безопасность и комплаенс. Продакт-прототип ничего не знает PII, шифрование данных, аудит. Это не интуитивные решения — это специализация. ИИ-агент пишет код, который проходит тесты — не код, который проходит ревью по безопасности. Между этими двумя вещами часто пропасть недели работы разработчика.

Прод-нагрузка. Когда сервис падает в три ночи в субботу, то реагирует разработчик, а не продакт, и не ИИ-агент. Ответственность всегда на человеке.

Что уходит от разработчика — и слава богу — это рутина: «написать вот эту простую страницу с формой», «сверстать модалку», «добавить эндпоинт по спеке». Это раньше занимало половину спринта. Теперь — час продакта в Claude Code.

Команда от этого выигрывает дважды. Инженер занимается тем, что приносит уникальную ценность — архитектурой, безопасностью, прод-нагрузкой. Продакт перестаёт ждать и начинает делать. Цикл сжимается. Все довольны, кроме менеджеров среднего звена, у которых раньше было «надо переслать ТЗ команде разработки».

Доля «отбрасываемых» гипотез до разработки. Здоровая команда отбрасывает 50–70% идей, которые казались хорошими, после прототипа. Если у вас отбрасывается 0% — это плохой знак. Это значит, что ИИ ускорил вашу команду в строительстве неправильных вещей.

Эти четыре метрики дают честный ответ: ускорилось ли решение, или вы просто строите быстрее.

Заключение

Прокачивать инженеров — нужно. Они напрямую ускоряются от ИИ-инструментов, и это хорошо для команды, для бизнеса, для самих инженеров. Никто не предлагает прекратить раздавать Copilot.

Но если прокачивать только их — мы получаем ту самую ситуацию из 2025-го года, которую видим в отчётах McKinsey: компании внедряют ИИ, ускоряют код, и не получают бизнес-результата. Цифры не врут: 5,5% high performers против 88% внедривших.

Ускорение даёт результат только тогда, когда скорость продуктовых решений догоняет скорость инженерии.

А это — задача продакта. Не «писать ТЗ быстрее», а собирать прототипы и валидировать гипотезы за день вместо недели. Не «приоритизировать бэклог», а приходить к инженерам с работающей моделью. Не «считать velocity», а измерять скорость отбрасывания неправильных решений.

Вот в этом и состоит ключ к внедрению ИИ.

Не в Cursor для разработчиков. И не в новом ChatGPT, развёрнутом в корпоративном облаке для всех сотрудников.

А в том, кто определяет, что строить. А это — продакт.