Yuri Gubin, CTO på DataArt – Intervjuserie

Yuri Gubin, CTO på DataArt är en veteran inom teknikledning och mjukvaruarkitektur som har tillbringat mer än 18 år på DataArt och har avancerat genom roller som spänner över mjukvaruarkitektur, lösningsarkitektur, molnteknik, innovation och ledarskap innan han blev teknisk chef i mars 2026. Hans arbete har fokuserat på att lösa komplexa tekniska utmaningar inom branscher som finansiella tjänster, sjukvård, resor och IoT, med särskild expertis inom molnberäkning, AI, dataplattformar och företagsprogramvaruarkitektur. Innan han blev teknisk chef tjänstgjorde Gubin i mer än fem år som DataArts chef för innovation och har varit medlem i företagets Board of Partners sedan 2021. Han är också en professionell medlem i Forbes Technology Council, där han deltar i AI‑ och Cloud Computing‑expertgrupperna, och han fungerar som teknisk rådgivare för Girls Who Code, där han ger råd om arkitektur, dataskydd, plattformsstyrning och teknikpolicy. DataArt listar honom för närvarande som sin tekniska chef med bas i New York.

DataArt är ett globalt mjukvaruutvecklings- och data‑ och AI‑transformationsföretag som grundades i New York 1997. Företaget har vuxit till mer än 6 000 teknologiprofessionella som verkar i över 20 länder och arbetar med mer än 400 kunder, och erbjuder tjänster inom områden som artificiell intelligens och maskininlärning, data och analys, molntransformation, skräddarsydd mjukvaruutveckling, cybersäkerhet och modernisering av legacy‑system. DataArt arbetar över sektorer som finansiella tjänster, sjukvård och livsvetenskaper, resor, media och underhållning samt detaljhandel, och upprätthåller tekniska partnerskap med plattformar inklusive AWS, Google Cloud, Microsoft Azure, Snowflake och Databricks. År 2025 meddelade företaget en $100 million, treårig investering i sina data‑ och AI‑kapaciteter, följt 2026 av lanseringen av Artisyn, en AI‑driven operativ modell avsedd att integrera AI‑agenter, återanvändbara acceleratorer, styrning, säkerhet och efterlevnad i företagsprogramvaruutveckling.

Du har tillbringat nästan två decennier på DataArt, och gått från mjukvaruarkitekt och lösningsarkitekt till chef för innovation och nu CTO. Hur har den resan format ditt sätt att skilja verkligt transformerande teknologier från hype‑cykler, och hur påverkar den ditt \”skeptiska optimism\” gentemot AI idag?

Vi har sett många olika vågor genom åren, inklusive framväxten av moln och mobil, olika generationer av AI, automation, DevOps och SRE, och jag har kodat, arkitekturerat och rådgivit våra kunder om många av dessa ämnen under den tiden. Vad jag insåg är att, ja, du kan göra nästan vad som helst med teknik, och teknik är ganska kraftfull, men djävulen sitter i detaljerna och du måste veta vad du gör för att det ska vara meningsfullt och fungera.

Jag har sett molnmiljöer bli allt dyrare, AI‑modeller som inte presterar som du tror de kommer göra, och dåligt implementerade försök att automatisera release‑cykler. Jag har sett effekterna av både goda och dåliga beslut, så när något nytt dyker upp och du läser alla tillkännagivanden, löften och hype, återgår jag till samma premiss: nästan vad som helst är möjligt med teknik, men du behöver veta vad du gör.

Du får en god förståelse för en teknik genom R&D och, viktigast av allt, genom verkliga projekt, eftersom det är så du lär dig vad som är möjligt, vad som inte är det och var saker kan gå fel. Du tar med dig dessa lärdomar från varje uppdrag, pratar med dina kollegor, andra arkitekter och analytiker, och försöker förstå om det finns mönster och om du kan skapa någon form av system kring dem. Så småningom blir det vägledning, och sedan ser du om de beslut du trodde var bra verkligen ger bra resultat.

Det är där den skeptiska optimismen kommer ifrån. Oavsett vad tekniken lovar, måste du fortfarande veta vad du gör, och den kunskapen kommer från erfarenhet, samarbete och ett kontinuerligt arbete med att lära sig, bli bättre och skapa någon form av system bakom hypen.

Enterprise AI verkar gå från en fas av att uppmuntra experiment till att avgöra vilka experiment som faktiskt förtjänar att skalas upp. Vilka signaler visar dig att ett AI‑use‑case är redo för bredare utrullning, och vilka varningssignaler indikerar att ett företag skalar för tidigt?

Jag använder två metoder för att förstå om vi kan skala något eller om vi behöver göra något annat: adoptionskurvan och inlärningskurvan.

För att förstå om ett AI‑use‑case fungerar måste du ge det tid och förstå vilket värde det tillför och hur användarresan ser ut, för då kan du se upp- och nedgångar istället för bara den omedelbara \”wow\”-effekten i ett specifikt team eller arbetsflöde. Du måste se vad som händer med samma personer några veckor senare. Använder de det fortfarande? Är de fortfarande nöjda med det use‑case, den automatisering eller den AI‑funktion de skapade, eller var det bara en kortvarig blinkning som egentligen inte bör skalas?

Vissa av dessa saker kan bara valideras över tid. Det kommer alltid att finnas de första pionjärerna, oftast de mest tekniskt kunniga personerna och de som är väldigt nyfikna, och sedan måste du prova det med andra segment, med dem som följer de tidiga adoptörerna och sedan den tidiga majoriteten. När det har bevisat sig där, ja, kan du börja skala upp det och expandera det användningsfallet till andra avdelningar.

Varje större modellrelease kan skapa tryck inom en organisation att omedelbart ge anställda tillgång till de senaste funktionerna. Hur bör teknikledare utvärdera om en ny modell innebär en meningsfull förbättring snarare än att bara generera en ny våg av experimentering och kostnad?

Här kommer min skeptiska optimism igen. Anta att du redan har en modell på plats och flera tusen personer använder AI dagligen, med olika modeller och verktyg redan tillgängliga. När en ny modell släpps, på grund av hypen och den naturliga nyfikenheten, kan du förvänta dig att alla vill experimentera med den, vilket är bra, men den experimenteringen kanske inte nödvändigtvis är styrd eller inriktad på några specifika resultat, och ibland kommer du inte ens kunna mäta skillnaden.

I skala är det viktigt. Det handlar inte bara om en eller två personer som testar för att se hur den nya modellen presterar jämfört med den gamla. Det kan vara tusentals personer som spenderar tid på experiment när utfallet för ett specifikt användningsfall kanske inte är så betydelsefullt. Samtidigt, om något fungerar riktigt bra, kan lärdomarna om vad som fungerar inom din organisation vara otydliga eller osynliga för alla.

Det är därför den första gruppen som utvärderar en ny modell inte bör vara hela organisationen. Det bör vara en R&D‑grupp som arbetar nära de relevanta teamen, samt juridik och säkerhet. Vi utvärderar modellen heltäckande, gör en snabb bedömning och presenterar den sedan för en bredare publik med kommentarer och vägledning kring säkerhet, regelefterlevnad och teknik. Med nya modeller och stora uppdateringar som ständigt anländer, måste du ha denna modell och detta tankesätt på plats. Det är verkligen ingen engångs‑ eller tillfällig övning.

DataArt har skapat ett tvärfunktionellt “AI SWAT”-team som involverar teknik, juridik, regelefterlevnad, InfoSec och andra team. Hur fungerar den här gruppen i praktiken, och vilka typer av risker eller frågor måste lösas innan ett nytt AI‑verktyg godkänns för bredare användning?

Sedan starten tror jag att vi har satt olika mål för den här gruppen ungefär var fjärde eller femte månad. Vi ändrar prioriteringen, målet och ibland uppdraget, och många av dessa mål handlar om AI. Det kan vara att höja kompetensen i arbetsstyrkan, gå‑till‑marknad och nya funktioner, partnerskap, eller att möjliggöra AI i större omfattning inom organisationen och över ADLC.

De konkreta ämnena utvecklas över tid, och jag tycker att det är sunt eftersom du ständigt måste ompröva din egen strategi, validera dina antaganden och förstå om du behöver svänga om och vad nästa tema för teamet bör vara.

Gruppen består av representanter från olika avdelningar, och ett av dess syften är helt enkelt att hålla alla informerade. När det finns ett nytt tillkännagivande, en fråga eller möjlighet, kan någon ta upp ämnet på ett av våra regelbundna möten. Även om det ser ut som en teknisk fråga som bara är relevant för ett smalt team, kan dessa ämnen idag ha konsekvenser för många delar av organisationen.

Det är därför, när vi utvärderar ett nytt partnerskap, verktyg eller accelerator, diskuterar vi det öppet så att alla förstår vart saker och ting är på väg och får möjlighet att ställa frågor eller ge tillsyn. För ett nytt AI‑verktyg kan teknik inte utvärdera det i isolation. Säkerhet, juridik och regelefterlevnad måste också förstå hur det hanterar företagets eller kundens data, vilka begränsningar som gäller och om det kan användas säkert i skala.

Ibland arbetar AI SWAT‑teamet också med specifika program, såsom kompetensutveckling, där vi sätter mål, kartlägger färdplaner och bestämmer hur olika grupper ska onboardas. Så fungerar det egentligen: hålla folk informerade, samarbeta i specifika program och ge styrelsen insyn i vad som händer med AI i hela företaget.

Du ser mycket olika attityder till AI‑assisterad mjukvaruutveckling, där vissa organisationer aktivt skalar agentbaserad utveckling medan andra fortfarande förbjuder AI‑genererad kod. Vad förklarar denna klyfta, och vad måste förändras innan mer riskmedvetna företag blir bekväma med att AI spelar en större roll i mjukvaruingenjörskonsten?

Troligen är det som driver skillnaden mellan dem som säger nej och dem som säger ja deras riskaptit och deras inställning till tvetydighet och osäkerhet. Vad som hjälper båda typerna av organisationer är kontinuerlig utbildning, experimentering och utvärdering. Även bland många organisationer vi arbetar med som omfamnar AI och integrerar den överallt, finns det fortfarande utmaningar kring att mäta resultat och påverkan. För att vara ärlig kommer frågan om hur du mäter AI:s påverkan och hur du utvärderar ett teams prestation ibland nästan ur ingenstans, som om ingen tidigare riktigt hade tänkt på det.

När du börjar utvärdera ett AI-initiativ mer omfattande inser du vilken påverkan och vilket värde det faktiskt ger dig, vilket leder till bättre beslut om var tekniken är meningsfull. För företag som säger nej till AI måste det fortfarande finnas en kontinuerlig process för att granska vad tekniken kan göra och var den står idag. Du vill inte att ett beslut som fattades för tre år sedan ska förbli företagspolicy bara för att ingen har omprövat de underliggande antagandena.

Agentisk AI gör det allt lättare för enskilda team att skapa sina egna agenter, vilket potentiellt kan leda till flera agenter som utför nästan identiska uppgifter. Vid vilken punkt blir experimenteringen en agentöverflöd, och vilken typ av styrningsnivå behövs för att hantera ägande, behörigheter, duplicering och livscykelhantering?

När vi ser ett typiskt scenario där en AI-licens ges till varje utvecklare och experimenteringen blir ohållbar, börjar alla skapa sina egna saker och arbeta på sitt eget sätt. Vanligtvis leder det till underpresterande team, missade förväntningar, eftersläpande kvalitet och ökande kostnader. Slutsatsen är att det inte gör vad alla förväntar sig, kvaliteten är dålig och det blir dyrt. För att motverka detta måste det vara ett teamarbete som är en del av en bredare avdelnings- eller organisationsinsats, och det är där styrning kommer in.

På projektnivå kan ni komma överens om kunskapsbasen och kontexten, samt de användningsfall där ni börjar använda AI. Därefter skapar ni färdigheter och agenter som är en del av utvecklingsarbetsflödet och som alla kan återanvända, så att ni samlar kunskap och bästa praxis istället för att återskapa dem varje gång. Detta projektbaserade arbete bör sedan styras av exempelvis en enterprise‑arkitekturgrupp, en teknikgrupp, CTO:n eller ett team som ansvarar för AI‑adoption. Ni vill återanvända agenter som fungerar bra, säkerställa att processen är robust och få den att fungera i hela organisationen snarare än att förvandlas till kaos och brus.

Så jag tror att det måste vara en samordnad insats på projektnivå, eventuellt programnivå, och sedan även på avdelnings- och organisationsnivå.

Tokenförbrukning och inferenskostnader kan verka relativt små under en pilot, men blir betydande när AI‑system distribueras till tusentals anställda eller autonoma agenter. Hur bör företag tänka kring AI‑kostnadshantering, och förväntar du dig att något liknande FinOps uppstår specifikt för AI‑arbetsbelastningar?

Jag börjar med att säga att ett nästan idealiskt scenario är när AI‑kostnaderna stiger, når en platå och sedan börjar minska något över tid. Det visar att du kan prognostisera, kontrollera kostnaderna, förstå vad du faktiskt spenderar på AI och se resultaten av de beslut du fattar. De dåliga situationerna är när kostnaderna fluktuerar upp och ner, vilket ofta betyder att något inte är hållbart, eller när kostnaderna stiger och sedan faller helt eftersom adoptionen kanske inte sker, något inte fungerar, eller folk använder något annat och du helt enkelt inte ser det.

FinOps är alltså ett begrepp, och AI‑FinOps är också ett. Vissa tekniker är mycket tekniska, medan andra är ganska enkla. Det kan vara så grundläggande som att välja den föredragna modellen så att du inte alltid förlitar dig på den dyraste, och steg för steg börjar dessa beslut spara pengar. Samtidigt är kunskapen om hur man sparar och kontrollerar kostnader bara hälften av ekvationen. FinOps, så som jag ser det, är en disciplin och metodik som också involverar produkt‑ och affärsledare eftersom du måste definiera vad du mäter när du utvärderar AI‑insatser.

Ja, jag tror att AI‑FinOps är ett bra ämne för motsvarigheten till ett AI‑SWAT‑team att diskutera: hur mycket du spenderar, hur mycket du får tillbaka, hur du kontrollerar det och var möjligheterna finns.

Många företag blir ombedda att visa ROI från AI även om de aldrig etablerade en pålitlig baslinje för hur produktiva deras team var innan AI infördes. Vad bör organisationer faktiskt mäta om de vill avgöra om AI skapar meningsfullt affärsvärde?

Oavsett din inställning till AI eller var du befinner dig just nu, kanske du redan använder agenter överallt eller kanske du tänker att du nästa år ska börja använda AI; att etablera en baslinje är absolut ett måste i dagens läge.

Det finns flera klasser av mätvärden. Vissa är subjektiva, och kan helt enkelt vara återkoppling från dina utvecklare eller anställda eftersom du arbetar med människor och det är viktigt att förstå hur de uppfattar AI:s värde. Mer objektiva mått kan börja med mekaniska eller syntetiska mätvärden, men jag uppmanar alla att inte binda sig för hårt till dem. Jag menar saker som kod‑commits eller story points. Dessa mätvärden visar att arbete har pågått, men de visar inte riktigt värdet eller påverkan.

Det som gör störst skillnad är metrik som förklarar hur snabbt eller hur väl arbetet levererades. Tänk på DORA-metrik som ledtid eller MTTR, hur snabbt du kan återhämta dig från ett fel, hur snabbt du kan åtgärda en bugg i produktion, eller hur dessa mått förändras över tid. En siffra vid ett tillfälle visar inte utvecklingskurvan. En av våra arkitekter nämnde nyligen att, inom mjukvaruutveckling, kan en bra metrik även vara hur pålitliga uppskattningarna är när AI‑adoptionen ökar, eftersom det säger något om hållbarheten i dessa insatser och hur produktiva team egentligen är. Du måste också hålla koll på kostnaderna, för om du bara pratar om fördelar utan att förstå vad det kostar att uppnå dem, har du inte hela bilden.

Utanför mjukvaruutveckling tänker jag på det på liknande sätt. I varje arbetsflöde eller process finns det någon arbetsenhet och någon definition av färdig. Oavsett om du behandlar anspråk, granskar dokument eller hanterar kundförfrågningar, definiera vad du levererar och mät sedan hur lång tid det tog innan AI, hur snabbt och hur väl du kan göra det nu, samt vad det kostar. Det ger dig en bra utgångspunkt både för baslinjen och för ramverket av metrik.

DataArt har integrerat AI genom hela mjukvaruleveransens livscykel via initiativ som Artisyn. När AI tar över fler implementerings-, test- och arbetsflödesuppgifter, vilka delar av mjukvaruingenjörskonsten blir mer värdefulla för människor, och vilka färdigheter riskerar att bli mindre viktiga?

Du kan bara använda AI effektivt i utveckling om du fortfarande kommer ihåg vad definitionen av bra är. Du behöver den expertisen för att vägleda dina agenter, granska resultatet, sätta begränsningar och definiera reglerna. Du måste förstå vad bästa praxis är och hur en bra arkitektur bör se ut, för utan det kan du missa vad som utvecklas, och värdet av den här typen av expertis ökar mycket, mycket betydligt.

Att förstå arkitekturmönster är viktigt, likaså att förstå vad som är lämpligt i en viss bransch, applikation eller lösningsklass. Du måste veta vilken typ av arkitektur som är bra just nu och vilken som fortfarande kommer att vara bra när lösningen skalar, eftersom samma arkitektur ibland inte fungerar under hela livscykeln för en lösning eller plattform.

Den balansen mellan vad som är lämpligt för en specifik lösning är den mänskliga delen. Det är smaken, hantverket bakom tjänster och mjukvaruutveckling. Du måste veta vad du gör, och det kommer också från att förstå kunden och branschen.

Vilka färdigheter är mindre viktiga? Det är verkligen svårt för mig att säga, även om kanske hur snabbt du kan skriva kod. Jag skämtar, men kod kan nu skapas mycket, mycket snabbare, och specifik kunskap om ett visst bibliotek eller språk kan också läras in mycket snabbare med AI.

Jag har sett .NET‑utvecklare omskolas till Java‑utvecklare mycket snabbt, och för fem eller tio år sedan skulle jag ha sagt att det nästan var omöjligt att göra i stor skala. Nuförtiden kan du det. En stark seniorutvecklare kan i allt högre grad hoppa mellan språk eftersom det som verkligen räknas är deras förståelse för teknik, arkitektur, bästa praxis för lösningar, SDLC och ADLC.

När företag går från dussintals AI‑pilotprojekt till produktionssystem som kan agera självständigt, var bör ansvaret slutligen ligga när en AI‑agent gör ett kostsamt misstag: hos utvecklaren, affärsägaren, modellleverantören, styrningsteamet eller någon kombination av dem?

Jag gillar idén om skuldfria samarbeten och delat ansvar eftersom alla i organisationen bidrar till bästa praxis, arkitekturramar och lösningar. Även om en utvecklare skapar kod med AI eller utan AI, granskar en annan utvecklare den, teamledare ger vägledning, arkitekter levererar arkitekturen och begränsningarna, och styrningsteamet bidrar till beslut om budgetar, tidplaner och releaser. Alla är på något sätt involverade.

Mycket ofta, när något går fel, är det processen som inte fungerar, så i den meningen är ansvaret delat över olika roller. Men om du bara säger att ansvaret är delat och därför skuldfria, räcker det inte. Det måste fortfarande brytas ner i specifika ansvarsområden.

Utvecklare är ansvariga för den kod de skickar in som en pull‑request, och de måste förstå vad som händer där. Arkitekter är ansvariga för de beslut de fattar och för de arkitekturbeslut som ges till agenter och utvecklare. Plattformsteamet är ansvarigt för lösningens tillförlitlighet oavsett vem eller vad som skapade en viss kodrad.

Ansvarsområdet finns, men du måste definiera det granulariskt efter team, roll och avdelning. Det du inte kan göra är att stoppa analysen vid “AI gjorde detta.” Du måste fråga vilka kontroller, tester eller översyn som tillät att felet nådde produktion.

Om brist på enhetstester gjorde att dålig kod trycktes in i produktion, eller brist på översyn och granskning tillät det, kan du inte skjuta över ansvaret på AI. Du kan inte heller bara skylla på modellleverantören eller molnleverantören för varje bugg eller driftstörning.

Tack för den fantastiska intervjun, läsare som vill lära sig mer bör besöka DataArt.