Yuri Gubin, CTO at DataArt – Серія інтерв’ю

Yuri Gubin, CTO у DataArt — досвідчений технологічний керівник і архітектор програмного забезпечення, який провів у DataArt понад 18 років, просуваючись через ролі, що охоплювали архітектуру ПЗ, архітектуру рішень, хмарні технології, інновації та керівництво, перед тим як стати головним технічним директором у березні 2026 року. Його робота була зосереджена на вирішенні складних технологічних викликів у різних галузях, включаючи фінансові послуги, охорону здоров’я, туризм та IoT, з особливою експертизою в хмарних обчисленнях, ШІ, платформах даних та корпоративній архітектурі ПЗ. До того як стати CTO, Губін понад п’ять років обіймав посаду Chief Innovation Officer у DataArt і з 2021 року є членом Ради Партнерів компанії. Він також є професійним членом Forbes Technology Council, бере участь у її експертних групах з ШІ та хмарних обчислень, і служить технологічним радником Girls Who Code, де консультує щодо архітектури, захисту даних, управління платформою та технологічної політики. DataArt наразі зазначає його як головного технічного директора, розташованого у Нью‑Йорку.

DataArt — глобальна компанія з розробки програмного забезпечення та трансформації даних і ШІ, заснована у Нью‑Йорку у 1997 році. Компанія виросла до понад 6 000 технологічних фахівців, які працюють у більш ніж 20 країнах, і обслуговує понад 400 клієнтів, надаючи послуги в областях, включаючи штучний інтелект і машинне навчання, дані та аналітику, хмарну трансформацію, індивідуальну розробку ПЗ, кібербезпеку та модернізацію застарілих систем. DataArt працює у секторах, таких як фінансові послуги, охорона здоров’я та науки про життя, туризм, медіа та розваги, а також роздрібна торгівля, і підтримує технологічні партнерства з платформами, включаючи AWS, Google Cloud, Microsoft Azure, Snowflake та Databricks. У 2025 році компанія оголосила про інвестиції у розмірі 100 млн доларів США на три роки у свої можливості з даних та ШІ, а у 2026 році запустила Artisyn — модель операцій, що використовує ШІ, створена для інтеграції AI‑агентів, багаторазових прискорювачів, управління, безпеки та відповідності у розробку корпоративного ПЗ.

Ви провели майже два десятиліття у DataArt, просуваючись від архітектора ПЗ і архітектора рішень до Chief Innovation Officer, а тепер до CTO. Як цей шлях вплинув на ваш підхід до розрізнення справжніх трансформаційних технологій від циклів гіпу, і як він формує ваш «скептичний оптимізм» щодо ШІ сьогодні?

Ми спостерігали багато різних хвиль за ці роки, включаючи підйом хмари та мобільних технологій, різні покоління ШІ, автоматизацію, DevOps і SRE, і я писав код, створював архітектури та консультував наших клієнтів щодо багатьох з цих тем протягом усього цього часу. Я зрозумів, що, так, за допомогою технологій можна майже все, і технології дійсно потужні, але диявольське — у деталях, і вам потрібно розуміти, що ви робите, щоб це мало сенс і працювало.

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

Ви отримуєте хороше розуміння технології через дослідження та розробки (R&D) і, що важливо, через реальні проєкти, бо саме так ви дізнаєтеся, що можливо, чого не можливо і де можуть виникнути проблеми. Ви берете ці уроки з кожного залучення, спілкуєтеся з колегами, іншими архітекторами та аналітиками, і намагаєтеся зрозуміти, чи існують шаблони і чи можете ви створити якусь систему навколо них. Згодом це перетворюється на рекомендації, і тоді ви бачите, чи рішення, які ви вважали хорошими, дійсно приносять позитивні результати.

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

Enterprise AI, здається, переходить від фази заохочення експериментів до визначення, які експерименти дійсно заслуговують на масштабування. Які сигнали підказують, що випадок використання ШІ готовий до ширшого впровадження, і які ознаки попереджають, що компанія масштабує занадто рано?

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

Щоб зрозуміти, чи працює випадок використання ШІ, потрібно дати йому час і зрозуміти, яку цінність він приносить і яким є шлях користувача, бо тоді можна спостерігати підйоми та спади, а не лише миттєвий ефект «вау» у конкретній команді чи робочому процесі. Потрібно подивитися, що відбувається з тими ж людьми через кілька тижнів. Чи продовжують вони його використовувати? Чи залишаються вони задоволеними цим випадком, цією автоматизацією чи цим AI‑навиком, який вони створили, чи це лише короткочасний сплеск, який не варто масштабувати?

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

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

Ось моя скептична оптимістичність знову. Припустимо, що у вас вже є модель, і кілька тисяч людей щодня користуються ШІ, при цьому різні моделі та інструменти вже доступні. Коли з’являється нова модель, через ажіотаж і природну цікавість можна очікувати, що усі захотять її протестувати, що добре, проте такі експерименти не обов’язково будуть спрямовані або орієнтовані на конкретні результати, і іноді ви навіть не зможете виміряти різницю.

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

Ось чому перша група, яка оцінює нову модель, не повинна включати всіх у організації. Це має бути група R&D, яка тісно співпрацює з відповідними командами, а також з юридичним відділом і безпекою. Ми всебічно оцінюємо модель, проводимо швидку оцінку, а потім представляємо її ширшій аудиторії з коментарями та рекомендаціями щодо безпеки, відповідності та технологій. Оскільки нові моделі та великі оновлення з’являються постійно, вам потрібні ця модель і такий менталітет. Це дійсно не одноразове чи одноразове завдання.

DataArt створила крос‑функціональну «AI SWAT», що включає технології, юридичний відділ, відповідність, InfoSec та інші команди. Як ця група працює на практиці і які типи ризиків або питань потрібно вирішити, перш ніж новий інструмент ШІ буде схвалений для ширшого використання?

З моменту створення, я вважаю, ми встановлюємо різні цілі для цієї групи приблизно кожні чотири‑п’ять місяців. Ми змінюємо пріоритети, мету і іноді місію, і багато з цих цілей стосуються ШІ. Це може бути підвищення кваліфікації персоналу, вихід на ринок і нові можливості, партнерства або ширше впровадження ШІ в організації та по всьому ADLC.

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

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

Ось чому, коли ми оцінюємо нове партнерство, інструмент або акселератор, ми обговорюємо це відкрито, щоб усі розуміли, куди рухається процес, і мали можливість ставити питання або здійснювати нагляд. Для нового інструменту ШІ технології не можуть оцінювати його в ізоляції. Безпека, юридичний відділ і відповідність також повинні розуміти, як він обробляє дані компанії або клієнтів, які обмеження застосовуються і чи можна його безпечно використовувати в масштабі.

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

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

Ймовірно, різниця між тими, хто каже «ні», і тими, хто каже «так», полягає у їхній схильності до ризику та ставленні до неоднозначності та невизначеності. Те, що допомагає обом типам організацій, — це безперервна освіта, експерименти та оцінка. Навіть серед багатьох організацій, з якими ми працюємо і які впроваджують ШІ скрізь, залишаються виклики щодо вимірювання результатів і впливу. Якщо чесно, питання про те, як виміряти вплив ШІ і як оцінювати продуктивність команди, іноді виникає майже з нуля, ніби ніхто раніше про це не думав.

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

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

Коли ми бачимо типову ситуацію, коли ліцензія на ШІ надається кожному розробнику, а експерименти стають некерованими, усі починають створювати власні рішення і працювати по‑своєму. Зазвичай це призводить до недоцільних команд, незадоволених очікувань, відставання якості та зростання витрат. Суть у тому, що система не виконує те, чого очікує більшість, якість погана, і це стає дорогим. Щоб пом’якшити це, потрібен командний підхід, який є частиною ширшого підрозділу або організаційної ініціативи, і саме тут вступає в дію управління.

На рівні проєкту ви можете узгодити базу знань і контекст, а також випадки використання, де ви починаєте застосовувати ШІ. Потім створюються навички та агенти, які входять у процес розробки і які кожен може повторно використовувати, що дозволяє накопичувати знання та кращі практики, а не відтворювати їх щоразу. Така проєктна ініціатива повинна координуватися, наприклад, радою корпоративної архітектури, технологічною групою, CTO або командою, відповідальною за впровадження ШІ. Ви хочете повторно використовувати добре працюючі агенти, забезпечити надійність процесу і щоб це працювало по всій організації, а не перетворювалося на хаос і шум.

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

Витрата токенів і витрати на інференс можуть здаватися відносно невеликими під час пілотного проєкту, але стають значними, коли системи ШІ розгортаються серед тисяч співробітників або автономних агентів. Як підприємствам слід підходити до управління витратами на ШІ, і чи очікуєте ви появу чогось подібного до FinOps, спеціально для навантажень ШІ?

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

Отже, FinOps існує, і AI FinOps також існує. Деякі методи дуже технічні, інші – досить прості. Це може бути так просто, як вибір пріоритетної моделі, щоб не завжди користуватися найдорожчою, і поступово такі рішення починають економити гроші. Водночас знання про те, як заощаджувати та контролювати витрати, – лише половина рівняння. FinOps, на мій погляд, – це дисципліна і методологія, яка також залучає лідерів продукту та бізнесу, оскільки потрібно визначити, що саме вимірюється під час оцінки зусиль у сфері ШІ.

Тож так, я вважаю, що AI FinOps – це гарна тема для обговорення еквівалентом AI‑SWAT‑команди: скільки ви витрачаєте, скільки отримуєте назад, як це контролюєте і де знаходяться можливості.

Багато компаній просять продемонструвати ROI від ШІ, хоча вони ніколи не встановили надійний базовий рівень продуктивності своїх команд до впровадження ШІ. Що саме організації мають вимірювати, якщо хочуть визначити, чи створює ШІ значну бізнес‑цінність?

Незалежно від вашого ставлення до ШІ або вашого поточного стану, можливо, ви вже використовуєте агентів скрізь, або плануєте почати використовувати ШІ наступного року – встановлення базової лінії сьогодні є обов’язковим.

Існує кілька класів метрик. Деякі є суб’єктивними, і це може бути просто зворотний зв’язок від ваших розробників або співробітників, оскільки ви працюєте з людьми, і важливо розуміти, як вони сприймають цінність ШІ. Більш об’єктивні показники можуть починатися з механічних або синтетичних метрик, хоча я закликаю не прив’язуватись до них надмірно. Мається на увазі такі речі, як коміти коду чи story points. Ці метрики показують, що робота відбувалася, але вони не демонструють справжньої цінності чи впливу.

Більше значення мають метрики, які пояснюють, наскільки швидко або наскільки добре була виконана робота. Подумайте про метрики DORA, такі як час виконання чи MTTR, наскільки швидко ви можете відновитися після збою, наскільки швидко ви можете виправити помилку в продакшн, або як ці показники змінюються з часом. Одна цифра в певний момент не розповідає про траєкторію. Один із наших архітекторів нещодавно зазначив, що в розробці програмного забезпечення хорошою метрикою може бути також надійність оцінок у міру зростання впровадження ШІ, бо це щось говорить про стійкість цих зусиль і про те, наскільки продуктивними є команди. Ви також повинні стежити за витратами, бо якщо говорити лише про переваги, не розуміючи, скільки це коштує, ви не отримуєте повної картини.

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

DataArt вбудовує ШІ у весь життєвий цикл доставки програмного забезпечення через ініціативи, такі як Artisyn. Оскільки ШІ бере на себе більше завдань з впровадження, тестування та робочих процесів, які частини інженерії ПЗ стають більш цінними для людей, а які навички ризикують стати менш важливими?

Ви можете ефективно використовувати ШІ у розробці лише тоді, коли пам’ятаєте, що таке good. Вам потрібна ця експертиза, щоб керувати своїми агентами, переглядати результати, встановлювати обмеження та визначати правила. Ви повинні розуміти, що таке краща практика і якою має бути хороша архітектура, бо без цього ви можете не знати, що саме розробляється, і цінність такого виду експертизи зростає надзвичайно швидко.

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

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

Які навички стають менш важливими? Мені дійсно важко це сказати, хоча, можливо, швидкість набору коду. Жартую, але код тепер можна створювати набагато, набагато швидше, і специфічні знання про певну бібліотеку чи мову також можна вивчати значно швидше за допомогою ШІ.

Я бачив, як .NET‑розробники дуже швидко перекваліфікувалися у Java‑розробників, і п’ять‑десять років тому я б сказав, що робити це в масштабі майже неможливо. Сьогодні це можливо. Досвідчений старший розробник все частіше може переходити між мовами, бо справді важливим є його розуміння технологій, архітектури, кращих практик рішень, SDLC та ADLC.

Коли підприємства переходять від десятків пілотних проєктів ШІ до виробничих систем, які самостійно виконують дії, де в кінцевому підсумку має лежати відповідальність за дорогий помилковий крок ШІ‑агента: у розробника, у власника бізнесу, у постачальника моделі, у команді управління чи у їхній комбінації?

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

Дуже часто, коли щось йде не так, це процес, який не працює, тому в цьому сенсі відповідальність розподіляється між різними ролями. Але просте ствердження, що відповідальність спільна і, отже, безвинахідна, недостатнє. Її все одно треба розбити на конкретні обов’язки.

Розробники відповідають за код, який вони надсилають у pull‑request, і повинні розуміти, що відбувається. Архітектори відповідають за прийняті рішення та за архітектурні рішення, які надаються агентам і розробникам. Команда платформи відповідає за надійність рішення незалежно від того, хто чи що створило конкретний рядок коду.

Отже, відповідальність є, але її потрібно визначати детально за командами, ролями та підрозділами. Ви не можете зупинити аналіз на «ШІ це зробив». Потрібно запитати, які контролі, тести чи нагляд дозволили цьому збою потрапити у продакшн.

Якщо відсутність юніт‑тестів дозволила поганому коду потрапити у продакшн, або відсутність нагляду та рев’ю дозволила це, ви не можете перекласти цю відповідальність на ШІ. Ви також не можете просто звинуватити постачальника моделі чи хмарного провайдера за кожну помилку чи збій.

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