Prince Kohli, president og administrerende direktør i Sauce Labs – Intervjuserie

Prince Kohli, president og administrerende direktør i Sauce Labs, er en erfaren teknologileder med omfattende erfaring innen kunstig intelligens, bedriftsprogramvare, skytjenester, automatisering, nettverk og cybersikkerhet. Før han begynte i Sauce Labs i februar 2025, tilbrakte han mer enn seks år som Chief Technology Officer i Automation Anywhere, hvor han bidro til å fremme AI‑drevet automatiseringsteknologi for store foretak. Tidligere var Kohli seniorvicepresident for engineering i ThoughtSpot og hadde seniorlederroller i Ericsson, inkludert ansvar for globale FoU‑organisasjoner med mer enn 10 000 ingeniører. Han tilbrakte også nesten et tiår i Citrix med ledelse av plattform, sky‑nettverk, engineering og driftsinitiativer. Tidligere i karrieren var han medstifter av applikasjonssikkerhetsselskapet Teros og arbeidet som teknisk leder i SGI. Ved siden av sine lederroller har Kohli bidratt til teknologigovernance‑initiativ gjennom Ethical AI Governance Group og tidligere deltatt i World Economic Forums arbeidsgruppe for trygge systemer og teknologier.

Sauce Labs er et selskap for programvarekvalitet og kontinuerlig testing som leverer infrastruktur og verktøy til bedrifter for testing av nett‑ og mobilapplikasjoner på tvers av nettlesere, operativsystemer, virtuelle miljøer og ekte enheter. Plattformen støtter funksjoner som automatisert og manuell testing, visuell testing, distribusjon av mobilapper, feilrapportering og AI‑drevet testforfatting og analyse, samtidig som den integreres med vanlige arbeidsflyter for kontinuerlig integrasjon og levering. Sauce Labs posisjonerer i økende grad teknologien sin rundt AURA, deres AI‑Unified Release Assurance‑plattform, som bruker AI‑agenter til å hjelpe med å generere, kjøre og analysere tester samtidig som menneskelig tilsyn beholdes gjennom hele programvareutgivelsesprosessen. Selskapet oppgir at infrastrukturen har støttet mer enn 8,7 milliarder testkjøringer og over 300 000 bedriftsbrukere, basert på nesten to tiår med tverrplattform‑testdata.

Før du begynte i Sauce Labs, ledet du AI‑drevet automatisering i Automation Anywhere og styrte store sky‑ og engineering‑organisasjoner i selskaper som Ericsson og Citrix. Hvordan har disse erfaringene påvirket ditt syn på programvarekvalitetsproblemet, og hva overbeviste deg om å gjøre AI‑native release assurance til en sentral prioritet i Sauce Labs?

Hos Ericsson og Citrix så jeg hvor raskt en programvarefeil kan spre seg og påvirke global infrastruktur, noe som skaper store konsekvenser for sikkerhet, kundedrift, tillit og inntekter. Automation Anywhere viste meg hvordan AI endrer hastigheten og strukturen i arbeidet, og det ble tydelig at testing måtte bygges om for tempoet til AI‑generert programvare. Sauce Labs var pionerer innen testautomatisering, så AI‑native release assurance er det neste store problemet vi er bygget for å løse.

Sauce Labs’ forskning fant at 80 % av organisasjoner har sporet en produksjons‑hendelse, nedetid eller kundepåvirkende feil til AI‑generert kode. Påpeker dette primært svakheter i koden som AI produserer, eller at bedrifter tar i bruk AI‑kodingsverktøy uten å oppdatere sine test‑ og styringsprosesser?

Den 80 %‑tallet peker på et problem i hele programvareleveransesystemet. AI‑industrien har tiltrukket mer enn en billion dollar i privat kapital, mye av den basert på at AI skal gjøre bedrifter dramatisk mer produktive. Men å generere mer kode skaper kun verdi dersom selskaper kan være sikre på kvaliteten og sikkerheten før den tas i produksjon.

AI‑generert kode kan innføre subtile feil og sikkerhetsproblemer, og bedrifter blir tvunget til å føre denne koden gjennom test‑ og styringsprosesser som allerede hadde vanskelig for å holde tritt. Det skaper et trillion‑dollar‑utførelsesproblem: AI kan akselerere programvareutvikling, men uten modernisert release assurance akselererer den like lett feil. Hver feil vil til slutt bli oppdaget, så selskaper må sørge for at de finner den før en kunde eller en angriper gjør det.

Rapporten viser at utviklere produserer 741 % mer kode mens utgivelseshastigheten kun har økt med mindre enn 20 %. Hva hindrer valideringssystemene i å holde tritt, og hvor oppstår den største flaskehalsen vanligvis i programvareutviklingslivssyklusen?

Kodegenerering har kommet langt foran opprettelse, vedlikehold og analyse av tester. De største flaskehalsene oppstår vanligvis etter at koden er skrevet og må verifiseres i konteksten av brukerreisen. Dette kan ofte være svært komplekst, ofte mer komplekst enn selve koden, siden det må ta hensyn til ende‑til‑ende‑stier som spenner over kodefunksjoner og objekter, hvor tilsynelatende små endringer i semantikk på ett sted skaper store nedstrøms effekter. Å skrive disse testene på en måte som korrekt og fullt ut fanger applikasjonens intensjon har tradisjonelt vært nesten umulig, i tillegg krever det en betydelig mengde manuelt arbeid og vedlikehold. Videre, etter at tester har kjørt og noe feiler, må teamene forstå og diagnostisere problemet, inkludert å avgjøre om en feil kommer fra produktet eller en utdatert test. Dette arbeidet er fortsatt sterkt avhengig av manuell gjennomgang og ingeniørkontekst.

Mer enn halvparten av de undersøkte virksomhetene innrømmet at de bevisst slapp ut programvare med kritiske feil, mens 66 % sa at de hadde kompromittert kvalitet eller teststandarder for å møte en frist. Hvorfor aksepterer organisasjoner dette risikonivået, og hva må endres for at programvarekvalitet skal bli en forretningsprioritet snarere enn et siste ingeniørkontrollpunkt?

Organisasjoner aksepterer risikoen fordi utgivelsesmål er knyttet til umiddelbare kunde‑, inntekts‑ og produktforpliktelser, og feilkostnader ofte viser seg senere på tvers av flere team. Kvalitet blir en forretningsprioritet først når ledere måler produksjonshendelser, kundepåvirkning, sikkerhetseksponering, omarbeidingskostnader og forsinket inntekt i tillegg til utgivelseshastigheten.

Sauce Labs posisjonerer AURA som en lukket sløyfe‑plattform som forfatter, kjører og analyserer tester mens den lærer av hver utgivelse. Hvordan skiller dette seg teknisk og operasjonelt fra AI‑assistert testgenerering, selv‑helbredende testskript eller andre automatiseringsverktøy som allerede brukes av ingeniørteam?

De fleste AI‑testverktøy adresserer en spesifikk oppgave, som å generere en test eller reparere en ødelagt lokator. AURA knytter sammen hele prosessen ved å forstå applikasjonens intensjon, forfatte og kjøre tester, analysere feil, og sende produksjonsatferd tilbake til utviklingen. Den kan automatisk håndtere mange endringer og involvere en person i prosessen når applikasjonens betydning eller forventet oppførsel har endret seg. I tillegg er testene den genererer stabile, det vil si at de ikke trenger å endres når endringer som ikke påvirker semantikken skjer i applikasjoner, nettlesere, enheter osv. Til slutt, siden AURA innebygd har en testkjørings‑sky, kan den avlaste hele prosessen fra en utvikler eller kvalitetstekning‑team.

AURA er designet for å verifisere programvare mot «forretningsintensjon». Hvordan defineres denne intensjonen og oversettes til testbare krav, hvem er ansvarlig for å godkjenne den, og hvordan håndterer plattformen krav som er tvetydige, ufullstendige eller åpne for tolkning?

Forretningsintensjon kommer fra produktkrav, akseptkriterier, forretningsregler, brukerreiser og måten kundene faktisk bruker applikasjonen på. Produktledere definerer det forventede resultatet, og engineering‑ og kvalitetsteam oversetter dette resultatet til atferd som systemet kan verifisere. Når krav er ufullstendige eller tvetydige, bør AURA avdekke usikkerheten og be om menneskelig godkjenning før den endrer det forventede resultatet.

Sauce Labs rapporterer at virksomheter som bruker AURA har opplevd 90 % færre produksjonshendelser, 47 % raskere utgivelsessykluser og gjenvunnet 38 % av ingeniørkapasiteten. Hvordan ble disse resultatene målt, over hvilke implementeringsperioder, og hvilken uavhengig validering ble brukt for å skille AURAs påvirkning fra andre organisatoriske eller tekniske endringer?

På tvers av bedriftsimplementeringer målte vi endringer i produksjonshendelser, hastighet på utgivelsessyklusen og ingeniørkapasitet etter at teamene implementerte AURA. Disse implementeringene viste mer enn 90 % færre produksjonshendelser, 47 % raskere utgivelsessykluser og 38 % av ingeniørkapasiteten gjenvunnet, med resultatene uavhengig validert. Kunder som Walmart og Keller Williams har også rapportert betydelige gevinster i utgivelsesfrekvens, testdekning og syklustid.

Forskningen fant at 64 % av organisasjonene økte antall kvalitetssikringspersonell selv om hendelser fortsatte å øke. Hvorfor kan ikke virksomheter løse verifiseringsgapet bare ved å ansette flere testere, og hvordan forventer du at ansvarsområdene til utviklere, kvalitetsteknikere og site‑reliability‑team vil endre seg når testing blir mer autonom?

AI kan øke kodevolumet mye raskere enn et selskap kan øke antall testere, og å ansette flere personer skaper også flere overleveringer og koordinering. Utviklere må definere intensjon tydelig, kvalitetsteknikere vil fokusere mer på risiko, dekning og styring, og site‑reliability‑team vil sende produksjonsatferd tilbake til utgivelsesprosessen. Agenter kan håndtere repeterende kjøring og analyse i den skalaen den nye utviklingsmodellen krever.

Etter hvert som AI‑agenter får ansvar for å forfatte, kjøre og tolke tester, hvor må mennesker beholde beslutningsmyndighet? Hvilke typer usikkerhet, sikkerhetsrisiko eller potensiell kundepåvirkning bør automatisk stoppe en utgivelse eller utløse menneskelig gjennomgang?

Mennesker må beholde endelig myndighet over utgivelsesbeslutninger, spesielt når vurdering, kundepåvirkning eller forretningsrisiko er involvert. AI‑agenter kan automatisere kjedelige, repeterende og klart definerte testoppgaver, men mennesker bør godkjenne produksjonsutgivelser når kode eller testresultater ikke kan forstås, forklares eller reproduseres fullt ut. Gjennomgang bør også være obligatorisk når krav er uklare, sikkerhetsvaksligheter er mulige, tredjepartskomponenter ikke er tilstrekkelig validert, eller feil kan påvirke inntekter, sensitiv data, kundeopplevelse eller kritiske operasjoner.

I slike situasjoner bør uforklarlig oppførsel, inkonsistente testresultater eller utilstrekkelig bevis på utgivelsesberedskap automatisk stoppe utgivelsen.

Vi har sett tilfeller hos våre kunder hvor en test som fremsto som «ustabil», og bestod inkonsekvent uten et tydelig feilmønster, ofte ble ignorert. Men velstyrte prosesser hos enkelte av disse kundene krevde grundig oppfølging, og med hjelp fra vår plattform klarte de å spore feilen til en subtil men kritisk tidsbasert feil som kunne ha ført til store konsekvenser dersom den ble sluppet, med svært høy kostnad.

Du har også jobbet med Ethical AI Governance Group og World Economic Forums arbeidsgruppe for trygge systemer og teknologier. Etter hvert som AI‑generert kode og autonom testing blir tettere knyttet sammen, hvilke styringsstandarder vil virksomheter trenge for å sikre at raskere programvareproduksjon ikke introduserer nye systemiske, sikkerhets‑ eller ansvarlighetsrisikoer?

Jo raskere AI kan lage programvare, jo sterkere må verifiserings‑ og styringslaget bli. Dette laget har mange deler.  Virksomheter må ha klare grenser for hva agenter kan bestemme autonomt, med menneskelig gjennomgang når det er usikkerhet rundt forretningsintensjon, sikkerhet, etterlevelse eller meningsfull semantisk endring. De trenger også sporbarhet i hva en agent endret, hvorfor den endret det, og hvilket bevis som støttet utgivelsesbeslutningen. Til syvende og sist bør styring måles etter kvaliteten og forutsigbarheten til det som når produksjon, for eksempel ved spesifikt å spore hvor ofte generert kode forårsaker hendelser innen 90 dager etter utgivelse, ikke etter hvor mye raskere AI kan generere kode.

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