Нещодавно до компанії Gart Solutions звернувся клієнт із начебто звичним завданням: перевести застосунок на production-ready інфраструктуру, розібратися з комплаєнсом і скласти план запуску. Продукт мав сильну ідею, реальний ринок і перших користувачів, які вже підтвердили попит.

Проте виявилася деталь, яка змінила весь підхід до розмови. Застосунок за кілька тижнів створила одна людина без техфаундера, 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»).

Причина не в тому, що штучний інтелект пише поганий код сам собою. Звіт 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).

Є ще один патерн, який ще наприкінці 2024-го описав інженер Google Chrome DevTools Едді Османі і який відтоді лише підтверджується: нетехнічна людина з 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 і скоротити решту команди» — самообман: команда виходить дорожчою, повільнішою (хоча й переконаною у зворотному) і генерує вдвічі більше легасі-коду. Цей висновок майже дослівно повторює результати METR, тільки мовою практиків.

AI вже не автодоповнення, і це змінює природу боргу

Важливий момент для розуміння того, звідки береться сьогоднішній технічний борг: у 2025 році AI-інструменти переважно допомагали окремому розробнику — автодоповнення, підказки, швидкі правки в межах рядка чи функції. У 2026-му агенти дедалі частіше самостійно планують, генерують, тестують і готують релізи з мінімальним втручанням людини, працюючи над усім циклом розробки, а не над окремим фрагментом коду. За прогнозом Gartner, до кінця 2026 року 40% enterprise-застосунків матимуть вбудованих task-specific AI-агентів проти менш ніж 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% завжди перевіряють такий код перед комітом (Sonar, «State of Code Developer Survey 2026», розбір результатів — Hyrax). Недовіра є практично у всіх, а дисципліна перевірки — лише у половини.

Найскладніша частина розробки в 2026-му не генерація коду, а governance: розуміти, що саме згенерував AI, чому саме так, і чи безпечно це випускати в продакшн, і саме цей шар роботи найлегше пропустити, коли фаундер нетехнічний.

Для нетехнічного фаундера оцінити цей шар роботи самостійно майже неможливо просто тому, що governance — те, чого він ніколи не бачив і не вмів оцінювати, навіть коли код писали люди.

Чому розмова з нетехнічним фаундером — інша дисципліна, а не «те саме, але простіше»

Може здатися, що робота консультанта з нетехнічним клієнтом — та сама робота з CTO, лише з меншою кількістю жаргону. Насправді різниця не в словнику, а в структурі розмови.

По-перше, зникає спільна база для перевірки. Коли розмова йде з інженером клієнта, він може перевірити запропоноване рішення, поставити уточнення, посперечатися про trade-off, помітити, коли хтось із сторін щось спрощує на шкоду точності. З нетехнічним фаундером цієї страховки немає: він або довіряє повністю, або йому просто нема на що спертися, щоб перевірити довіру. Це підвищує відповідальність на боці консультанта і водночас робить кожну рекомендацію потенційно непрозорою для клієнта.

По-друге, вимоги формулюються не в технічних, а в бізнесових координатах, які до того ж рухаються. У згаданому кейсі стратегія виходу на ринок змінилася просто під час обговорення: спершу клієнт планував продавати продукт медичним установам (B2B), що відразу тягне повний HIPAA-комплаєнс, бо медичні заклади в США є covered entities, які працюють із персональними медичними даними. Потім фокус зсунувся на прямий продаж кінцевим споживачам (B2C), і юридичний контекст навколо тих самих технічних рішень повністю змінився. Технічний партнер зазвичай одразу бачить зв'язок «модель продажів → регуляторні вимоги». Нетехнічний фаундер — ні, і це нормально: це просто не його зона експертизи.

По-третє, продукт, зібраний в AI-платформі, створює ілюзію завершеності: він працює, виглядає готовим, має інтерфейс, і фаундеру щиро незрозуміло, чому «трохи доробити» коштує стільки ж, скільки коштувала перша версія цілком. Наведена вище статистика саме це й пояснює: перші 70% рішення і останні 30% — принципово різні за складністю етапи роботи, хоча зовні цю різницю майже не видно.

Як це організовують інші

Gart Solutions не єдина компанія, яка зіткнулася з цією проблемою, — індустрія вже почала формувати відповідь, хоч і фрагментовано.

Найпомітніший напрямок — послуги fractional CTO: прошарок між бізнесом та інженерією, людина чи невелика команда, яка перекладає технічні рішення в бізнес-логіку — ризики, вартість, терміни, а не архітектурні деталі. Фаундеру не потрібно розуміти технологію, йому потрібно розуміти ризики, які він на себе бере, і вплив кожного рішення на бізнес.

Другий напрямок з'явився буквально протягом останнього року: окремі агенції почали пропонувати «vibe coding cleanup» чи «rescue engineering» як самостійну послугу — аудит згенерованого коду, оцінку архітектури, безпеки та готовності до CI/CD з подальшим планом стабілізації. За оцінкою масштабу ринку в $400 млн – $4 млрд це вже не нішева послуга, а окрема галузь. Показово, що такі агенції майже завжди пропонують безкоштовну первинну оцінку — саме тому, що на цьому етапі фаундер ще не може сформулювати технічний скоуп самостійно, а продавати платний аудит «наосліп» було б нечесно щодо клієнта.

Що з цього працює у Gart Solutions

Спираючись на власний досвід (і на кілька набитих гуль), у компанії поступово формують принципи роботи з фаундерами без технічного бекграунду.

  • Структурований дискавері замість вільної розмови. З технічним клієнтом можна імпровізувати — обидві сторони орієнтуються в темі й самі спрямовують розмову. З нетехнічним фаундером імпровізація небезпечна: легко пропустити критичне питання лише тому, що воно здається очевидним інженеру, але ніколи не спадало на думку людині без інженерного досвіду. Тут допомагає наперед підготовлений список дискавері-питань, згрупований за темами: compliance posture, обсяг і тип даних, поточне середовище, цільова архітектура, доступи й аудит, план міграції, інтеграції, пост-launch операції, бюджет і терміни, критерії успіху.
  • Переклад технічних рішень у бізнесові наслідки, а не в технічні альтернативи. Є велика різниця між питанням «AWS чи Supabase» і «швидший запуск без повного комплаєнсу зараз, або довший запуск з повною готовністю до B2B-угод з медичними закладами пізніше». Перше питання фаундер не може оцінити змістовно. Друге — може, бо це вже питання бізнес-стратегії, а не архітектури.
  • Письмові артефакти замість усних домовленостей. Нетехнічна людина забуває нюанси технічної розмови значно швидше за інженера, тому кожне архітектурне рішення принципово фіксується в документі чи діаграмі, до яких фаундер може повернутися за тиждень і все ще зрозуміти логіку.
  • Явне управління дрейфом вимог. Якщо вимоги можуть змінитися посеред проєкту (а в роботі з ранніми стартапами вони змінюються майже завжди), це потрібно закладати в процес, а не сприймати як зрив плану. У згаданому кейсі саме зміна моделі продажів (B2B → B2C) стала підставою для двофазної стратегії комплаєнсу: запуск без повного HIPAA зараз і активація повного комплаєнсу тоді, коли компанія реально почне підписувати угоди з медичними установами. Це рішення виникло не завдяки заздалегідь спланованому сценарію, а тому, що процес дозволяв перепланувати без відчуття «все зламалося».

Замість висновку

Вайб-кодинг не скасував потребу в інженерній дисципліні — він лише підняв ціну за її відсутність, бо тепер набагато простіше згенерувати значно більше коду й швидше, ніж хтось встигне помітити брак дисципліни. Практичний висновок звідси один: клієнт без технічного співзасновника — не менш серйозний клієнт, а клієнт, якому потрібен інший протокол роботи: структурований дискавері, переклад рішень у бізнес-наслідки і письмові артефакти замість усних домовленостей.

У Gart Solutions цю навичку свідомо тренують у команді, а не виносять в окрему посаду — принаймні поки що. Кількість «one-person AI-built» стартапів росте швидше, ніж індустрія встигає домовитися, як із ними правильно працювати, тож питання, ймовірно, постане гостріше для всіх уже за рік-два.

Ми свідомо тренуємо цю навичку в команді, а не виносимо її в окрему посаду — поки що. Кількість «one-person AI-built» стартапів росте швидше, ніж індустрія встигає домовитись, як із ними правильно працювати, тож підозрюю, що це питання постане гостріше для всіх нас уже за рік-два. Якщо у вашій команді вже склався інший підхід, буду радий обмінятися досвідом.

Федір Компанієць, CEO та співзасновник Gart Solutions

Джерело: IT Ukraine Association