Почему большинство ИИ-пилотов не доходит до продакшена и как довести свой до живой работы

Больше половины ИИ-пилотов так и не становятся частью обычной работы. Некоторые становятся: наша собственная CRM и клиентский портал работают каждый день. По нашему опыту, модель редко бывает причиной. Пилоты застревают на ТЗ, на знаниях, которые никто не записал, на требованиях, которые меняются на ходу, и на счёте, которого никто не ждал. Рассказываем, что мы видели на своих продуктах и на проектах клиентов и что помогает довести пилот до запуска.

КОРОТКО

Почему ИИ-пилоты застревают

ИИ-пилот обычно проваливается в зазоре между тем, что можно нарисовать, и тем, как на самом деле работает бизнес. Claude Code, Cursor и Codex сделали первую версию почти бесплатной. Рабочее демо, на которое три года назад у команды уходили месяцы, теперь появляется за день. Раньше попробовать было дорого, поэтому пробовали немногие идеи. Сейчас попробовать дёшево, до пилота доходит гораздо больше идей, и фильтр сместился. Вопрос уже в том, сможете ли вы продавить идею и свежая ли она для рынка, а построить её сегодня может почти кто угодно. Быстрее не стало другое: понимание бизнеса. Почему фильтр работает именно так, откуда в старой системе это странное правило, кто будет платить за токены, когда людьми этим действительно начнут пользоваться.

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

ИИ сократил путь до пилота. Путь до продакшена остался прежним.

Мы видим это с двух сторон. Мы делаем продукты с помощью ИИ для себя, в том числе нашу CRM и Disorder, концепт магазина одежды, и делаем их для клиентов: ERP-систему, ИИ-ассистентов, платформы, которые пришли к нам сырыми MVP. Часть из них запущена, одна система пока на уровне пилота, ещё одну переписывают, пока требования под ней продолжают двигаться. Каждая показывает свою причину, по которой пилоты застревают.

ЦИФРЫ

Что на самом деле говорят исследования

Встречаются цифры от половины до 95 процентов. Они измеряют разное, поэтому прежде чем цитировать, стоит понимать, что именно.

Вместе картина последовательная: больше половины ИИ-пилотов не становятся частью обычной работы. 95 процентов от MIT самая жёсткая цифра, и измеряет она более строгую вещь, чем «дошёл до продакшена»: изменил ли пилот финансовые показатели. Осторожнее с круглыми цифрами, которые гуляют по сети без ссылки на издателя. Несколько таких мы так и не смогли найти ни в одном исходном отчёте.

Опросы перечисляют знакомые причины: данные не готовы, ценность неясна, расходы растут, управление слабое. Всё так. Чего они не показывают, так это как это выглядит внутри одного проекта, и об этом вся остальная статья.

ТРИ ПИЛОТА

Три дня, три магазина, один победитель

Disorder наш собственный концепт-проект: интернет-магазин вымышленного бренда нетипичной одежды в стиле панк и рейв, доведённый до состояния, когда его можно запускать. Из любопытства мы поставили на нём эксперимент. Одна и та же задача ушла в Claude Code через разных людей, и каждый писал промпт так, как понимал работу: сильный продакт-менеджер, проджект-менеджер среднего уровня и версия на основе полного исследования и ТЗ.

Мы дали себе жёсткий лимит времени. Один рабочий день на исследование, один на ТЗ, один, чтобы привести всё в порядок. К концу третьего дня у нас было три работающих пилота магазина. Три года назад это звучало бы нереально.

Три продукта получились совершенно разными. Каждый мог сойти за пилот: страницы открываются, товары видны, корзина работает. Но только один из них работал как магазин, и это был тот, что сделан по полному ТЗ. Это ТЗ писал наш основатель, который от 15 до 20 лет был и проджект-, и продакт-менеджером и знает, почему в магазинах ряд вещей сделан именно так и где стандартная логика ломается.

Каждый промпт дал пилот. Магазин дал только один.

В исследование для этого ТЗ вошли карты пути клиента у конкурентов, разбор того, как у них работают фильтры и карточки товара, и изучение магазинов одежды той же тематики, успешных в своей нише: с высоким трафиком и доверием по Ahrefs и Semrush, быстрыми страницами и минимумом раздражённых кликов. Из того же исследования вырос и выбор технологий для итогового продукта, а сам магазин собран на нашем собственном ядре.

ТЗ

Почему модели по-прежнему нужно настоящее задание

Самая показательная разница была в фильтрах. Claude Code многое знает о том, как устроены интернет-магазины. И всё же по простому ТЗ, где логика фильтров не была расписана, он сделал то, что модель делает со свободой: каждый параметр товара стал отдельной сущностью, а каждая комбинация параметров отдельным URL. В итоге получилось огромное количество почти одинаковых страниц, что для поиска недопустимо.

У магазина с подробным ТЗ этой проблемы не было, потому что ТЗ говорило, какие комбинации фильтров заслуживают своей страницы, какие остаются на одном URL и почему. Это решение принадлежит бизнесу и SEO, и принимать его нужно до кода. О том же порядке работы мы писали в статье о SEO, встроенном в интернет-магазин.

Фильтр сначала решение бизнеса, а уже потом код.

С дизайном то же самое. По промпту и паре ссылок модель нарисует почти что угодно, и выйдет шаблон. Интерфейс становится менее шаблонным и начинает работать, когда модель получает причины: почему мы хотим такой путь покупателя, почему карточка товара устроена именно так, что покупатель пытается сделать на каждом шаге. Красиво нарисовать фильтр легко. Вопрос в том, как он поведёт себя при 40 размерах, трёх цветах не в наличии и распродаже, которая заканчивается сегодня вечером.

Можно попросить Claude Code написать ТЗ за вас. Он напишет хорошее, и всё равно что-то упустит, потому что многое из важного в интернете не лежит. Оно живёт в опыте людей, которые такие продукты строили и вели.

НЕПИСАНЫЕ ПРАВИЛА

Что знала старая система

Сильнее всего это проявляется, когда новая система заменяет существующую. Настоящему пилоту, новому продукту на новом рынке, наивность простительна: вы тестируете, многого ещё не знаете и опираетесь на общий опыт.

С заменой всё иначе. Старая система, какой бы неуклюжей она ни была, хранит годы решений. Какое-то странное правило в счетах, статус, который кажется лишним, поле, которое все заполняют по-своему. Часто этих решений нет ни в комментариях, ни в задачах, ни в документации. Разработчики, которые их принимали, ушли, а вместе с ними ушла и причина.

Модель видит код, а не историю. Если на проекте никто не знает, почему предыдущий продукт был сделан именно так, новый потеряет эти правила незаметно для всех, и бизнес узнает об этом уже в работе, обычно с клиентом на другом конце.

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

НЕ ПИЛОТ

Почему наша CRM обошлась без пилота

Наша собственная система продаж показывает обратный случай, и по ней видно, что меняет шансы. Мы сделали свою CRM для лидов, проектов и счетов примерно за месяц: один синьор-разработчик, который при необходимости ещё и тестировал, архитектор, который проверял работу, и Claude.

Ничего её не остановило, и причина простая: мы ни дня не считали её пилотом. До первой строки кода мы уже решили попрощаться с предыдущей CRM. Мы понимали, что Claude Code, Cursor и Codex умеют на нынешнем уровне, а что нет. И за плечами было пять лет работы с разными CRM и их доработки, так что ТЗ выросло из реального использования, а не из списка функций.

Есть ещё одна вещь, из-за которой задача сложнее, чем кажется. CRM давно никто не воспринимает просто как CRM. Владельцы хотят внутри закупки, немного планирования, куски ERP, так же как SEO сегодня это смесь поиска, ответов ИИ, сигналов доверия и социальных сетей. Продукты отвечают на большее число вопросов, чем раньше, значит, и ТЗ должно отвечать на большее.

ДВИЖУЩАЯСЯ ЦЕЛЬ

Когда требования меняются по ходу

Такая ясность есть не у каждого проекта. Мы строим ERP-систему для архитектурно-строительного бизнеса: закупки материалов из разных стран и брендов, логистика, курсы валют и их колебания, предоплаты, остатки, на какой склад что ложится, плюс подключение новых подрядчиков.

Она не провалилась, но и в продакшене её пока нет. Требования по ходу заметно поменялись, и теперь ТЗ переписывается, а сами задачи продолжают меняться в реальном времени.

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

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

СЧЁТ

Когда пилот удался и стоит дороже

Наши ИИ-ассистенты для сайтов готовы как каркас. Мы проверили их на своих внутренних продуктах и на клиентских проектах, в том числе на строительном портале с большим трафиком, и работают они хорошо. Сейчас они ждут запуска самих клиентских сайтов.

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

Пилот живёт на нескольких тестовых диалогах, и счёт за использование выглядит маленьким. В работе за языковую модель платят за каждый разговор, а число разговоров растёт вместе с трафиком и с тем, насколько ассистент полезен. Пилот, который оценивают только по тому, работает ли он, проверку пройдёт, а потом споткнётся о счёт.

Поэтому вопрос бюджета решается в пилоте, а не после него. Сколько разговоров вы ждёте при реальном трафике? На какие вопросы можно отвечать из фиксированной базы знаний, без полного запроса к модели? Где справится модель подешевле? Какой месячный лимит и что происходит, когда он исчерпан? Подробнее о том, как работают такие ассистенты, мы писали в статье ИИ-ассистенты на сайте не чат-боты.

МАЛАЯ НАГРУЗКА

Пилот, который работает, потому что его никто не нагружает

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

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

Так пилоты и застревают, без чьего-либо решения. Ничего не ломается, поэтому никто не решает его доделать, и пилот понемногу превращается в постоянную инфраструктуру, хотя так его никогда не строили. Лечится это датой: либо он получает оставшуюся работу и становится продуктом, либо его заменяют.

РАЗРЫВ

От демо-кода к системе, которую можно эксплуатировать

Даже победивший пилот Disorder нельзя было запускать в том виде, в котором его выдал Claude Code. Такие пилоты хорошо работают как демонстрация и экономят огромное количество времени, но для настоящего запуска всё равно нужны нормальный бэкенд, подходящий стек, безопасность и хостинг. В нашем случае пилоты были на Next.js, а версия, которую мы действительно запускали бы, собрана на нашем собственном ядре.

Вторая часть разрыва это проверка. Генерировать быстро. Убедиться, что результат верный, что фильтр не плодит тысячи страниц, что ассистент не выдумывает цены, требует людей и времени, и эта стоимость растёт с каждым изменением. Об этом мы писали в статье Стоимость ИИ в проверке, а не в генерации.

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

ЗА ПРЕДЕЛАМИ КОДА

Когда у идеи нет дороги на рынок

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

ИИ добавляет сюда свой поворот. Языковые модели склонны соглашаться. Спросите, хороша ли ваша идея, и обычно услышите, что она прекрасна. Эта склонность хорошо задокументирована: в апреле 2025 года OpenAI откатила обновление ChatGPT, потому что модель стала слишком льстивой. И люди неделями строят то, что уже существует, у компаний, которые держат рынок и опережают на годы. Модель редко скажет вам об этом, если не попросить её поискать конкурентов и поспорить с вами.

Теперь мы видим это и в собственных цифрах. Недавно мы запустили услугу MVP Review, и за первые полтора месяца пришло четыре заявки. Все четыре оказались одной и той же историей. Основатели считали, что у них свежее ноу-хау, которое стоит патентовать, и в каждом случае очень похожие продукты уже были запущены и неплохо работали, у кого полгода, у кого полтора года. Часть из них была развита сильнее, чем MVP, который лежал перед нами. Без настоящего отличия найти на это инвестиции было нереально, а времени основатели уже потратили много.

Несколько человек присылали нам скриншоты своих переписок с ИИ: модель «провела анализ рынка», поискала, ничего похожего не нашла и похвалила идею. Качество такого анализа очень разное. Быстрый ответ лёгкой модели и тщательный прогон в режиме глубокого рассуждения или исследования могут дать на один и тот же вопрос противоположные выводы. Под каждым ответом в чате написано, что модель может ошибаться и ответ нужно проверить. В азарте новой идеи, когда вайб-кодинг делает первую версию почти бесплатной, эту строку пропускают. Четыре из четырёх это маленькая выборка за шесть недель, поэтому считайте её сигналом, а не статистикой. Сигнал громкий.

Есть и хорошие идеи в настоящих нишах, которые застревают по причинам, не связанным с продуктом. У основателя нет выхода на инвесторов или на людей, которые могли бы его поддержать. Или технологии нужен патент, а патентовать в США небыстро и недёшево: по оценкам практикующих юристов, типичный патент на изобретение вместе с работой патентного поверенного обходится примерно от 15 000 до 25 000 долларов до выдачи, а к заявкам на софт относятся строже.

Пилот доказывает, что идею можно построить. Но не то, что она выживет.

Цифры за этим отрезвляют, даже если ни одно исследование не измеряет напрямую «идеи, которые заняли нишу». По данным Бюро статистики труда США, из всех предприятий, открытых в 2013 году, через пять лет работала примерно половина, через десять примерно треть. Среди стартапов, которые уже подняли посевной раунд в последние годы, по данным Carta, меньше трети за два года дошли до раунда A. Это компании, которые уже убедили кого-то вложить деньги. Доля сырых идей, которые становятся устойчивым бизнесом, ещё меньше, и это честный контекст для любой статистики о пилотах.

ЧЕК-ЛИСТ

Как довести пилот до продакшена

О чём мы договорились бы перед стартом любого ИИ-пилота, своего или клиентского:

• Решение о старом способе. Если старую систему или процесс не собираются выключать, когда пилот удастся, пилоту некуда идти.
• Мера успеха и дата решения. Не «посмотрим, как пойдёт», а что должно быть правдой к какой дате, чтобы запустить его или закрыть.
• ТЗ от человека, который вёл такой продукт, с причинами логики, а не только экранами. Для магазина это прежде всего фильтры, карточки и правила URL.
• Неписаные правила текущей системы, собранные у людей, которые работают в ней каждый день.
• Один человек, принимающий решения со стороны бизнеса, и журнал того, почему меняются требования.
• Бюджет на использование при реальном трафике, с лимитами и планом, что отвечается без полного запроса к модели.
• Реальные данные с самого начала, а не вычищенная выборка, в которой не видно трудных случаев.
• Путь от демо-кода к поддерживаемой системе: репозиторий, тестовая копия, бэкенд, безопасность, мониторинг и ответственный за каждое.
• Нагрузочный тест или мягкий запуск, прежде чем пилот по умолчанию превратится в инфраструктуру.
• Бюджет на жизнь после запуска: хостинг, поддержка, реклама и контент, посчитанные до разработки, а не после.
• Честная проверка идеи: кто уже это делает, как они туда пришли и кто профинансирует следующий этап. Просите модель спорить с вами, а не соглашаться.

Если нескольких пунктов нет, пилот всё равно может быть правильным шагом, потому что сегодня это самый дешёвый способ увидеть идею. Просто называйте его тем, чем он является, демонстрацией, и путь до продакшена закладывайте в бюджет отдельно.

FAQ

Источники

• iTnews: Half of AI pilot projects make it to production, Gartner
• CIO Dive: AI project failure rates are on the rise, S&P Global
• CIO.com: 88% of AI pilots fail to reach production, but that's not all on IT
• Gartner: Over 40% of agentic AI projects will be canceled by end of 2027
• Gartner: Lack of AI-ready data puts AI projects at risk
• U.S. Bureau of Labor Statistics: 34.7 percent of business establishments born in 2013 were still operating in 2023
• Carta: Most seed startups never reach Series A
• BitLaw: What does a patent application cost?
• TechCrunch: OpenAI explains why ChatGPT became too sycophantic