AI в технологічних компаніях: чому швидкий код гальмує бізнес

Код уже можна писати у кілька разів швидше. Але для технологічної компанії це не завжди означає швидший бізнес. Коли AI бере на себе частину розробки, слабкі вимоги, нечіткий roadmap, поверхневе ревʼю і розмитий ownership стають не меншою, а більшою проблемою. Про цей реальний зріз AI-впровадження розповів YouTube-канал Flow: про книги, бізнес та ідеї на основі закритої розмови близько десяти CTO зі США та Європи.

У дискусії брали участь технічні директори fintech-, tech- та AI-компаній. Це були не команди, які лише тестують GPT, Claude чи Gemini. У їхніх компаніях AI-системи вже працюють у продакшені, частину коду генерує штучний інтелект, а в окремих випадках класична QA-команда фактично зникла як окрема функція.

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

AI трансформація бізнесу: чому провали починаються з даних

Досвід, який описується, спирається на два контексти. Перший — Kin Geek, компанія з 11-річною історією, що створює white-label-рішення для фінтеху, банкінгу, платіжних систем і регульованих фінансових продуктів. У такому середовищі AI — це не лише швидкість, а й продакшн, безпека, compliance і юридична відповідальність.

Другий контекст — Easy Flow, бізнес, який займається AI-трансформацією. За півтора року команда провела сотні розмов із компаніями різного масштабу: від стартапів і scaleup-команд до великих ентерпрайзів.

Головний висновок із цих розмов не про те, яка модель краща. Компанії найчастіше провалюють AI-впровадження через неготові дані, слабкі процеси, відсутність відповідального власника змін і невибудуване управління трансформацією.

AI не прибирає організаційний хаос. Він робить цей хаос швидшим і дорожчим.

AI агенти у розробці: реальна межа — 2–3х, а не 20х

Щоб тверезо оцінювати AI в технологічних компаніях, варто розділяти чотири рівні зрілості.

Перший — ручна робота з чатами.

Другий — інженер, який використовує Copilot, Codex, Claude Code чи подібні інструменти.

Третій — агентні workflow, коли AI-агенти за інструкціями створюють артефакти або виконують завдання end-to-end, а людина перевіряє і затверджує результат. Саме третій рівень сьогодні виглядає найреалістичнішим для більшості компаній. Він може давати приблизно 2–3х продуктивності. Це вже серйозний результат, але ще не повна автономія.

Четвертий рівень — фабрика AI-агентів із заявками на 10х або 20х продуктивності. Для більшості бізнесів це поки радше орієнтир або маркетингова обіцянка. Показово, що жоден із CTO, які працюють із реальними продакшн-продуктами, не описав систему, де автономні агенти самі ухвалюють рішення про scope, архітектуру та релізи.

Автоматизація розробки: вузьке місце перейшло до вимог

Підписуйтеся на наші соцмережі

Раніше написання коду могло забирати приблизно 70–80% дня інженера. Тепер значну частину цієї роботи бере на себе AI. Але звільнений час не зникає — він переходить в архітектуру, security, ревʼю, тестування і відповідальність за якість.

В одній із компаній, яку згадували під час розмови, окремої QA-команди немає вже понад рік. Тести й перевірки виконує AI разом з інженером, який пише код і відповідає за результат. За словами учасників, багів стало менше, ніж будь-коли раніше.

Однак це не означає, що розробка стала простою. Вузьке місце лише змістилося. Якщо раніше бізнес чекав на інженерів, то тепер інженери дедалі частіше чекають на якісні вимоги, пріоритети, roadmap і контекст.

Слабка специфікація стала дорожчою. Раніше вона могла загальмувати одного розробника. Тепер може одночасно збити з курсу одного інженера і кількох AI-агентів, які працюють над продуктом паралельно.

AI у product delivery: PM і BA стають супервайзерами

AI adoption — це не просто видати команді Claude Code, Codex чи Copilot. Це перебудувати всю систему delivery: від вимог і acceptance criteria до test plan, code review, DevOps, security-перевірок і рішень про merge.

У зрілій моделі кожна роль поступово отримує свого AI-агента: BA, дизайн, розробка, QA, DevOps, PM. Але ключові гейти залишаються за людьми. Людина затверджує scope, перевіряє тест-план, проводить ревʼю, оцінює ризики й ухвалює рішення про продакшн.

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

Vibe coding у fintech: де потрібен інженерний контроль

AI дав нетехнічним ролям нову можливість: за вихідні зібрати прототип у Claude і принести його команді як майже готове рішення. Для CEO чи продуктового менеджера це може виглядати як прорив. Для інженерної команди — як потенційний ризик.

Прозвучали два підходи. Перший — hard rails: частина продукту може бути відкритою для експериментів нетехнічних людей, але критичні зони залишаються тільки за інженерами. Другий — приносити не «готовий код», а проблему, рішення або прототип рішення.

Це важлива межа. PM і бізнес-аналітики можуть генерувати специфікації, acceptance criteria, test cases і драфти UI-логіки. Але все, що йде у продакшн, має проходити branch protection, review, автоматизовані тести, security-перевірки й відповідального інженера.

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

AI трансформація команди: борд має питати не про скорочення

Тиск від CEO, борду або інвесторів часто звучить прямолінійно: якщо є AI, команда має бути меншою, а швидкість — вищою. Але така логіка може завести бізнес у хибні рішення.

У розмові згадували правило, яке повʼязують із Zapier: перед відкриттям нової ролі менеджмент має пояснити, чому це завдання не може повністю виконати AI. Такий підхід корисний як дисципліна мислення, але небезпечний, якщо перетворюється на автоматичне виправдання скорочень.

AI справді дозволяє сильній людині тягнути більший обсяг роботи. Компанія може замінити частину великого SaaS-продукту власним інструментом, якщо реально використовує лише 10% його можливостей. Але це не означає, що Salesforce можна переписати за два тижні. Можна відтворити лише той малий функціональний шматок, який справді потрібен бізнесу.

Те саме з ідеєю одного iOS-розробника на якісний застосунок. Це можливо тільки тоді, коли йдеться про винятково сильного фахівця: людину, яка розуміє бізнес, дизайн, клієнтів, архітектуру, технічні деталі й працює проактивно. Таких людей мало, вони дорогі, а до їхньої вартості треба додати ще й витрати на токени.

Тому розмову з бордом варто переводити з теми скорочень у тему результату: як змінився cycle time, чи стало менше переробок, чи зросла якість і чи швидше цінність доходить до клієнта.

Вартість токенів AI і compliance: чому потрібен план Б

Токени потрібно контролювати, але вони не можуть бути головною метрикою успіху. Сьогодні провайдер може дати більше токенів за ті самі гроші, завтра — підняти ціну втричі. У такій системі метрика швидко втрачає сенс.

Краще вимірювати прийняту, перевірену й простежувану роботу, яка дійшла до продакшену без ризиків. Також важливо дивитися на cycle time, кількість багів у клієнтів, обсяг переробок, рівень adoption серед ролей і те, як часто людина перекриває рішення AI-системи.

Compliance стає окремою темою. У подкасті згадується запит на AI-трансформацію, де в NDA був пункт, що підрядник не може використовувати AI-інструменти для самої трансформації. Це виглядає парадоксально, але добре показує стан ринку: правила ще формуються, а компаніям уже потрібно самостійно визначати межі безпеки.

Окремий ризик — дешева ера AI може закінчитися. Доступ до моделей, ціни й правила використання можуть змінюватися швидко. Тому компаніям потрібен план Б: локальні моделі, гібридні схеми, дешевші моделі для low-risk завдань і сильніші — для архітектури, security та критичних рішень.

Не менш важливо не привʼязувати критичні процеси до одного AI-провайдера. Вимоги, архітектурні документи, тести, правила review, playbook і єдине джерело правди мають жити у власних системах компанії: Jira, Git, документації та внутрішніх базах знань, а не лише в контексті Claude, OpenAI чи Gemini.

AI в технологічних компаніях: виграє не бібліотека промптів

Найближчий рік може стати жорстким тестом для AI-стартапів-обгорток, які тримаються лише на API OpenAI чи Claude. Якщо лідери ринку вбудують ці функції у власні моделі, частина таких продуктів втратить сенс.

Ще один ризик — юридичний відкат для компаній, які тренували моделі на чужих даних без згоди. Паралельно зростатиме залежність бізнесу від кількох AI-провайдерів. Один великий збій у лідера ринку може зачепити сервіси, які вже стали частиною щоденної інфраструктури.

Тому виграють не ті компанії, які зберуть найбільшу бібліотеку промптів. Виграють ті, хто краще організує дані, контекст, відповідальність, ревʼю, безпеку і контроль витрат.

AI агенти можуть різко посилити розробку, але human in the loop залишається базовим принципом. Людина має ухвалювати рішення там, де є ризик, гроші клієнтів, архітектура, security, compliance або стратегічний вибір.

Якщо дешева ера AI справді закінчиться, стійкішими будуть не найгучніші експериментатори, а компанії з власним context layer, прозорими метриками, диверсифікованими моделями й чітким розумінням, хто відповідає за результат.