Від SaaS до персоналізованих AI-агентів: наступний крок у бізнес-софті

Або чому “давайте впровадимо Claude” — це не стратегія

Я почав думати про це не під час стратегічної сесії, не після чергового звіту McKinsey і навіть не після надихаючого поста в LinkedIn, де хтось знову “переосмислив майбутнє роботи” втретє за цей місяць.

Я почав думати про це, коли вкотре оптимізував дизайн-систему та внутрішні процеси компанії під AI First підхід.

Ми обговорювали Claude Code, Claude Design, design-to-code pipeline, інтеграцію дизайн-системи з кодом, Storybook, Figma, Code Connect, агентні workflows, прототипи, які можна збирати швидше, і все в такому дусі.

Іншими словами, стандартний набір сучасного продуктового шаманізму.

І в якийсь момент у мене з’явилося дивне відчуття.

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

Ти розумів: ця робота стабілізує продукт. Ця зменшить хаос. Ця пришвидшить команду. Ця зменшить кількість рішень, прийнятих “на око”. Ця допоможе дизайнерам і розробникам говорити однією мовою.

Цінність була відчутною.

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

Сьогодні ми оптимізуємо передачу дизайну в розробку. Завтра дизайнер уже може зібрати майже production-like prototype за допомогою AI. Сьогодні ми документуємо правила для компонентів. Завтра агент читає документацію, кодову базу і сам пропонує реалізацію. Сьогодні ми обговорюємо, як пришвидшити design-to-code. Завтра питання вже не в тому, як передати дизайн у код, а в тому, чи потрібен увесь звичний процес у тому вигляді, в якому він існував раніше.

І ось тут з’являється важливіша думка.

Можливо, проблема не в тому, що ми недостатньо швидко впроваджуємо нові інструменти.

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

SaaS не помер. Спокійно, акаунт можна не видаляти

Почнімо без звичної LinkedIn-драми.

SaaS не помер. Насправді ринок програмного забезпечення все ще зростає. Gartner прогнозує, що світові витрати на IT досягнуть $6.15 трлн у 2026 році, а software залишатиметься однією з категорій витрат, що зростають найшвидше.

Тож якщо хтось каже “SaaS помер”, є велика ймовірність, що він продає вам курс “Як побудувати AI-агента за 7 днів і звільнитися з роботи”.

SaaS усе ще дуже живий. Компанії досі купують CRM, ERP, accounting tools, HR platforms, design tools, compliance systems, dashboards, analytics products, helpdesks і все інше. Бізнес не може просто прокинутися в понеділок і сказати: “Видаляємо весь enterprise stack, тепер у нас один агент на ім’я Борис Бритва. Передаємо привіт Гаю Річі.”

Так це не працює.

Але важливіше інше: SaaS може не померти як ринок, але може перестати бути основною моделлю, через яку люди взаємодіють із роботою.

І ось це вже набагато цікавіше.

Що таке класичний SaaS насправді

Класичний SaaS продає доступ до інструмента.

У тебе є задача: підготувати податкову декларацію, обробити інвойс, перевірити документи, зібрати звіт, провести клієнта через onboarding, оновити CRM, створити дизайн, написати код.

SaaS каже:

“Ось тобі інтерфейс. Ось меню. Ось фільтри. Ось таблиці. Ось налаштування. Ось документація. Ось 14 вкладок. Успіхів.”

Користувач виконує роботу всередині продукту.

Саме тому SaaS так довго будувався навколо інтерфейсів. Логіка була проста: людина заходить у систему, дивиться на екран, розуміє структуру, натискає кнопки, вводить дані, перевіряє результат і рухається далі.

Це був світ, у якому software був інструментом, а людина була оператором.

Так, інструмент міг бути хорошим. Так, UX міг бути чудовим. Так, дизайн-система могла пришвидшити розробку. Так, продукт міг бути розумнішим за конкурентів.

Але фундаментально модель була така:

Людина працює. Програма допомагає.

AI-агенти починають перевертати цю модель.

AI First часто розуміють занадто вузько

Коли компанія каже “ми стаємо AI First”, дуже часто це означає щось цілком практичне: підключити Claude Code, дати дизайнерам доступ до Claude Design, вбудувати AI в сапорт, автоматизувати research, написати промпти, створити внутрішні гайди, провести воркшоп і, звісно, створити Slack-канал #ai-transformation, бо очевидно, що без Slack-каналу жодна трансформація не відбудеться.

Усе це може бути корисним.

Але це не обов’язково змінює бізнес.

Це може просто замінити виконавця.

Раніше код писала людина. Тепер це людина плюс Claude Code. Раніше дизайнер збирав прототипи вручну. Тепер це дизайнер плюс Claude Design. Раніше аналітик писав SQL. Тепер це аналітик плюс AI. Раніше сапорт відповідав клієнтам. Тепер це сапорт плюс AI.

Це прискорення. Але це не переосмислення.

Як компанія, ви все ще будуєте той самий SaaS-продукт, для того самого ринку, з тією самою моделлю і тим самим interface-first мисленням. Просто тепер у вас швидші внутрішні процеси.

Це як перейти з Photoshop на Figma. Важливо? Так. Чи змінює це природу бізнесу? Ні.

Це як перейти від ручної front-end реалізації до design-to-code pipeline. Корисно? Так. Але податкова платформа від цього не стає новою продуктовою категорією.

І ось тут з’являється головне питання:

Ми просто впроваджуємо нові інструменти, щоб швидше будувати старий SaaS?
Чи ми готові переосмислити, чим має стати наш продукт у світі AI-агентів?

Справжній зсув: від інструмента до виконавця

Радикальний зсув починається не тоді, коли AI допомагає користувачу натискати кнопки.

Він починається тоді, коли користувач перестає бути головним оператором системи.

Класичний SaaS каже:

“Ось платформа. Зайди і зроби роботу.”

AI-агент каже:

“Скажи, який результат тобі потрібен. Я пройду процес, перевірю дані, поставлю питання, виконаю дії, покажу винятки і попрошу approval там, де потрібне людське рішення.”

Це вже не просто інтерфейс. Це інший контракт між користувачем і продуктом.

Користувач купує не доступ.
Користувач купує виконання.

Не “у нас є модуль інвойсів”.
А “інвойси будуть оброблені”.

Не “у нас є tax dashboard”.
А “податкову декларацію буде підготовлено, перевірено і передано на review”.

Не “у нас є CRM pipeline”.
А “ліди будуть кваліфіковані, follow-ups будуть відправлені, ризики будуть підсвічені”.

Не “у нас є дизайн-інструмент”.
А “прототип буде зібраний, перевірений на consistency, підготовлений до review і частково реалізований у коді”.

Це вже не SaaS у традиційному сенсі. Це ближче до персоналізованого цифрового працівника.

І так, технічно це все ще може продаватися через хмару. Формально можна сказати: “Ну, це теж SaaS.” Але це буде приблизно так само точно, як сказати, що Tesla і віз із конем — це обидва транспортні засоби.

Формально так. По суті — ні.

Чому Anthropic є важливим прикладом

Anthropic цікавий не просто тому, що має хороший чат-бот.

Цікаво те, що продукти на кшталт Claude Code починають змінювати саму роль інструмента. Anthropic описує Claude Code як agentic coding system, яка може читати кодову базу, змінювати файли, запускати тести і доводити код ближче до commit-ready стану.

Це вже не “асистент, який підказав шматок коду”.

Це система, яка бере задачу і починає діяти всередині робочого середовища.

Тепер додамо Claude Design, який дозволяє людям створювати дизайни, прототипи, слайди, one-pagers і візуальні матеріали в колаборації з Claude. Це вже не просто “AI допомагає дизайнеру”. Це AI бере участь у створенні результату.

Спочатку AI відповідав.
Потім AI писав.
Потім AI редагував.
Потім AI почав працювати всередині інструментів.
Тепер AI стає виконавцем у конкретній професійній доменній області.

Це не означає, що дизайнери й розробники зникнуть завтра вранці. Спокійно, Figma можна не видаляти і в ліс не переїжджати.

Але роль людини зміщується.

Людина менше клікає.
Людина дедалі більше задає напрям, перевіряє, обмежує, ухвалює рішення і відповідає за якість.

Чому Google ще цікавіший

Google, здається, дивиться ще ширше.

Gemini Enterprise Agent Platform описується як платформа для створення, масштабування, управління й оптимізації enterprise-ready агентів. Іншими словами, це не просто готовий AI-продукт. Це інфраструктура для побудови агентних систем усередині компаній.

Gemini Enterprise також включає Agent Designer: no-code / low-code середовище, де люди можуть створювати single-step і multi-step агентів, описувати задачі природною мовою, візуально редагувати workflows, підключати джерела даних і запускати агентів за розкладом.

І ось тут з’являється дуже цікавий парадокс.

Gemini Enterprise сам по собі є SaaS.

Але він дозволяє створювати речі, які можуть замінити частину потреби в SaaS.

Іншими словами, це SaaS для створення анти-SaaS.

Звучить як жарт, але насправді це дуже серйозна стратегічна позиція.

Google не просто каже: “Ось вам ще один інструмент.”
Google каже: “Ось вам середовище, де ви можете створювати цифрових виконавців для власних процесів.”

Це вже не просто ринок окремих застосунків. Це ринок агентних робочих систем.

Вертикальний AI-агент як вбивця частини SaaS

Тепер перейдемо ближче до tax, accounting і financial products.

Уявімо класичну SaaS-платформу для податків. У ній є client profiles, documents, forms, statuses, tasks, notifications, roles, approvals, dashboards, reports, workflows та integrations.

Усе це потрібно, тому що людина має бачити процес і керувати ним.

Тепер уявімо не платформу, а tax AI-агента, налаштованого під конкретну accounting firm.

Він знає спеціалізацію фірми, типи клієнтів, локальні податкові правила, внутрішній review process, стиль комунікації, потрібні документи, типові помилки, тон пояснень, ролі в команді й ситуації, де потрібен accountant approval.

Клієнт не заходить у “платформу”.
Він пише агенту:

“Що мені потрібно підготувати для self assessment?”

І агент не просто показує статтю з help center. Він дивиться на контекст клієнта, перевіряє документи, розуміє missing information, пояснює наступний крок, готує summary для бухгалтера і може надіслати нагадування клієнту, якщо це дозволено процесом.

Для accounting firm це вже не просто SaaS.

Це робочий шар між фірмою, клієнтом, документами, податковими правилами і внутрішніми процесами.

Ось це і є радикальний зсув.

Не “ми додали AI-кнопку в dashboard”.
А “dashboard більше не є головним способом, у який відбувається робота”.

Це вже починається в accounting і tax

Це не наукова фантастика з майбутнього, де всі носять сріблясті костюми і розмовляють із холодильником.

У tax і accounting компанії та продукти вже рухаються в бік AI-агентів і vertical AI.

Наприклад, Juno, CPA-founded AI tax startup, починала як co-pilot, а пізніше запустила tax product, який швидко виріс серед tax firms. Цікаве тут не лише зростання. Цікава сама логіка: AI не просто допомагає користувачам натискати кнопки всередині старої системи. Він починає брати на себе частини tax workflow.

Balance з Y Combinator описує себе як AI accounting firm для SMBs. Їхній AI-агент Bea займається reconciliation, categorization і reporting, а людські accountants перевіряють books і подають returns. Особливо цікаво, що інтерфейсом взаємодії можуть бути Slack, WhatsApp або email. Іншими словами, користувач не обов’язково живе всередині класичної SaaS-платформи.

Thomson Reuters у 2025 році анонсувала agentic AI solutions для tax, audit і accounting workflows, включно з automated tax preparation у форматі “Ready to Review”. Wolters Kluwer також пише про зсув від task automation до workflow orchestration в accounting.

І це ключовий момент.

Майбутнє не в тому, щоб просто “додати AI”.
Майбутнє в тому, щоб перебудувати продуктову архітектуру так, щоб агенти могли безпечно виконувати роботу.

SaaS не зникне. Він стане backend для агентів

Найімовірніший сценарій не такий:

Був SaaS, потім прийшли агенти, SaaS помер, усі поплескали.

Швидше за все, буде приблизно так:

SaaS перестане бути головним інтерфейсом, але залишиться інфраструктурою.

Агентам усе одно будуть потрібні data, permissions, audit logs, workflows, integrations, business rules, compliance, source of truth, APIs, role models, billing, approvals і action history.

Іншими словами, уся нудна доросла частина продукту нікуди не зникне.

Але користувач може все рідше заходити в інтерфейс напряму.

Сьогодні SaaS каже:

“Відкрий екран, знайди задачу, виконай дію.”

Завтра агент каже:

“Я знайшов 12 клієнтів із missing documents, підготував повідомлення, 3 випадки потребують accountant review, а 2 клієнти мають ризик, пов’язаний із expense classification. Approve?”

І в цей момент SaaS стає не місцем, де живе людина, а системою, у якій діє агент.

Це величезна різниця.

Чому гонка за інструментами небезпечна

Тепер повернімося до компаній, які “стають AI First”.

Проблема не в тому, що вони впроваджують Claude, Gemini, OpenAI, Figma AI, Cursor, Code Connect або щось інше. Це нормально. Це потрібно. Це частина адаптації.

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

Це якби компанія у 2012 році сказала:

“Ми тепер mobile-first, бо купили всім iPhone.”

Ні. Ви купили телефони.

Mobile-first означав переосмислення продукту, поведінки користувачів, контексту використання, інтерфейсу, швидкості, notifications, geolocation, payments, camera, offline scenarios і всього іншого.

AI First також не означає “у нас є підписка на Claude”.

AI First має означати, що компанія починає ставити собі більш незручні питання.

Які процеси більше не мають виконуватися людьми вручну? Які частини продукту мають стати агентними? Які інтерфейси перестануть бути основним способом, у який відбувається робота? Які дані мають стати доступними для безпечного виконання дій? Які рішення потребують approval? Які задачі можна продавати як outcomes, а не як access?

І найважливіше питання:

Де ми перестаємо будувати “ще один екран” і починаємо будувати “виконавця”?

Саме це відрізняє adoption інструментів від стратегічного переосмислення.

Prompt engineering як маленький урок

Історія з prompt engineering дуже добре показує, чому небезпечно будувати стратегію навколо поточної форми інструмента.

Ще нещодавно здавалося, що prompt engineering стане великою окремою професією. Будуть люди, які знають спеціальні формули, магічні послідовності, правильні дужки, правильний порядок слів, правильне “act as a senior world-class award-winning...” та інші заклинання.

Але що ми бачимо зараз?

Промпти стають простішими. Моделі краще розуміють звичайну людську мову. Щоб створити хороше зображення, вже не завжди потрібно писати технічне есе на кшталт:

cinematic lighting, ultra detailed, octane render, trending on artstation, 8k, masterpiece, please don’t make six fingers

Часто достатньо чітко пояснити задачу.

Цінність зміщується від “знати формулу промпта” до розуміння задачі, здатності добре пояснювати, чітко ітерувати, мати смак, доменну експертизу, вміння оцінити результат і прийняти рішення.

Те саме станеться з багатьма AI-інструментами.

Сьогодні ми вивчаємо конкретні інтерфейси. Завтра ці інтерфейси можуть зникнути, злитися або стати автоматичними.

Якщо компанія будує стратегію навколо конкретного інструмента, вона постійно наздоганятиме.

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

Головне питання для SaaS-компаній

Якщо ви будуєте SaaS-продукт, особливо у складному домені на кшталт tax, accounting, legal, compliance, healthcare, insurance, finance або enterprise operations, головне питання більше не звучить так:

“Як нам вбудувати AI в продукт?”

Це занадто маленьке питання.

Краще питання:

“Якби клієнту не потрібно було користуватися нашою платформою напряму, яку роботу наш продукт мав би виконувати від його імені?”

Ще жорсткіша версія:

“Які частини нашого інтерфейсу існують лише тому, що раніше не було агента?”

Це болюче питання. Особливо для product designers. Бо відповідь може бути некомфортною.

Багато екранів існують не тому, що користувач хоче ними користуватися.

Вони існують тому, що системі потрібен людський оператор.

А якщо оператором стає агент, інтерфейс змінюється радикально.

Він не зникає повністю. Але стає іншим. Менше navigation заради navigation. Менше manual input. Менше tables заради tables. Більше review. Більше exceptions. Більше explainability. Більше auditability. Більше controls. Більше “approve / reject / ask why”. Більше trust і responsibility.

Це вже не просто UX.

Це governance of delegated work.

Звучить добре. Можна вставляти в leadership deck.

Що це означає для дизайн-систем

Для дизайн-систем це теж некомфортна, але цікава новина.

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

Вона має почати описувати нові типи взаємодії: approval flows, exception handling, confidence states, human-in-the-loop logic, audit trails, source citation, reversible actions, permission escalation, autonomous and assisted modes, explainability і trust boundaries.

Іншими словами, дизайн-система має рухатися від UI kit до operating model.

І саме тут стає зрозуміло, чому просто “зробити компоненти красивішими” недостатньо.

Якщо агент може сам створювати, змінювати, відправляти, класифікувати, перевіряти і запускати процеси, головне дизайнерське питання вже не “як виглядає dropdown?”

Головне дизайнерське питання стає таким:

“Як людина розуміє, що агент зробив, чому він це зробив, де ризик, що можна скасувати, де потрібна відповідальність і хто тепер володіє рішенням?”

Це зовсім інший рівень патернів.

Компанія має не лише рухатися швидше. Вона має розуміти, що продає

Є два шляхи.

Перший шлях — гонка за інструментами.

Компанія впроваджує Claude, навчає команду, через місяць виходить новий tool, проводиться новий воркшоп, створюються нові гайди, усе частково застаріває, і процес повторюється.

Це не погано. Це неминуча операційна гігієна.

Але це не стратегія.

Другий шлях — переосмислення продукту як агентної системи.

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

Наприклад, для tax/accounting SaaS це може бути не “AI assistant inside the dashboard”, а окремий продуктовий шар:

personal tax preparation agent for small accounting firms

або: client document collection agent trained on your firm’s workflow

або: expense classification review agent with accountant approval

або: MTD readiness agent for UK accountants

Це вже не просто feature. Це новий продуктовий шар.

Моя гіпотеза

Моя гіпотеза проста:

SaaS не помре. Але SaaS-інтерфейс перестане бути центром бізнес-софту.

Центром стане агент, який розуміє задачу, контекст, дані, обмеження і може виконувати роботу від імені користувача або компанії.

Старий SaaS продавав доступ до системи.
Новий агентний продукт продаватиме делеговану роботу.

Старий SaaS казав: “Зайди і зроби.”
Новий продукт казатиме: “Я зробив. Перевір винятки.”

Старий SaaS конкурував кількістю функцій.
Новий продукт конкуруватиме якістю виконання, довірою, доменною експертизою, інтеграціями і безпекою.

Старий SaaS вимірював seats.
Новий продукт дедалі частіше вимірюватиме outcomes.

І це, можливо, головний зсув.

Не “AI допоможе нам швидше будувати SaaS”.
А “AI змусить нас перебудувати саму ідею SaaS”.

Фінальна думка

Компанії, які сьогодні просто впроваджують AI-інструменти, звісно, рухатимуться швидше.

Вони швидше писатимуть код. Швидше робитимуть дизайн. Швидше збиратимуть прототипи. Швидше відповідатимуть клієнтам. Швидше генеруватимуть документи.

Це добре.

Але стратегічно вони все ще можуть залишатися в позиції тих, хто наздоганяє.

Бо справжнє питання не в тому, який інструмент ми використовуємо сьогодні.

Справжнє питання:

“Що станеться, коли клієнту більше не потрібно буде користуватися нашим SaaS так, як він користується ним зараз?”

Ось тут починається цікава частина.

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

Він може забрати саму категорію.

А ми тим часом будемо дуже ефективно впроваджувати черговий інструмент, який за три місяці знову застаріє.

Зате Slack-канал #ai-first-transformation виглядатиме красиво.