Yuri Gubin, CTO w DataArt – Seria wywiadów

Yuri Gubin, CTO w DataArt jest doświadczonym menedżerem technologicznym i architektem oprogramowania, który spędził ponad 18 lat w DataArt, awansując przez role obejmujące architekturę oprogramowania, architekturę rozwiązań, technologię chmurową, innowacje oraz przywództwo executive, zanim w marcu 2026 objął stanowisko Chief Technology Officer. Jego praca koncentrowała się na rozwiązywaniu złożonych wyzwań technologicznych w różnych branżach, w tym usług finansowych, opieki zdrowotnej, podróży i IoT, ze szczególną ekspertyzą w zakresie przetwarzania w chmurze, AI, platform danych oraz architektury oprogramowania korporacyjnego. Przed objęciem stanowiska CTO, Gubin pełnił ponad pięć lat funkcję Chief Innovation Officer w DataArt i od 2021 roku jest członkiem Rady Partnerów firmy. Jest także profesjonalnym członkiem Forbes Technology Council, uczestnicząc w grupach ekspertów AI i Cloud Computing, oraz pełni rolę doradcy technologicznego w Girls Who Code, gdzie doradza w zakresie architektury, ochrony danych, zarządzania platformą i polityki technologicznej. DataArt aktualnie wymienia go jako Chief Technology Officer z siedzibą w Nowym Jorku.

DataArt jest globalną firmą zajmującą się inżynierią oprogramowania oraz transformacją danych i AI, założoną w Nowym Jorku w 1997 roku. Firma rozrosła się do ponad 6 000 specjalistów technologicznych działających w ponad 20 krajach i współpracuje z ponad 400 klientami, świadcząc usługi w obszarach m.in. sztucznej inteligencji i uczenia maszynowego, danych i analityki, transformacji chmurowej, inżynierii oprogramowania na zamówienie, cyberbezpieczeństwa oraz modernizacji starszych systemów. DataArt działa w sektorach takich jak usługi finansowe, opieka zdrowotna i nauki przyrodnicze, podróże, media i rozrywka oraz handel detaliczny, a także utrzymuje partnerstwa technologiczne z platformami takimi jak AWS, Google Cloud, Microsoft Azure, Snowflake i Databricks. W 2025 roku firma ogłosiła inwestycję w wysokości 100 milionów dolarów na trzy lata w swoje możliwości w zakresie danych i AI, a w 2026 roku uruchomiła Artisyn, model operacyjny z wbudowaną sztuczną inteligencją, zaprojektowany do włączania agentów AI, wielokrotnego użytku przyspieszaczy, zarządzania, bezpieczeństwa i zgodności w rozwój oprogramowania korporacyjnego.

Spędziłeś prawie dwie dekady w DataArt, awansując od architekta oprogramowania i architekta rozwiązań do Chief Innovation Officer, a teraz CTO. Jak ta droga ukształtowała Twoje podejście do odróżniania naprawdę przełomowych technologii od cykli hype i jak wpływa na Twoją „skeptyczną optymistyczną” postawę wobec AI dzisiaj?

Widzieliśmy wiele różnych fal na przestrzeni lat, w tym wzrost popularności chmury i urządzeń mobilnych, różne generacje AI, automatyzację, DevOps i SRE, a ja programowałem, projektowałem i doradzałem naszym klientom w wielu z tych obszarów przez cały ten czas. Zdałem sobie sprawę, że tak, technologia pozwala zrobić prawie wszystko i jest dość potężna, ale diabeł tkwi w szczegółach i trzeba wiedzieć, co się robi, aby miało to sens i działało.

Zauważyłem, że środowiska chmurowe stają się coraz droższe, modele AI nie działają tak, jak się tego spodziewasz, oraz słabo wdrożone próby automatyzacji cykli wydawniczych. Doświadczyłem wpływu zarówno dobrych, jak i złych decyzji, więc gdy pojawia się coś nowego i czytasz wszystkie ogłoszenia, obietnice i hype, wracam do tej samej zasady: prawie wszystko jest możliwe dzięki technologii, ale musisz wiedzieć, co robisz.

Zdobywasz solidne pojęcie o technologii poprzez badania i rozwój oraz, co ważniejsze, poprzez projekty w rzeczywistym środowisku, ponieważ tak uczysz się, co jest możliwe, czego nie ma i gdzie mogą pojawić się problemy. Czerpiesz te lekcje z każdego zaangażowania, rozmawiasz z kolegami, innymi architektami i analitykami oraz starasz się zrozumieć, czy istnieją wzorce i czy możesz stworzyć jakiś system wokół nich. Z czasem staje się to wskazówką, a potem sprawdzasz, czy decyzje, które uważałeś za dobre, naprawdę przynoszą pozytywne rezultaty.

To właśnie z tego wynika sceptyczna optymistyczna postawa. Niezależnie od obietnic technologii, nadal musisz wiedzieć, co robisz, a ta wiedza pochodzi z doświadczenia, współpracy i ciągłego dążenia do nauki, doskonalenia się i tworzenia pewnego systemu za hype’em.

Sztuczna inteligencja w przedsiębiorstwach wydaje się przechodzić od fazy zachęcania do eksperymentów do określania, które eksperymenty naprawdę zasługują na skalowanie. Jakie sygnały wskazują, że przypadek użycia AI jest gotowy do szerszego wdrożenia, i jakie są ostrzeżenia, że firma skaluje zbyt wcześnie?

Używam dwóch metod, aby zrozumieć, czy możemy coś skalować, czy też musimy zrobić coś innego: krzywej adopcji i krzywej uczenia się.

Aby zrozumieć, czy przypadek użycia AI działa, musisz dać mu trochę czasu i zrozumieć, jaką wartość przynosi oraz jak wygląda ścieżka użytkownika, ponieważ wtedy możesz dostrzec wzloty i upadki, a nie tylko natychmiastowy efekt „wow” w konkretnym zespole lub procesie. Musisz zobaczyć, co dzieje się z tymi samymi osobami po kilku tygodniach. Czy nadal z niego korzystają? Czy nadal są zadowoleni z tego przypadku użycia, tej automatyzacji lub tej umiejętności AI, którą stworzyli, czy był to jedynie krótkotrwały impuls, którego naprawdę nie należy skalować?

Niektóre z tych rzeczy można zweryfikować dopiero z czasem. Zawsze będą pierwsi pionierzy, zazwyczaj najbardziej technicznie zaawansowani ludzie i ci, którzy są bardzo ciekawi, a potem trzeba spróbować z innymi segmentami, z tymi, którzy podążają za wczesnymi przyjmującymi, a następnie wczesną większością. Gdy udowodni to tam, tak, możesz zacząć skalować to i rozszerzać ten przypadek użycia na inne działy.

Każde większe wydanie modelu może wywierać presję w organizacji, aby natychmiast udostępnić pracownikom najnowsze możliwości. Jak liderzy technologiczni powinni ocenić, czy nowy model stanowi znaczącą poprawę, a nie tylko generuje kolejną falę eksperymentów i kosztów?

Oto moja sceptyczna optymistyczna perspektywa. Załóżmy, że masz już model w miejscu i kilka tysięcy osób codziennie korzysta z AI, przy dostępnych różnych modelach i narzędziach. Gdy pojawi się nowy model, z powodu szumu i naturalnej ciekawości, możesz się spodziewać, że każdy będzie chciał go wypróbować, co jest dobre, ale takie eksperymenty nie muszą być ukierunkowane na konkretne wyniki, a czasem nie będziesz w stanie zmierzyć różnicy.

W skali to ma znaczenie. Nie chodzi tylko o jedną czy dwie osoby, które próbują sprawdzić, jak nowy model wypada w porównaniu ze starszym. Może to być tysiące osób poświęcających czas na eksperymenty, gdy w konkretnym przypadku użycia wynik nie jest aż tak istotny. Jednocześnie, jeśli coś działa naprawdę dobrze, wiedza o tym, co działa w twojej organizacji, może nie być jasno wyjaśniona ani widoczna dla wszystkich.

Dlatego pierwsza grupa oceniająca nowy model nie powinna obejmować całej organizacji. Powinna to być grupa R&D współpracująca blisko z odpowiednimi zespołami, a także z działami prawnym i bezpieczeństwa. Oceniamy model kompleksowo, przeprowadzamy szybką ocenę, a następnie przedstawiamy go szerszej publiczności z komentarzami i wskazówkami dotyczącymi bezpieczeństwa, zgodności i technologii. Ponieważ nowe modele i duże aktualizacje pojawiają się nieustannie, musisz mieć ten model i nastawienie w miejscu. To naprawdę nie jest jednorazowe ani jednorazowe działanie.

DataArt stworzyło międzydziałowy zespół „AI SWAT”, obejmujący technologię, prawo, zgodność, InfoSec i inne zespoły. Jak ten zespół działa w praktyce i jakie rodzaje ryzyk lub pytań należy rozwiązać, zanim nowe narzędzie AI zostanie zatwierdzone do szerszego użycia?

Od momentu powstania, myślę, że ustalamy różne cele dla tej grupy mniej więcej co cztery lub pięć miesięcy. Zmieniamy priorytet, cel, a czasem misję, i wiele z tych celów dotyczy AI. Może to być podnoszenie kwalifikacji pracowników, wprowadzanie na rynek i nowe możliwości, partnerstwa lub szersze udostępnianie AI w organizacji i w całym ADLC.

Konkretne tematy ewoluują z czasem i uważam, że to zdrowe, ponieważ stale musisz przeglądać własną strategię, weryfikować założenia i rozumieć, czy trzeba zmienić kierunek oraz jaki powinien być kolejny temat dla zespołu.

Grupa obejmuje przedstawicieli różnych działów, a jednym z jej celów jest po prostu utrzymanie wszystkich w poinformowaniu. Gdy pojawi się nowe ogłoszenie, pytanie lub okazja, ktoś może przedstawić ten temat na jednym z naszych regularnych spotkań. Nawet jeśli wydaje się to pytaniem technologicznym istotnym tylko dla wąskiego zespołu, obecnie takie tematy mogą mieć wpływ na wiele części organizacji.

Dlatego, gdy oceniamy nową współpracę, narzędzie lub akcelerator, omawiamy to otwarcie, aby każdy rozumiał, dokąd zmierzają sprawy i miał możliwość zadawania pytań lub zapewnienia nadzoru. W przypadku nowego narzędzia AI, technologia nie może ocenić go w izolacji. Bezpieczeństwo, prawo i zgodność muszą również zrozumieć, jak przetwarza dane firmy lub klienta, jakie obowiązują ograniczenia i czy może być używane bezpiecznie w skali.

Czasami zespół AI SWAT pracuje również nad konkretnymi programami, takimi jak podnoszenie kwalifikacji, gdzie ustalamy cele, opracowujemy plany działania i decydujemy, jak różne grupy będą wprowadzane. Tak naprawdę tak to działa: informowanie ludzi, współpraca nad konkretnymi programami i zapewnianie zarządowi wglądu w to, co dzieje się z AI w całej firmie.

Widzisz bardzo różne podejścia do rozwoju oprogramowania wspomaganego AI, niektóre organizacje aktywnie skalują rozwój agentowy, podczas gdy inne nadal zakazują kodu generowanego przez AI. Co wyjaśnia tę podział i co musi się zmienić, zanim bardziej ostrożne pod względem ryzyka przedsiębiorstwa poczują się komfortowo z AI odgrywającą większą rolę w inżynierii oprogramowania?

Prawdopodobnie różnicę między tymi, którzy mówią nie, a tymi, którzy mówią tak, napędza ich apetyt na ryzyko i podejście do niepewności oraz niejasności. To, co pomaga obu typom organizacji, to ciągła edukacja, eksperymentowanie i ocena. Nawet wśród wielu organizacji, z którymi współpracujemy i które przyjmują AI oraz wprowadzają ją wszędzie, wciąż istnieją wyzwania związane z pomiarami wyników i wpływu. Szczerze mówiąc, pytanie o to, jak mierzyć wpływ AI i jak oceniać wydajność zespołu, czasami pojawia się nagle, jakby nikt wcześniej naprawdę o tym nie myślał.

Gdy zaczynasz bardziej kompleksowo oceniać inicjatywę AI, zaczynasz rozumieć jej wpływ i rzeczywistą wartość, co prowadzi do lepszych decyzji dotyczących tego, gdzie technologia ma sens. Dla firm, które odmawiają AI, nadal potrzebny jest ciągły proces przeglądu możliwości technologii i jej aktualnego stanu. Nie chcesz, aby decyzja podjęta trzy lata temu pozostała polityką firmy tylko dlatego, że nikt nie zweryfikował założeń stojących za nią.

Agentic AI coraz bardziej ułatwia poszczególnym zespołom tworzenie własnych agentów, co może skutkować wieloma agentami wykonującymi prawie identyczne zadania. W którym momencie eksperymentowanie przekształca się w rozrost agentów i jaka warstwa zarządzania jest potrzebna do kontrolowania własności, uprawnień, duplikacji i zarządzania cyklem życia?

Kiedy obserwujemy typowy scenariusz, w którym licencja na AI jest przydzielana każdemu programiście, a eksperymentowanie staje się nieukierunkowane, każdy zaczyna tworzyć własne rozwiązania i pracować po swojemu. Zazwyczaj prowadzi to do słabo działających zespołów, niespełnionych oczekiwań, obniżonej jakości i rosnących kosztów. Sednem sprawy jest to, że nie spełnia to oczekiwań, jakość jest niska, a koszty rosną. Aby to złagodzić, potrzebny jest wysiłek zespołowy będący częścią szerszej inicjatywy działu lub organizacji, i właśnie tutaj wchodzi zarządzanie.

Na poziomie projektu można uzgodnić bazę wiedzy i kontekst oraz przypadki użycia, w których zaczynacie korzystać z AI. Następnie tworzysz umiejętności i agentów będących częścią przepływu pracy deweloperskiej, które każdy może ponownie wykorzystać, dzięki czemu gromadzisz wiedzę i najlepsze praktyki zamiast odtwarzać je za każdym razem. Ten wysiłek na poziomie projektu powinien być koordynowany przez coś w rodzaju rady architektury korporacyjnej, grupy technologicznej, CTO lub zespołu odpowiedzialnego za przyjęcie AI. Chcesz ponownie wykorzystywać dobrze działających agentów, zapewnić solidność procesu i sprawić, by działał w całej organizacji, a nie zamieniał się w chaos i szum.

Myślę więc, że musi to być zsynchronizowany wysiłek na poziomie projektu, ewentualnie programu, a także na poziomach działu i całej organizacji.

Zużycie tokenów i koszty inferencji mogą wydawać się stosunkowo niewielkie podczas pilotażu, ale stają się znaczące, gdy systemy AI są wdrażane wśród tysięcy pracowników lub autonomicznych agentów. Jak przedsiębiorstwa powinny podchodzić do zarządzania kosztami AI i czy spodziewasz się powstania czegoś na kształt FinOps dedykowanego obciążeniom AI?

Zacznę od stwierdzenia, że prawie idealny scenariusz to sytuacja, w której koszty AI rosną, osiągają plateau, a następnie nieco spadają z czasem. Daje to możliwość prognozowania, kontrolowania wydatków, zrozumienia, na co faktycznie wydajesz na AI, oraz obserwacji rezultatów podjętych decyzji. Negatywne sytuacje pojawiają się, gdy koszty wciąż rosną i spadają, co zazwyczaj oznacza brak zrównoważenia, lub gdy koszty rosną, a potem całkowicie spadają, ponieważ przyjęcie może nie zachodzić, coś nie działa, albo ludzie korzystają z innego rozwiązania i po prostu tego nie widzisz.

FinOps istnieje, a AI FinOps również. Niektóre techniki są bardzo techniczne, inne zaś dość proste. Może to być tak podstawowe, jak wybór preferowanego modelu, aby nie zawsze polegać na najdroższym, a decyzje te stopniowo przynoszą oszczędności. Jednocześnie znajomość sposobów oszczędzania i kontrolowania kosztów to tylko połowa równania. FinOps, jak go postrzegam, to dyscyplina i metodologia, która angażuje także liderów produktów i biznesu, ponieważ trzeba określić, co mierzymy przy ocenie działań AI.

Tak, uważam, że AI FinOps to dobry temat dla odpowiednika zespołu AI SWAT, aby go omówić: ile wydajesz, ile odzyskujesz, jak to kontrolujesz i gdzie są możliwości.

Wiele firm jest proszonych o wykazanie ROI z AI, mimo że nigdy nie ustaliły wiarygodnej bazy odniesienia dotyczącej produktywności swoich zespołów przed wprowadzeniem AI. Co organizacje powinny faktycznie mierzyć, aby określić, czy AI generuje istotną wartość biznesową?

Niezależnie od twojego nastawienia do AI czy aktualnego etapu, być może już korzystasz z agentów wszędzie, a może planujesz rozpocząć użycie AI w przyszłym roku – ustanowienie bazy odniesienia jest dziś absolutnym koniecznym elementem.

Istnieje kilka klas metryk. Niektóre są subiektywne i mogą po prostu polegać na opinii twoich programistów lub pracowników, ponieważ pracujesz z ludźmi i ważne jest zrozumienie, jak postrzegają wartość AI. Bardziej obiektywne miary mogą zaczynać się od metryk mechanicznych lub syntetycznych, choć zalecałbym, aby nie przywiązywać się do nich zbyt ściśle. Mam na myśli takie rzeczy jak commity kodu czy story points. Te metryki pokazują, że praca się odbywa, ale nie odzwierciedlają rzeczywistej wartości ani wpływu.

Większe znaczenie mają metryki, które wyjaśniają, jak szybko i jak dobrze praca została dostarczona. Pomyśl o metrykach DORA, takich jak lead time czy MTTR, o tym, jak szybko możesz odzyskać po awarii, jak szybko naprawić błąd w produkcji, lub jak te miary zmieniają się w czasie. Jedna liczba w danym momencie nie pokazuje trajektorii. Jeden z naszych architektów wspomniał niedawno, że w rozwoju oprogramowania dobrą metryką może być także wiarygodność szacunków w miarę rosnącej adopcji AI, ponieważ mówi to coś o trwałości tych działań i o rzeczywistej wydajności zespołów. Musisz także śledzić koszty, ponieważ jeśli mówisz tylko o korzyściach, nie rozumiejąc, ile kosztuje ich osiągnięcie, nie masz pełnego obrazu.

Poza rozwojem oprogramowania myślę o tym w podobny sposób. W każdym przepływie pracy lub procesie istnieje pewna jednostka pracy i określenie „zrobione”. Niezależnie od tego, czy przetwarzasz roszczenia, przeglądasz dokumentację, czy obsługujesz zgłoszenia klientów, określ, co dostarczasz, a następnie zmierz, ile to zajęło przed AI, jak szybko i jak dobrze możesz to zrobić teraz oraz jakie to generuje koszty. Daje to solidny punkt wyjścia zarówno dla podstawy, jak i dla ram metryk.

DataArt wprowadza AI w całym cyklu dostarczania oprogramowania poprzez inicjatywy takie jak Artisyn. W miarę jak AI przejmuje coraz więcej zadań związanych z implementacją, testowaniem i przepływem pracy, które części inżynierii oprogramowania stają się bardziej wartościowe dla ludzi, a które umiejętności ryzykują utratę znaczenia?

Możesz skutecznie wykorzystywać AI w rozwoju tylko wtedy, gdy nadal pamiętasz, jaka jest definicja dobrego. Potrzebujesz tej wiedzy, aby prowadzić swoich agentów, przeglądać wyniki, ustalać ograniczenia i definiować zasady. Musisz rozumieć, czym jest najlepsza praktyka i jak powinna wyglądać dobra architektura, ponieważ bez tego możesz nie wiedzieć, co jest rozwijane, a wartość takiej ekspertyzy rośnie bardzo, bardzo znacząco.

Zrozumienie wzorców architektonicznych ma znaczenie, podobnie jak zrozumienie, co jest odpowiednie w danej branży, aplikacji czy klasie rozwiązania. Musisz wiedzieć, jaki rodzaj architektury jest dobry teraz i jaki będzie nadal dobry, gdy rozwiązanie będzie się skalować, ponieważ czasami ta sama architektura nie sprawdza się przez cały okres życia rozwiązania lub platformy.

Ta równowaga tego, co jest odpowiednie dla konkretnego rozwiązania, to ludzki element. To gust, rzemiosło stojące za usługami i rozwojem oprogramowania. Musisz wiedzieć, co robisz, a to wynika również ze zrozumienia klienta i branży.

Które umiejętności są mniej istotne? Trudno mi to określić, choć może jak szybko potrafisz pisać kod. Żartuję, ale kod może być teraz tworzony znacznie, znacznie szybciej, a konkretna wiedza o określonej bibliotece lub języku może być również przyswajana znacznie szybciej dzięki AI.

Widziałem, jak programiści .NET bardzo szybko przeszli na programowanie w Javie, a pięć czy dziesięć lat temu powiedziałbym, że robienie tego na dużą skalę było prawie niemożliwe. Obecnie można to zrobić. Doświadczony starszy programista może coraz częściej przeskakiwać między językami, ponieważ naprawdę liczy się ich zrozumienie technologii, architektury, najlepszych praktyk rozwiązania, SDLC i ADLC.

Jak przedsiębiorstwa przechodzą od dziesiątek projektów pilotażowych AI do systemów produkcyjnych, które mogą samodzielnie podejmować działania, gdzie ostatecznie powinna spoczywać odpowiedzialność, gdy agent AI popełni kosztowny błąd: u developera, właściciela biznesu, dostawcy modelu, zespołu zarządzającego czy w kombinacji tych podmiotów?

Podoba mi się idea współpracy bez obwiniania i wspólnej odpowiedzialności, ponieważ każdy w organizacji przyczynia się do najlepszych praktyk, ram architektonicznych i rozwiązań. Nawet jeśli jeden programista tworzy kod z AI lub bez AI, inny programista go przegląda, liderzy zespołów udzielają wskazówek, architekci dostarczają architekturę i ograniczenia, a zespół zarządzający uczestniczy w decyzjach dotyczących budżetów, terminów i wydania. Każdy jest w jakiś sposób zaangażowany.

Bardzo często, gdy coś idzie nie tak, to proces nie działa, więc w tym sensie odpowiedzialność jest współdzielona pomiędzy różne role. Jednak samo stwierdzenie, że odpowiedzialność jest współdzielona i dlatego bez winy, nie wystarczy. Wciąż musi być podzielona na konkretne obowiązki.

Programiści są odpowiedzialni za kod, który zgłaszają jako pull request i muszą rozumieć, co się w nim dzieje. Architekci są odpowiedzialni za podejmowane decyzje oraz za decyzje architektoniczne przekazywane agentom i programistom. Zespół platformy jest odpowiedzialny za niezawodność rozwiązania, niezależnie od tego, kto lub co stworzyło konkretną linię kodu.

Tak więc odpowiedzialność istnieje, ale musisz ją definiować szczegółowo według zespołu, roli i działu. Nie możesz po prostu zakończyć analizy stwierdzeniem „AI to zrobiło”. Musisz zapytać, jakie kontrole, testy lub nadzór pozwoliły, by ta awaria trafiła do produkcji.

Jeśli brak testów jednostkowych pozwolił na wypchnięcie złego kodu do produkcji, lub brak nadzoru i przeglądu doprowadził do tego, nie możesz przenieść tej odpowiedzialności na AI. Nie możesz również po prostu obwiniać dostawcy modelu lub dostawcy chmury za każdy błąd czy awarię.

Dziękujemy za wspaniały wywiad, czytelnicy, którzy chcą dowiedzieć się więcej, powinni odwiedzić DataArt.