AI-first, которого нет

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

«У нас нет данных, это не продукт с рынком».

Но постойте. Продукт есть. Он продается, используется клиентами. Да, это десктоп-версия, не SaaS, но данные с десктопа переносимы. В интернете есть оценки по аналогам — конкуренты, их метрики, отзывы, рыночные бенчмарки. Казалось бы: зайди в DeepSeek, проведи быстрый анализ, получи RICE хотя бы предварительный. Модель может проверить наличие фактов, подсветить, где оценка завышена, а где данных просто нет. Это не идеальная приоритизация, но это движение. Вместо ступора — черновик, который можно оспорить и уточнить.

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

Это не частный случай. Исследование 2026 года, охватившее 287 продуктовых профессионалов, показало: только 7,3% респондентов часто используют ИИ и ML для приоритизации бэклога, хотя 63,4% открыты к этому. RICE требует реальных данных о reach и impact, MoSCoW — честного признания, что «must have» не равно «все хочется». Без данных любой фреймворк превращается в ритуал. Поэтому и возникает ступор: цифр нет, а без них приоритизация — политика, а не управление.

Более того, старые фреймворки в 2026 году сломались. Один из бенчмарков показал: только 6,4% фич дают 80% кликов. 94% всего, что команды шипят, игнорируется. Проблема не в RICE как методе — проблема в его входах. Vibe coding сжал цикл разработки с кварталов до дней, и та же ошибка приоритизации теперь повторяется в десять раз быстрее. AI-проекты проваливаются в 80,3% случаев, 95% GenAI-пилотов не доходят до продакшена. Не потому что модели плохи, а потому что команды строят не то.

Дальше — знакомая история. «Нам обещали за день. Авторизацию делали быстро». Окей, делали. Потому что был готовый дизайн, требования обсуждены. Но я ни разу не видел, чтобы что-то быстро сделали в продуктовой команде, где больше одного человека и больше одного мнения. По данным BairesDev, 42% разработчиков говорят, что ИИ пишет как минимум половину их кода (год назад — 12%). ИИ экономит им 13 часов в неделю на кодинге. Но 67% стали больше времени тратить на ревью ИИ-кода, а 52% — на отладку проблем, которые ИИ привнес. «Ни один из этих сэкономленных часов не вернулся», — говорит CEO BairesDev Даррен Шимкус. В командах, где нужно согласовывать мнения, скорость упирается не в код, а в координацию.

Компании называют себя AI-first, но ИИ у них не first. Люди продолжают встречаться, заметки со встреч не ведутся, цифры не фиксируются, правила не описываются. Потом возникает вопрос: «Почему так долго?» Действительно, непонятно. По данным Atlassian, 89% руководителей говорят, что ИИ ускорил работу, но только 6% уверены, что могут указать на конкретную окупаемость инвестиций в ИИ на уровне всей организации. NBER: около 70% компаний заявляют о внедрении ИИ, но почти 90% не фиксируют измеримого влияния на продуктивность или занятость. Sinch: 62% компаний уже используют ИИ-агентов в производстве, 88% ожидают этого к концу 2026 года. Techreviewer.co: 89% компаний используют ИИ для написания кода, 97% сообщают о росте продуктивности, но 90% сталкиваются как минимум с одним негативным последствием — 52,8% жалуются на галлюцинации, 44,1% — на рост нагрузки на код-ревью, 33,1% — на уязвимости в сгенерированном коде. Доля компаний, сообщающих о росте продуктивности более чем на 50%, выросла с 7,5% в 2024 году до 30,7% в 2026-м. Но рабочий документ Duke University и Федеральных резервных банков Ричмонда и Атланты, основанный на опросе почти 750 руководителей, показал: заявленный рост продуктивности от ИИ в 2025 году — 1,8%, а расчеты на основе реальной выручки и занятости дают куда более скромные цифры. «Это еще не бьет по верхней строке в полную силу, — говорит соавтор исследования Джон Грэм. — Здесь определенно есть задержка».

Andus Labs в сентябре 2026 года опубликовала Ground Truth Index — рейтинг 25 главных барьеров, мешающих корпоративному ИИ приносить отдачу. Почти половина из них связана с решениями руководства, а не с технологиями. На первом месте — «Empty Chairs»: компании дают ИИ право принимать решения, но не назначают ответственного, который может эти решения проверить или отменить. На втором — «Learning While Drowning»: сотрудников заставляют учить ИИ, не освобождая для этого время. «Модели работают. Ломается все вокруг них», — говорит CEO Andus Labs Крис Перри.

Исследование Insead и Harvard, охватившее 515 быстрорастущих стартапов, добавляет: AI-native компании примерно на 25% меньше по размеру, но эффективнее. Разница не в количестве инструментов, а в культуре: данные, метрики и обратная связь встроены в саму работу.

Проблема не в ИИ, а в том, как его используют. ИИ ускоряет создание артефактов старой проектной модели — бизнес-кейсов, роадмапов, PRD, кода. Сильные продуктовые команды применяют его иначе: для ускорения discovery, проверки гипотез и поиска решений, которые действительно работают. Разница между AI-first на словах и AI-first на деле — это разница между «мы купили инструменты» и «мы изменили способ принятия решений». Первое можно сделать за день. Второе требует времени, данных и готовности признать: старые фреймворки без новых данных остаются старыми фреймворками.