Чому українські сервісні компанії мають змінитися — або померти

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

У травні цього року Google випустила звіт The New SDLC With Vibe Coding — 51 сторінка, серед авторів, зокрема, добре відомий спільноті Адді Османі.

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

І його варто прочитати всім, хто працює в IT-галузі, але особливо сильно це стосується наших українських сервісних компаній, бо, на моє переконання, саме вони зараз у зоні найбільшого ризику. Спробую пояснити детальніше. Кілька ілюстрацій далі по тексту я взяв саме з цього звіту і коментарів до нього з блогу Адді Османі.

Що декларує Google

У документі Google описує поточний стан речей і робить із нього висновки. Лише подумайте над цим: станом на початок 2026 року близько 85% професійних розробників регулярно користуються AI-агентами для створення коду, і 41% усього нового коду згенеровано AI. Тобто це вже давно мейнстрим, а не якісь нішеві експерименти.

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

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

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

Вайб-кодинг — цілком робочий варіант, але лише до певного рівня проєкту

Наступне — за останні три-чотири роки галузь пройшла кілька рівнів автономності: спочатку лише автодоповнення фрагментів коду (2021–2022), потім робота в режимі чату (2023), далі робота з агентами (2024–2025), і нарешті — автономні агенти, те, що ми маємо станом на сьогодні: агент сам клонує репозиторій, планує зміни в багатьох файлах, виконує їх в ізольованому середовищі, ганяє тести, відкриває pull request, і за певних умов навіть може сам його змерджити.

Рівні агентної автономності

Ну і найцікавіше: якщо всі попередні етапи ще можна було вписати у традиційний Scrum-подібний SDLC, то тепер, стверджують автори, ми дозріли до зміни SDLC як такого.

Імплементація більше не найдорожча

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

Новий AI-Driven SDLC

Відповідно, складність зміщується в інше: підготувати ці специфікації, а результат — верифікувати та валідувати.

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

А от друга частина — верифікація та валідація — в епоху агентів стає по-справжньому складною інженерною задачею. Людині навіть просто прочитати й зрозуміти згенерований агентами код за таких обсягів — уже непідйомна задача. І, як виявляється, для агентів це теж непросто: написати код агенту легше, ніж якісно перевірити. Тому збудувати ефективну систему перевірки результату за всіма критеріями якості — дуже нетривіальна задача, і коштує вона, насправді, істотно дорожче, ніж та частина, яка імплементує. Тут потрібно чимало специфічних знань значно вищого рівня, ніж «ось тобі вимоги — зроби рішення».

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

Що з продуктовими компаніями

Багато продуктових компаній швидко побачили вікно можливостей і почали активно інвестувати в навчання, інфраструктуру, інструменти і — що особливо важливо — почали змінювати самі процеси SDLC. Наприклад, дали можливість продакт-менеджерам та бізнес-аналітикам прототипувати з AI. Або почали вводити нові ролі, яких не було раніше (агентні інженери, прототипувальники, рев’ювери і т.п.)

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

Звичайно, що продуктові компанії теж маю свої проблеми і виклики, але загалом з мого досвіду вони значно відкритіші до серйозних рішучих змін.

А що з сервісними компаніями і чому вони в зоні ризику

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

Класична бізнес-модель сервісної компанії — це, по суті, продаж людино-годин. Rate sheet, команда з N людей на M місяців і пірамідка з джунів, мідлів та сеньйорів, у якій значна частина маржі часто робилася саме на джуніорних позиціях. Проблема в тому, що нова реальність б’є одразу по всіх елементах цієї моделі.

Зникає сама передумова. Замовнику вже не «дорого і довго робити самому». Його продакт-менеджер за вечір збирає з AI прототип, а внутрішня команда з трьох інженерів з агентами закриває обсяг, під який раніше наймали двадцять людей ззовні. Аргумент «у нас є люди, яких у вас немає» стрімко втрачає вагу.

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

Змінюються очікування замовників. Клієнти читають ті самі звіти й бачать ті самі демо, де розказують про те, що AI тепер все робить швидко і якісно (звичайно, що це не завжди об’єктивно, і його треба тверезо оцінювати, але на це не кожен здатен). Питання «чому це коштує стільки і триває півроку, якщо агенти пишуть код за години?» буде звучати зі сторони клієнта все частіше, і відповіді «у нас такий процес» чи «так порахував наш естімейт» більше не працюють. Тиск на існуючу бізнес модель, вартість робіт і тривалості проєктів буде тільки наростати.

Естімейти. Для оцінки тривалості та вартості проєктів додається багато невідомих. Зокрема, з’являється вартість токенів, яку заздалегідь оцінити непросто, і в компаніях немає накопиченого попереднього досвіду для оцінки. Плюс терміни виконання проєкту тепер отримують значно більший діапазон варіативності — з одного боку результат можна видавати дуже швидко, з іншого — доведення його до продакшин-реді стану може займати значно більше часу, ніж здається на перший погляд.

Нові моделі компетентностей. Вимоги до знань/вмінь фахівців змінюються з небаченою раніше швидкістю. На голову інженера, який використовує агентів у своїй роботі, звалюється просто величезний пласт нової інформації — LLM-моделі, токени, скіли, MCP, агенти/сабагенти, оркестрація, промпт/контекст інжиніринг, безпека, витрати, цикли, харнесс і т.д і т.п. Це не можна просто додати до існуючих моделей компетентностей і оцінювати всіх традиційними мірками. Для того щоб щось додати, треба мати сміливість щось забрати, а на такі революційні зміни в підходах до оцінки людей на інтерв’ю чи апрайзалах мало хто готовий.

І окремий український нюанс: сервісний сегмент — це кістяк нашого IT-експорту. Ми конкуруємо за ті самі контракти з Індією, Латинською Америкою та Східною Європою, і там на агентні процеси переходять так само активно. Той, хто перебудується першим, забере ринок у того, хто «хоче дочекатися, щоб все стабілізувалося, щоб знати, як воно має бути».

Що з цим робити

Чи означає це, що сервісна модель приречена? Зовсім ні. Просто треба максимально швидко трансформуватися. Що, на мою думку, потрібно робити вже зараз.

Продавати результат, а не години. Білінг за людино-години прямо конфліктує з AI-продуктивністю: що ефективніше ви працюєте, то менше заробляєте. Fixed price, outcome-based і value-based моделі з незручної екзотики перетворюються на умову виживання.

Зробити агентну інженерію ключовою компетенцією. Специфікації, багаторівневе рев’ю, автоматизовані верифікація та валідація, безпека, відповідність регуляторним вимогам — саме це стає найдорожчою частиною розробки, і саме цю експертизу замовник не збудує собі «за вечір». Якщо ви в це інвестуєте зараз, то зможете показати чим ви дійсно кращі за конкурентів.

Перебудувати власний SDLC, не чекаючи вимог клієнта. Розробка на основі специфікацій, пайплайни з агентами, метрики якості згенерованого коду, чітко визначені точки людського контролю. Це вимагає часу та експериментів — нагадаю, що мій клієнт зі своєю «фабрикою» витратив на це не один місяць.

Змінити структуру команд і перевчити людей. Менше «рук», більше інженерів, які вміють керувати фабрикою агентів: писати специфікації, проєктувати перевірки, розбиратися в домені. Джуніорні позиції не зникнуть, але їхній зміст буде зовсім іншим — і шлях зростання теж доведеться проєктувати заново.

Продуктизувати експертизу. Власні акселератори, референсні пайплайни, готові агентні платформи під типові класи задач — усе, що дозволяє стартувати проєкт за дні, а не місяці, і що відрізняє вас від «просто команди на аутстаф».

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

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

Google своїм звітом, по суті, офіційно зафіксувала те, що багато хто з нас уже бачив на практиці: точку неповернення пройдено, і SDLC вже не буде таким, як раніше.

Я бачу, що за якихось три роки ринок неймовірно розшарувався. Дехто з команд досі живе у 2023-му — чат, копіпаст коду в редактор, а подекуди AI взагалі заборонений. А дехто вже запускає фабрики автономних агентів — аж до таких, що здатні вдосконалювати самі себе. Цікаво, що причина розриву — не в здатності розробників як таких, а у тому чи працюють системно компанії над впровадженням інструментів. Надія, що «розробники якось самі навчаться» вечорами після закриття тасок, не спрацює, я це особливо розумію, бо сам всі ці роки значну частину свого часу лише те й роблю, що навчаюся, але є відчуття що заледве встигаю за всім, що відбувається. Тут потрібні вибудувані системи навчання, перебудовані процеси і подекуди жорсткі управлінські рішення.

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

З чого почати компаніям? З чесної діагностики. Я для цього виклав на dev-ai.dev безкоштовні чеклісти самооцінки агентної зрілості — персональний і командний. Вони питають не «що ви знаєте», а «що ви реально робите»: чи є у команди спільний AGENTS.md та skills, як побудована верифікація, скільки роботи насправді делегується агентам. На виході — ваш поточний рівень автономності та розуміння, що підтягувати далі. Попереджаю: дуже часто відчуття «та в нас усе добре з AI» після такої перевірки виявляється ілюзією. А якщо після самооцінки захочеться рухатися далі — ви знаєте, де мене шукати.

Смерть сервісних компаній, які не зміняться, не виглядатиме як вибух. Вона виглядатиме як повільне стискання: коротші контракти, менші команди, тиск на рейти, замовники, які «вирішили спробувати самі». А потім у якийсь момент виявиться, що продавати вже нічого. То у вас ще є вибір це все змінити.