Чому більшість ШІ-пілотів не доходить до продакшену і як довести свій до живої роботи

Понад половина ШІ-пілотів так і не стає частиною звичайної роботи. Деякі стають: наша власна 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