Дата публікації:
Публікація:
Кілька місяців тому до нас прийшов клієнт із доволі типовим на перший погляд запитом: перевести застосунок на production-ready інфраструктуру, розібратися з комплаєнсом і підготувати go-live план. Ідея сильна, ринок реальний, перші користувачі вже підтвердили попит.
Але був нюанс, який змінив для мене весь підхід до розмови. Продукт написала одна людина — без техфаундера, без CTO, без інженерної команди. Весь застосунок з’явився за кілька тижнів у no-code/AI-платформі. Фаундер не програміст. Фаундер взагалі не з теху.
Коли до нас на консультацію приходить технічний фаундер чи CTO, ми говоримо однією мовою: «інфраструктура», «BAA», «managed Postgres», «encryption at rest» — це терміни, якими оперують обидві сторони розмови. А коли навпроти тебе фаундер, який щиро не розуміє, чому те, що вже добре виглядає на демо для перших користувачів, це не те саме, що система, готова обробляти платіжні чи медичні дані реальних людей, весь процес консультування доводиться вибудовувати інакше.
І таких клієнтів буде більше. Значно більше.
Перш ніж говорити про те, як консультувати таких клієнтів, варто чесно подивитись, наскільки серйозна сама проблема, бо цифри тут вражають навіть тих, хто вже давно в індустрії.
За оцінками кількох незалежних розборів індустрії, з приблизно 10 000 стартапів, що до кінця 2025 року вивели в продакшн застосунки, побудовані переважно AI-кодогенерацією, до середини 2026-го більш ніж 8 000 потребували часткової чи повної переробки, тобто рескью-інженерії, яка вже стає окремою категорією послуг, із вартістю $50–500 тис. за проєкт (Vexlint, «Why Vibe Coded Startups Are Failing»; методологія й деталі — Getcreatr, «Vibe Coding Technical Debt»).
Причина — не в тому, що AI погано пише код сам собою. Звіт Veracode за результатами тестування понад сотні мовних моделей на 80 задачах з кодингу показав: 45% згенерованого коду не проходить базові тести з переліку OWASP Top-10 — не екзотичні вразливості, а базові речі на кшталт неперевірених вхідних даних чи відсутньої авторизації (огляд методології та результатів — Axis Intelligence, Keyhole Software). Дослідження CodeRabbit і CSA Labs, що проаналізувало майже 470 реальних pull request’ів, зафіксувало приблизно у 2,7 раза вищу частоту вразливостей у AI-згенерованому коді порівняно з еквівалентним кодом, написаним людиною (та сама Axis Intelligence). А незалежне сканування безпекової компанії Symbiotic Security, що перевірило 1 072 реальні vibe-coded застосунки, знайшло хоч одну вразливість у 98% з них — переважно засвічені Supabase-ключі доступу в клієнтському коді та неправильно налаштований CORS (повний звіт Symbiotic Security).
Є ще один патерн, який добре описав інженер Google Chrome DevTools Едді Османі ще наприкінці 2024-го, і який з тих пір лише підтверджується: нетехнічна людина з AI-інструментом швидко доходить приблизно до 70% робочого рішення, а останні 30% перетворюються на цикл, де кожен фікс породжує новий баг (Coding With Vibe). В індустрії це вже називають «стіною третього місяця», моментом, коли кілька фіч, побудованих ізольовано одна від одної, структурно розходяться між собою.
Це і є той самий це розрив між відчуттям швидкості й реальною швидкістю. Рандомізоване контрольоване дослідження METR серед 16 досвідчених розробників, які працювали з великими кодовими базами (у середньому понад 1 млн рядків коду, 5+ років досвіду в проєкті) за допомогою AI-асистентів, показало: фактично вони виконували задачі на 19% повільніше, а після завершення дослідження оцінювали, що AI пришвидшив їх на 20% (METR, «Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity»). Розрив у майже 40 процентних пунктів між відчуттям і реальністю. Саме звідси беруться нереалістичні дедлайни, які потім падають на стіл консультанта.
У макромасштабі це виглядає так: за прогнозом Forrester, до кінця 2026-го понад 75% технологічних лідерів матимуть помірний або серйозний технічний борг, проти трохи більш ніж 50% у 2025-му, і аналітики прямо називають прискорену AI-розробку одним із драйверів цього стрибка (офіційний реліз Forrester).
McKinsey ще у своєму дослідженні «Tech debt: Reclaiming tech equity» оцінювала, що технічний борг займає до 40% технологічних активів середньої організації, а компанії витрачають додаткові 10–20% бюджету понад вартість будь-якого проєкту саме на обслуговування цього боргу (McKinsey, «Breaking technical debt’s vicious cycle»).
Ще одна ілюстрація цього самого сюжету — гілка на DOU під назвою «Ілюзія економії: чому заміна розробників на AI — це шлях до технічного дефолту», яка зібрала понад 230 коментарів: досвідчені мейнтейнери великих open-source проєктів там прямо застерігають, що стратегія «залишити тільки сеньйорів з AI і скоротити решту команди» — самообман, бо команда виходить дорожчою, повільнішою (хоч і впевненою у зворотному) і генерує вдвічі більше легасі-коду (обговорення на DOU). Це майже дослівно повторює висновок METR, тільки мовою практиків.
Ще один зсув, важливий для розуміння того, звідки береться цей борг сьогодні: у 2025 році AI-інструменти здебільшого допомагали окремому розробнику — автодоповнення, підказки, швидкі фікси в межах одного рядка чи функції. У 2026-му агенти дедалі частіше самі планують, генерують, тестують і готують релізи з мінімальним втручанням людини, працюючи по всьому циклу розробки, а не над окремим фрагментом коду. За прогнозом Gartner, 40% enterprise-застосунків матимуть вбудованих task-specific AI-агентів до кінця 2026 року, проти менш ніж 5% на початку 2025-го, а за даними Gartner Hype Cycle 2026, понад 60% організацій планують розгорнути таких агентів протягом найближчих двох років (офіційний реліз Gartner).
Приріст продуктивності від цього реальний, але далеко не той, що обіцяла маркетингова риторика «10x». Дослідницька компанія DX, яка відстежувала понад 400 компаній протягом 15 місяців, прямо так і сформулювала висновок у назві свого звіту: «AI productivity gains are 10%, not 10x» (DX Research). Систематичний огляд 116 досліджень також фіксує приріст у діапазоні 10–30% по випуску релізів, а не кратне прискорення (Reinvently).
Показово, куди змістилося вузьке місце. Опитування Sonar серед понад 1 100 професійних розробників у 2026-му зафіксувало дивний розрив: 96% з них не повністю довіряють AI-згенерованому коду, але лише 48% завжди перевіряють AI-асистований код перед комітом (Sonar, «State of Code Developer Survey 2026», розбір результатів — Hyrax). Тобто недовіра є практично у всіх, а дисципліна перевірки тільки у половини.
Найскладніша частина розробки в 2026-му не генерація коду, а governance: розуміти, що саме згенерував AI, чому саме так, і чи безпечно це випускати в продакшн і саме цей шар роботи найлегше пропустити, коли фаундер нетехнічний.
Для нетехнічного фаундера це майже неможливо оцінити самостійно просто тому, що governance є саме тим шаром роботи, якого фаундер ніколи не бачив і не вмів оцінювати навіть тоді, коли код писали люди.
Легко подумати, що робота консультанта з нетехнічним клієнтом — це та сама робота з CTO, тільки з меншою кількістю жаргону. Це не так. Різниця не в словнику, а в структурі самої розмови.
По-перше, зникає спільна база для перевірки.
Коли ми говоримо з інженером клієнта, він може перевірити наше рішення, задати уточнююче питання, посперечатися про trade-off, розпізнати, коли ми або він самі щось спрощуємо на шкоду точності. З нетехнічним фаундером цієї страховки немає. Він або довіряє нам повністю, або йому нема на що спертися, щоб довіру перевірити. Це підвищує планку відповідальності на нашій стороні і водночас робить кожну нашу рекомендацію потенційно непрозорою для клієнта.
По-друге, вимоги формулюються не в технічних, а в бізнесових координатах, і ці координати рухаються.
У нашому кейсі стратегія виходу на ринок змінилася просто в процесі обговорення: спершу клієнт планував продавати продукт медичним установам (B2B), а це відразу тягне за собою повний HIPAA-комплаєнс, бо медичні заклади в США — це covered entities, які працюють із персональними медичними даними. Потім фокус змістився на прямий продаж кінцевим споживачам (B2C) і юридичний контекст навколо тих самих технічних рішень змінився повністю. Технічний партнер зазвичай одразу бачить зв’язок «модель продажів → регуляторні вимоги». Нетехнічний фаундер — ні, і це нормально: це не його зона експертизи.
По-третє, продукт, зібраний в AI-платформі, створює ілюзію завершеності: він працює, виглядає готовим, має інтерфейс і фаундеру щиро незрозуміло, чому «доробити трохи» коштує стільки ж, скільки коштувала вся перша версія. Статистика вище якраз пояснює, чому: перші 70% рішення й останні 30% — це принципово різна за складністю робота, хоча зовні цієї різниці майже не видно.
Ми не перші, хто зіткнувся з цією проблемою, і індустрія вже почала формувати відповідь на неї, щоправда, поки що фрагментовано.
Найпомітніший напрямок — fractional CTO послуги. По суті, це прошарок між бізнесом і інженерією. Людина чи невелика команда, яка бере на себе переклад технічних рішень у бізнес-логіку: ризики, вартість, терміни, а не архітектурні деталі. Фаундеру не треба розуміти, як влаштована технологія, йому треба розуміти ризики, які він на себе бере, і вплив кожного рішення на бізнес.
Другий напрямок з’явився буквально протягом останнього року — окремі агенції почали пропонувати «vibe coding cleanup» чи «rescue engineering» як самостійну послугу: аудит згенерованого коду, оцінка архітектури, безпеки та готовності до CI/CD, після чого — план стабілізації. При оціночному масштабі ринку в $400 млн – $4 млрд це перестало бути нішевою послугою й перетворюється на окрему галузь. Показово, що такі агенції майже завжди пропонують безкоштовну первинну оцінку, саме тому, що на цьому етапі фаундер ще не може сформулювати технічний скоуп сам, і продавати платний аудит «наосліп» нечесно стосовно клієнта.
Спираючись на власний досвід (і, чесно кажучи, на кілька набитих гуль), ми поступово формуємо для себе кілька принципів роботи саме з фаундерами без технічного бекграунду.
З технічним клієнтом можна імпровізувати, обидві сторони орієнтуються в темі й вирулюють розмову туди, куди треба. З нетехнічним фаундером імпровізація небезпечна: легко пропустити критичне питання просто тому, що воно здається очевидним інженеру й ніколи не спало на думку людині без інженерного бекграунду. Дуже допомагають наперед підготовлений список дискавері-питань, згрупованім по темам: compliance posture, обсяг і тип даних, поточне середовище, цільова архітектура, доступи й аудит, план міграції, інтеграції, пост-launch операції, бюджет і терміни, критерії успіху.
Є велика різниця між питанням «AWS чи Supabase» і «швидший запуск без повного комплаєнсу зараз, або довший запуск з повною готовністю до B2B-угод з медичними закладами пізніше». Перше питання фаундер не може оцінити змістовно. Друге може, бо це вже питання його бізнес-стратегії, а не архітектури.
Нетехнічна людина забуває нюанси технічної розмови значно швидше за інженера. Тому ми принципово фіксуємо кожне архітектурне рішення в документі чи діаграмі, до якої фаундер може повернутися за тиждень і все ще зрозуміти логіку.
Якщо вимоги можуть змінитися посеред проєкту (а в роботі з ранніми стартапами вони змінюються майже завжди), треба закладати це в процес, а не сприймати як зрив плану. У нашому кейсі саме зміна моделі продажів (B2B → B2C) стала підставою для двофазної стратегії комплаєнсу: запуск без повного HIPAA зараз і активація, коли компанія реально почне підписувати угоди з медичними установами. Це рішення народилося не тому, що ми заздалегідь усе спланували, а тому, що процес дозволяв перепланувати без відчуття, що «все зламалося».
Вайб-кодинг не скасував потребу в інженерній дисципліні, він підняв ціну за її відсутність, бо тепер значно простіше згенерувати набагато більше коду, набагато швидше, до того як хтось помітить, що дисципліни бракує. Для нас це означає одну практичну річ: клієнт без технічного співзасновника — не менш серйозний клієнт, а клієнт, якому потрібен інший протокол роботи, структурований дискавері, переклад рішень у бізнес-наслідки й письмові артефакти замість усних домовленостей.
Ми свідомо тренуємо цю навичку в команді, а не виносимо її в окрему посаду — поки що. Кількість «one-person AI-built» стартапів росте швидше, ніж індустрія встигає домовитись, як із ними правильно працювати, тож підозрюю, що це питання постане гостріше для всіх нас уже за рік-два. Якщо у вашій команді вже склався інший підхід, буду радий обмінятися досвідом.
Федір Компанієць — CEO & Co-Founder, Gart Solutions. Cloud Solutions Architect & Digital Transformation Consultant.
