Yuri Gubin, CTO i DataArt – Intervjuserie

Yuri Gubin, CTO i DataArt er en erfaren teknologileder og programvarearkitekt som har tilbrakt mer enn 18 år i DataArt, og har utviklet seg gjennom roller som omfatter programvarearkitektur, løsningsarkitektur, skyteknologi, innovasjon og lederansvar før han ble Chief Technology Officer i mars 2026. Arbeidet hans har fokusert på å løse komplekse teknologiske utfordringer på tvers av bransjer inkludert finansielle tjenester, helsevesen, reise og IoT, med særlig ekspertise innen sky‑computing, AI, dataplattformer og bedriftsprogramvarearkitektur. Før han ble CTO, tjente Gubin i mer enn fem år som DataArts Chief Innovation Officer og har vært medlem av selskapets Board of Partners siden 2021. Han er også profesjonelt medlem av Forbes Technology Council, deltar i deres ekspertgrupper for AI og sky‑computing, og fungerer som teknologirådgiver for Girls Who Code, hvor han gir råd om arkitektur, databeskyttelse, plattformstyring og teknologipolitikk. DataArt oppgir ham nå som Chief Technology Officer med base i New York.

DataArt er et globalt programvare‑ingeniør- og data‑ og AI‑transformasjonsfirma grunnlagt i New York i 1997. Selskapet har vokst til mer enn 6 000 teknologiprofesjonelle som opererer i over 20 land og jobber med mer enn 400 kunder, og leverer tjenester innen områder som kunstig intelligens og maskinlæring, data og analyse, skytransformasjon, skreddersydd programvareutvikling, cybersikkerhet og modernisering av eldre systemer. DataArt opererer på tvers av sektorer som finansielle tjenester, helse og livsvitenskap, reise, media og underholdning, samt detaljhandel, og opprettholder teknologipartnerskap med plattformer som AWS, Google Cloud, Microsoft Azure, Snowflake og Databricks. I 2025 kunngjorde selskapet en investering på $100 million over tre år i sine data‑ og AI‑kapasiteter, etterfulgt i 2026 av lanseringen av Artisyn, en AI‑drevet driftsmodell designet for å integrere AI‑agenter, gjenbrukbare akseleratorer, styring, sikkerhet og samsvar i bedriftsprogramvareutvikling.

Du har tilbrakt nesten to tiår i DataArt, og har gått fra programvarearkitekt og løsningsarkitekt til Chief Innovation Officer og nå CTO. Hvordan har den reisen påvirket måten du skiller ekte transformative teknologier fra hype‑sykluser, og hvordan informerer den ditt «skeptisk optimisme» overfor AI i dag?

Vi har sett mange ulike bølger gjennom årene, inkludert fremveksten av sky og mobil, forskjellige generasjoner av AI, automatisering, DevOps og SRE, og jeg har kodet, arkitektet og rådgitt våre kunder om mange av disse temaene i løpet av den tiden. Det jeg innså er at, ja, du kan gjøre nesten alt med teknologi, og teknologi er ganske kraftig, men djevelen ligger i detaljene, og du må vite hva du gjør for at det skal gi mening og fungere.

Jeg har sett sky‑miljøer bli stadig dyrere, AI‑modeller som ikke presterer slik du tror de vil, og dårlig implementerte forsøk på å automatisere utgivelsessykluser. Jeg har sett virkningen av både gode og dårlige beslutninger, så når noe nytt dukker opp og du leser alle kunngjøringer, løfter og hype, går jeg tilbake til samme premiss: nesten alt er mulig med teknologi, men du må vite hva du gjør.

Du får en god forståelse av en teknologi gjennom FoU og, viktigst, gjennom virkelige prosjekter, fordi det er slik du lærer hva som er mulig, hva som ikke er det, og hvor ting kan gå galt. Du tar med deg disse lærdommene fra hvert oppdrag, snakker med kolleger, andre arkitekter og analytikere, og prøver å forstå om det finnes mønstre og om du kan lage et slags system rundt dem. Til slutt blir dette veiledning, og så ser du om beslutningene du trodde var gode faktisk gir gode resultater.

Det er her den skeptiske optimismen kommer fra. Uansett hva teknologien lover, må du fortsatt vite hva du gjør, og den kunnskapen kommer fra erfaring, samarbeid og en kontinuerlig innsats for å lære, bli bedre og skape et slags system bak hype.

Enterprise AI ser ut til å gå fra en fase med å oppmuntre til eksperimentering til å bestemme hvilke eksperimenter som faktisk fortjener å skaleres. Hvilke signaler forteller deg at et AI‑brukstilfelle er klart for bredere utrulling, og hva er advarselstegnene på at et selskap skalerer for tidlig?

Jeg bruker to metoder for å forstå om vi kan skalere noe eller om vi må gjøre noe annet: adopsjonskurven og læringskurven.

For å forstå om et AI‑brukstilfelle fungerer, må du gi det tid og forstå hvilken verdi det gir og hvordan brukerreisen ser ut, fordi da kan du se opp- og nedturer i stedet for bare den umiddelbare «wow»-effekten i et bestemt team eller arbeidsflyt. Du må se hva som skjer med de samme personene noen uker senere. Bruker de det fortsatt? Er de fortsatt fornøyde med det brukstilfellet, den automatiseringen eller den AI‑ferdigheten de har laget, eller var det bare en kortvarig blip som egentlig ikke bør skaleres?

Noen av disse tingene kan kun valideres over tid. Det vil alltid være de første pionerene, vanligvis de mest teknisk kyndige og de som er svært nysgjerrige, og så må du prøve det med andre segmenter, med de som følger de tidlige adoptererne og deretter den tidlige majoriteten. Når det har bevist seg der, ja, kan du begynne å skalere det og utvide det brukstilfellet til andre avdelinger.

Hver større modellutgivelse kan skape press i en organisasjon om umiddelbart å gi ansatte tilgang til de nyeste funksjonene. Hvordan bør teknologiledere vurdere om en ny modell representerer en meningsfull forbedring snarere enn bare å generere en ny bølge av eksperimentering og kostnader?

Her er min skeptiske optimisme igjen. Anta at du allerede har en modell på plass og flere tusen personer som bruker AI daglig, med ulike modeller og verktøy allerede tilgjengelige. Når en ny modell kommer ut, på grunn av hypen og den naturlige nysgjerrigheten, kan du forvente at alle vil eksperimentere med den, noe som er bra, men den eksperimenteringen er kanskje ikke nødvendigvis styrt eller rettet mot spesifikke resultater, og noen ganger vil du ikke engang kunne måle forskjellen.

I skala betyr det noe. Det er ikke bare én eller to personer som prøver seg frem for å se hvordan den nye modellen presterer i forhold til den gamle. Det kan være tusenvis av mennesker som bruker tid på eksperimentering når resultatet for et bestemt brukstilfelle kanskje ikke er så betydningsfullt. Samtidig, hvis noe fungerer veldig bra, kan læringen om hva som fungerer i organisasjonen din være lite tydelig forklart eller synlig for alle.

Derfor bør den første gruppen som evaluerer en ny modell ikke være alle i organisasjonen. Det bør være en FoU&D‑gruppe som arbeider tett med de relevante teamene, samt juridisk avdeling og sikkerhet. Vi evaluerer modellen grundig, gjør en rask vurdering, og deretter presenterer vi den for et bredere publikum med noen kommentarer og veiledning rundt sikkerhet, etterlevelse og teknologi. Med nye modeller og store oppdateringer som kommer kontinuerlig, må du ha denne modellen og tankesettet på plass. Det er virkelig ingen engangs‑ eller enkeltøvelse.

DataArt har opprettet en tverrfaglig «AI SWAT» som involverer teknologi, juridisk, etterlevelse, InfoSec og andre team. Hvordan fungerer denne gruppen i praksis, og hvilke typer risikoer eller spørsmål må løses før et nytt AI‑verktøy godkjennes for bredere bruk?

Siden oppstarten tror jeg vi har satt ulike mål for denne gruppen omtrent hver fjerde eller femte måned. Vi endrer prioriteringen, målet og noen ganger oppdraget, og mange av disse målene handler om AI. Det kan være oppkvalifisering av arbeidsstyrken, go‑to‑market og nye kapasiteter, partnerskap, eller å gjøre AI mer tilgjengelig i organisasjonen og på tvers av ADLC.

De konkrete temaene utvikler seg over tid, og jeg synes det er sunt fordi du kontinuerlig må revurdere din egen strategi, validere antakelsene dine, og forstå om du må endre retning og hva neste tema for teamet bør være.

Gruppen består av representanter fra ulike avdelinger, og ett av formålene er enkelt å holde alle informert. Når det er en ny kunngjøring, et spørsmål eller en mulighet, kan noen ta opp temaet på ett av våre faste møter. Selv om det kan se ut som et teknologispørsmål som kun gjelder et lite team, kan slike temaer i dag ha konsekvenser for mange deler av organisasjonen.

Derfor, når vi evaluerer et nytt partnerskap, verktøy eller akselerator, diskuterer vi det åpent slik at alle forstår hvor tingene er på vei, og får mulighet til å stille spørsmål eller gi tilsyn. For et nytt AI‑verktøy kan ikke teknologien vurdere det isolert. Sikkerhet, juridisk avdeling og etterlevelse må også forstå hvordan det håndterer selskapets eller kundens data, hvilke begrensninger som gjelder, og om det kan brukes trygt i stor skala.

Noen ganger jobber AI SWAT‑teamet også med spesifikke programmer, som oppkvalifisering, hvor vi setter mål, kartlegger veikart og bestemmer hvordan ulike grupper skal tas inn. Det er egentlig slik det fungerer: holde folk informert, samarbeide om konkrete programmer, og gi styret innsikt i hva som skjer med AI i hele selskapet.

Du ser svært ulike holdninger til AI‑assistert programvareutvikling, der noen organisasjoner aktivt skalerer agentbasert utvikling mens andre fortsatt forbyr AI‑generert kode. Hva forklarer dette skillet, og hva må endres før mer risikobevisste virksomheter blir komfortable med at AI får en større rolle i programvareingeniørfaget?

Sannsynligvis er det risikovilligheten og holdningen til tvetydighet og usikkerhet som driver forskjellen mellom de som sier nei og de som sier ja. Det som hjelper begge typer organisasjoner er kontinuerlig opplæring, eksperimentering og evaluering. Selv blant mange av organisasjonene vi samarbeider med som omfavner AI og integrerer den overalt, finnes det fortsatt utfordringer med å måle resultatet og virkningen. Ærlig talt, spørsmålet om hvordan du måler AI‑virkningen og hvordan du evaluerer et teams ytelse dukker noen ganger opp nesten fra ingensteds, som om ingen egentlig hadde tenkt på det før.

Når du begynner å evaluere et AI‑initiativ mer grundig, får du forståelse for påvirkningen og verdien det faktisk gir deg, noe som fører til bedre beslutninger om hvor teknologien er fornuftig. For selskaper som sier nei til AI, må det fortsatt finnes en kontinuerlig prosess for å gjennomgå hva teknologien kan gjøre og hvor den står i dag. Du vil ikke at en beslutning tatt for tre år siden skal forbli selskapets policy bare fordi ingen har revurdert forutsetningene bak den.

Agentisk AI gjør det stadig enklere for individuelle team å lage sine egne agenter, noe som potensielt kan føre til flere agenter som utfører nesten identiske oppgaver. På hvilket tidspunkt blir eksperimentering til en spredning av agenter, og hvilken type styringslag er nødvendig for å håndtere eierskap, tillatelser, duplisering og livssyklusadministrasjon?

Når vi ser et typisk scenario der en AI‑lisens gis til hver utvikler og eksperimenteringen blir ustyrt, begynner alle å lage sine egne løsninger og jobbe på sin egen måte. Vanligvis fører dette til underpresterende team, uoppfylte forventninger, etterlat kvaliteten og økende kostnader. Konklusjonen er at den ikke lever opp til det alle forventer, kvaliteten er dårlig, og den blir kostbar. For å dempe dette må det være en laginnsats som er en del av en bredere avdelings- eller organisasjonsinnsats, og det er her styring kommer inn.

På prosjektnivå kan du bli enige om kunnskapsbasen og konteksten, samt brukstilfellene der du begynner å bruke AI. Deretter lager du ferdigheter og agenter som er en del av utviklingsarbeidsflyten og som alle kan gjenbruke, slik at du samler kunnskap og beste praksis i stedet for å gjenskape dem hver gang. Denne prosjektbaserte innsatsen bør så koordineres av for eksempel et enterprise‑arkitekturboard, en teknologigruppe, CTO‑en eller et team som har ansvar for AI‑adopsjon. Du vil gjenbruke agenter som fungerer bra, sikre at prosessen er solid, og få dette til å fungere på tvers av organisasjonen i stedet for å ende i kaos og støy.

Så tror jeg det må være en koordinert innsats på prosjektnivå, kanskje programnivå, og deretter også på avdelings- og organisasjonsnivå.

Token‑forbruk og inferenskostnader kan virke relativt små under en pilot, men blir betydelige når AI‑systemer rulles ut til tusenvis av ansatte eller autonome agenter. Hvordan bør virksomheter tenke rundt AI‑kostnadsstyring, og forventer du at noe som ligner på FinOps vil dukke opp spesielt for AI‑arbeidsbelastninger?

Jeg vil begynne med å si at et nesten ideelt scenario er når AI‑kostnadene øker, når et platå, og deretter begynner å falle litt over tid. Det viser at du kan prognostisere, kontrollere kostnadene, forstå hva du faktisk bruker på AI, og se resultatene av beslutningene du tar. Dårlige situasjoner er når kostnadene svinger opp og ned fordi det vanligvis betyr at noe ikke er bærekraftig, eller når kostnadene stiger og så faller helt fordi adopsjonen kanskje ikke skjer, noe fungerer ikke, eller folk bruker noe annet og du simpelthen ikke ser det.

FinOps er altså et konsept, og AI‑FinOps er også et konsept. Noen teknikker er svært tekniske, mens andre er ganske enkle. Det kan være så enkelt som å velge den foretrukne modellen slik at du ikke alltid er avhengig av den dyreste, og etter hvert begynner disse beslutningene å spare penger. Samtidig er kunnskap om hvordan du sparer og kontrollerer kostnader bare halvparten av ligningen. FinOps, slik jeg ser det, er en disiplin og metodikk som også involverer produkt‑ og forretningsledere fordi du må definere hva du måler når du evaluerer AI‑innsats.

Ja, jeg tror AI‑FinOps er et godt tema for et tilsvarende AI‑SWAT‑team å diskutere: hvor mye du bruker, hvor mye du får tilbake, hvordan du kontrollerer det, og hvor mulighetene ligger.

Mange selskaper blir bedt om å demonstrere avkastning på investering (ROI) fra AI selv om de aldri har etablert et pålitelig grunnlag for hvor produktive teamene deres var før AI ble introdusert. Hva bør organisasjoner faktisk måle hvis de vil fastslå om AI skaper meningsfull forretningsverdi?

Uavhengig av din holdning til AI eller hvor du befinner deg nå, kanskje du allerede bruker agenter overalt, eller kanskje du tenker at du vil begynne å bruke AI neste år – å etablere et grunnlag er absolutt et must i dag.

Det finnes flere klasser av måleparametere. Noen er subjektive, og kan ganske enkelt være tilbakemeldinger fra utviklerne eller de ansatte, fordi du jobber med mennesker og det er viktig å forstå hvordan de oppfatter verdien av AI. Mer objektive mål kan starte med mekaniske eller syntetiske målinger, selv om jeg vil oppfordre alle til ikke å binde seg for tett til dem. Jeg mener ting som kode‑commits eller story‑points. Disse målene viser at arbeid foregikk, men de viser ikke virkelig verdien eller påvirkningen.

Det som gjør mest forskjell er måleparametere som forklarer hvor raskt eller hvor bra arbeidet ble levert. Tenk på DORA‑målinger som ledetid eller MTTR, hvor raskt du kan komme deg etter en feil, hvor raskt du kan fikse en bug i produksjon, eller hvordan disse målingene endrer seg over tid. Et tall på ett tidspunkt viser ikke utviklingskurven. En av våre arkitekter nevnte nylig at, i programvareutvikling, kan en god måleparameter også være hvor pålitelige estimatene er etter hvert som AI‑adopsjon øker, fordi det sier noe om bærekraften i disse innsatsene og hvor produktive teamene egentlig er. Du må også holde oversikt over kostnadene, for hvis du kun snakker om fordeler uten å forstå hva det koster å oppnå dem, har du ikke hele bildet.

Utenfor programvareutvikling tenker jeg på det på en lignende måte. I hver arbeidsflyt eller prosess finnes det en enhet av arbeid og en definisjon av ferdig. Enten du behandler krav, gjennomgår papirarbeid eller håndterer kundebegär, må du definere hva du leverer og så måle hvor lang tid det tok før AI, hvor raskt og hvor bra du kan gjøre det nå, og hva det koster. Det gir deg et godt utgangspunkt både for basislinjen og for rammen av måleparametere.

DataArt har integrert AI gjennom hele programvareleveringslivssyklusen via initiativer som Artisyn. Etter hvert som AI overtar flere implementerings-, test‑ og arbeidsflytopgaver, hvilke deler av programvareingeniørfaget blir mer verdifulle for mennesker, og hvilke ferdigheter risikerer å bli mindre viktige?

Du kan bare bruke AI effektivt i utvikling hvis du fortsatt husker hva definisjonen av god er. Du trenger den ekspertisen for å veilede agentene dine, gjennomgå resultatene, sette begrensninger og definere reglene. Du må forstå hva beste praksis er og hvordan god arkitektur skal se ut, for uten dette kan du ikke vite hva som blir utviklet, og verdien av denne typen ekspertise øker svært, svært betydelig.

Å forstå arkitektoniske mønstre er viktig, akkurat som å forstå hva som er passende i en bestemt bransje, applikasjon eller løsningsklasse. Du må vite hvilken type arkitektur som er god nå, og hvilken som fortsatt vil være god når løsningen skalerer, fordi noen ganger fungerer ikke den samme arkitekturen gjennom hele levetiden til en løsning eller plattform.

Den balansen mellom hva som er passende for en bestemt løsning er den menneskelige delen. Dette er smaken, håndverket bak tjenester og programvareutvikling. Du må vite hva du gjør, og det kommer også fra forståelse av kunden og bransjen.

Hvilke ferdigheter er mindre viktige? Det er virkelig vanskelig for meg å si, selv om kanskje hvor raskt du kan skrive kode. Jeg tuller, men kode kan nå bli laget mye, mye raskere, og spesifikk kunnskap om et bestemt bibliotek eller språk kan også læres mye raskere med AI.

Jeg har sett .NET‑utviklere omskolert til Java‑utviklere på svært kort tid, og for fem eller ti år siden ville jeg ha sagt at det var nesten umulig i stor skala. I dag kan du det. En sterk seniorutvikler kan i økende grad bevege seg mellom språk fordi det som virkelig betyr noe er deres forståelse av teknologi, arkitektur, løsningsbeste praksis, SDLC og ADLC.

Når bedrifter går fra dusinvis av AI‑piloter til produksjonssystemer som kan handle uavhengig, hvor bør ansvaret til slutt ligge når en AI‑agent gjør en kostbar feil: hos utvikleren, forretningslederen, modellleverandøren, styringsgruppen eller en kombinasjon av dem?

Jeg liker idéen om feilfri samarbeid og delt ansvar fordi alle i organisasjonen bidrar til beste praksis, arkitekturrammer og løsninger. Selv om en utvikler lager kode med eller uten AI, så gjennomgår en annen utvikler den, teamledere gir veiledning, arkitekter leverer arkitekturen og begrensningene, og styringsgruppen bidrar til beslutninger om budsjetter, tidsplaner og utgivelser. Alle er involvert på en eller annen måte.

Veldig ofte, når noe går galt, er det prosessen som svikter, så i den forstand er ansvaret delt på tvers av ulike roller. Men hvis du bare sier at ansvaret er delt og dermed feilfritt, er det ikke nok. Det må fortsatt brytes ned i konkrete ansvarsområder.

Utviklere er ansvarlige for koden de sender inn som en pull‑request, og de må forstå hva som skjer der. Arkitekter er ansvarlige for beslutningene de tar og for de arkitektoniske retningslinjene som gis til agenter og utviklere. Plattformteamet er ansvarlig for løsningens pålitelighet uavhengig av hvem eller hva som har laget en bestemt kodelinje.

Ansvarsområdet er der, men du må definere det detaljert etter team, rolle og avdeling. Det du ikke kan gjøre er å stoppe analysen ved «AI gjorde dette». Du må spørre hvilke kontroller, tester eller tilsyn som tillot at feilen nådde produksjon.

Hvis mangel på enhetstester tillot dårlig kode å bli skyvet inn i produksjon, eller mangel på tilsyn og gjennomgang tillot det, kan du ikke skyve ansvaret over på AI. Du kan heller ikke bare klandre modellleverandøren eller skytilbyderen for hver bug eller nedetid.

Takk for det flotte intervjuet, lesere som ønsker å lære mer bør besøke DataArt.