Prince Kohli, præsident og administrerende direktør for Sauce Labs – Interviewserie

Prince Kohli, præsident og administrerende direktør for Sauce Labs, er en erfaren teknologiekspert med omfattende erfaring inden for kunstig intelligens, enterprise‑software, cloud‑computing, automatisering, netværk og cybersikkerhed. Før han tiltrådte Sauce Labs i februar 2025, tilbragte han mere end seks år som Chief Technology Officer hos Automation Anywhere, hvor han hjalp med at fremme AI‑drevet automatiseringsteknologi for store virksomheder. Tidligere var Kohli Senior Vice President of Engineering hos ThoughtSpot og havde ledende roller hos Ericsson, herunder ansvar for globale R&D‑organisationer med over 10.000 ingeniører. Han tilbragte også næsten et årti hos Citrix med ledelse af platform‑, cloud‑netværks‑, ingeniør‑ og driftsinitiativer. Tidligt i sin karriere var han medstifter af applikationssikkerhedsfirmaet Teros og arbejdede som teknisk leder hos SGI. Ved siden af sine ledelsesroller har Kohli bidraget til teknologigovernance‑initiativer gennem Ethical AI Governance Group og tidligere deltaget i World Economic Forum’s Safe Systems and Technologies‑arbejdsgruppe.

Sauce Labs er en virksomhed inden for softwarekvalitet og kontinuerlig test, som leverer infrastruktur og værktøjer til test af web‑ og mobilapplikationer på tværs af browsere, operativsystemer, virtuelle miljøer og fysiske enheder. Platformen understøtter funktioner som automatiseret og manuel test, visuel test, distribution af mobil‑apps, fejlrapportering samt AI‑drevet testforfatning og analyse, samtidig med at den integreres i almindelige CI/CD‑arbejdsgange. Sauce Labs positionerer i stigende grad sin teknologi omkring AURA, deres AI‑Unified Release Assurance‑platform, som bruger AI‑agenter til at generere, udføre og analysere tests, mens menneskelig kontrol bevares gennem hele software‑releaseprocessen. Virksomheden oplyser, at deres infrastruktur har understøttet mere end 8,7 milliarder testkørsler og over 300 000 virksomhedskunder, baseret på næsten to årtiers tværplatform‑testdata.

Før du tiltrådte Sauce Labs, ledede du AI‑drevet automatisering hos Automation Anywhere og styrede store cloud‑ og ingeniøroperationer i virksomheder som Ericsson og Citrix. Hvordan har disse erfaringer påvirket din opfattelse af software‑kvalitetsproblemet, og hvad overbeviste dig om at gøre AI‑native release assurance til en central prioritet hos Sauce Labs?

Hos Ericsson og Citrix så jeg, hvor hurtigt en softwarefejl kan sprede sig og påvirke global infrastruktur, hvilket skaber store konsekvenser for sikkerhed, kundedrift, tillid og indtægter. Automation Anywhere viste mig, hvordan AI ændrer hastigheden og strukturen i arbejdet, og det blev tydeligt, at testning måtte bygges om for at følge tempoet i AI‑genereret software. Sauce Labs var pionerer inden for testautomatisering, så AI‑native release assurance er det næste store problem, vi er bygget til at løse.

Sauce Labs’ forskning viste, at 80 % af organisationerne har sporet en produktions‑incident, nedbrud eller kundepåvirkende fejl til AI‑genereret kode. Peger dette primært på svagheder i den kode, AI producerer, eller på at virksomheder adopterer AI‑kodningsværktøjer uden at opdatere deres test‑ og governance‑processer?

Den 80 %‑tall peger på et problem i hele softwareleveringssystemet. AI‑branchen har tiltrukket mere end en billion dollars i privat kapital, meget af den baseret på, at AI gør virksomheder dramatisk mere produktive. Men at generere mere kode skaber kun værdi, hvis virksomheder kan være sikre på kvaliteten og sikkerheden, før den bringes i produktion.

AI‑genereret kode kan introducere subtile fejl og sikkerhedsproblemer, og virksomheder bliver tvunget til at presse den kode gennem test‑ og governance‑processer, som allerede havde svært ved at følge med. Det skaber et trillion‑dollar‑executions‑problem: AI kan accelerere software‑skabelse, men uden moderniseret release assurance accelererer den lige så let fejl. Hver fejl vil til sidst blive opdaget, så virksomheder skal sikre sig, at de finder den, før en kunde eller en angriber gør.

Rapporten viser, at udviklere producerer 741 % mere kode, mens udgivelseshastigheden kun er steget med mindre end 20 %. Hvad forhindrer valideringssystemerne i at holde trit, og hvor opstår typisk den største flaskehals i softwareudviklingslivscyklussen?

Kodegenerering er langt foran testoprettelse, -vedligeholdelse og -analyse. De største flaskehalse opstår som regel efter, at koden er skrevet og skal verificeres i konteksten af brugerrejsen. Det kan ofte være meget komplekst, ofte mere komplekst end selve koden, fordi det skal tage højde for end‑to‑end‑stier, der spænder over kodefunktioner og -objekter, hvor tilsyneladende små semantiske ændringer ét sted kan skabe store efterfølgende virkninger. At forfatte disse tests på en måde, så de korrekt og fuldstændigt indfanger applikationens intention, har traditionelt været næsten umuligt og kræver en betydelig mængde manuelt arbejde og vedligeholdelse. Desuden, når tests kører og noget fejler, skal teamet forstå og diagnosticere problemet, herunder afgøre om fejlen skyldes produktet eller en forældet test. Dette arbejde er stadig stærkt afhængigt af manuel gennemgang og ingeniørkontekst.

Mere end halvdelen af de adspurgte virksomheder indrømmede bevidst at frigive software med kritiske fejl, mens 66 % sagde, at de havde gået på kompromis med kvalitet eller teststandarder for at overholde en deadline. Hvorfor accepterer organisationer denne risikoniveau, og hvad skal ændres, for at softwarekvalitet bliver en forretningsprioritet frem for et sidste ingeniørkontrolpunkt?

Organisationer accepterer risikoen, fordi udgivelsesmål er knyttet til umiddelbare kunde‑, indtægts‑ og produktforpligtelser, og fejlomkostninger ofte først viser sig senere på tværs af flere teams. Kvalitet bliver en forretningsprioritet først, når ledere måler produktions‑incidents, kundepåvirkning, sikkerhedseksponering, genarbejdsomkostninger og forsinket omsætning sammen med udgivelseshastigheden.

Sauce Labs positionerer AURA som en lukket‑sløjfe‑platform, der forfatter, udfører og analyserer tests, mens den lærer af hver udgivelse. Hvordan adskiller dette sig teknisk og operationelt fra AI‑assisteret testgenerering, selvhelbredende test‑scripts eller andre automatiseringsværktøjer, som allerede anvendes af ingeniørteams?

De fleste AI‑testværktøjer adresserer en specifik opgave, såsom at generere en test eller reparere en brudt locator. AURA forbinder hele processen ved at forstå applikationens intention, forfatte og udføre tests, analysere fejl og sende produktionsadfærd tilbage til udviklingen. Den kan automatisk håndtere mange ændringer og inddrage en person, når applikationens mening eller forventede adfærd har ændret sig. Derudover er de tests, den genererer, stabile, hvilket betyder, at de ikke behøver at ændres, når ændringer, der ikke påvirker semantik, forekommer i applikationer, browsere, enheder osv. Endelig, da AURA indeholder sin egen test‑eksekverings‑cloud, kan den aflaste hele processen fra en udvikler eller kvalitetstekniker‑team.

AURA er designet til at verificere software mod “forretningsintention”. Hvordan defineres denne intention, og hvordan omsættes den til testbare krav, hvem er ansvarlig for at godkende den, og hvordan håndterer platformen krav, der er tvetydige, ufuldstændige eller åbne for fortolkning?

Forretningsintentionen kommer fra produktkrav, acceptkriterier, forretningsregler, brugerrejsen og den måde, kunderne faktisk bruger applikationen på. Produktledere definerer det forventede resultat, og ingeniør‑ og kvalitetsteams omsætter dette resultat til adfærd, som systemet kan verificere. Når krav er ufuldstændige eller tvetydige, bør AURA fremhæve usikkerheden og anmode om menneskelig godkendelse, før det forventede resultat ændres.

Sauce Labs rapporterer, at virksomheder, der bruger AURA, har oplevet 90 % færre produktions‑incidents, 47 % hurtigere udgivelsescyklusser og har genvundet 38 % af ingeniørkapaciteten. Hvordan blev disse resultater målt, over hvilke implementeringsperioder, og hvilken uafhængig validering blev brugt til at skelne AURAs indflydelse fra andre organisatoriske eller tekniske ændringer?

På tværs af virksomheders implementeringer målte vi ændringer i produktions‑incidents, udgivelseshastighed og ingeniørkapacitet efter, at teams havde implementeret AURA. Disse implementeringer viste mere end 90 % færre produktions‑incidents, 47 % hurtigere udgivelsescyklusser og 38 % genvundet ingeniørkapacitet, med resultaterne valideret uafhængigt. Kunder som Walmart og Keller Williams har også rapporteret betydelige gevinster i udgivelsesfrekvens, testdækning og cyklustid.

Forskningen viste, at 64 % af organisationerne øgede QA‑personale, selvom incidents fortsatte med at stige. Hvorfor kan virksomheder ikke løse verifikationskløften blot ved at ansætte flere testere, og hvordan forventer du, at ansvarsområderne for udviklere, kvalitetsteknikere og site‑reliability‑teams vil ændre sig, når testning bliver mere autonom?

AI kan øge kodevolumen meget hurtigere, end en virksomhed kan øge sit testpersonale, og at tilføje folk skaber også flere overleveringer og koordinationsbehov. Udviklere vil skulle definere intentionen tydeligt, kvalitetsteknikere vil fokusere mere på risiko, dækning og governance, og site‑reliability‑teams vil sende produktionsadfærd tilbage til udgivelsesprocessen. Agenter kan håndtere gentagen eksekvering og analyse i den skala, som denne nye udviklingsmodel kræver.

Efterhånden som AI‑agenter får ansvar for at forfatte, køre og fortolke tests, hvor skal mennesker bevare beslutningsmyndigheden? Hvilke typer af usikkerhed, sikkerhedsrisiko eller potentiel kundepåvirkning bør automatisk stoppe en udgivelse eller udløse menneskelig gennemgang?

Mennesker skal bevare den endelige myndighed over udgivelsesbeslutninger, især når der er tale om dømmekraft, kundepåvirkning eller forretningsrisiko. AI‑agenter kan automatisere kedelige, gentagelige og klart definerede testopgaver, men mennesker bør godkende produktionsudgivelser, når kode eller testresultater ikke kan forstås, forklares eller reproduceres fuldt ud. Gennemgang bør også være obligatorisk, når krav er uklare, sikkerhedssårbarheder er mulige, tredjepartskomponenter ikke er tilstrækkeligt valideret, eller fejl kan påvirke indtægter, følsomme data, kundeoplevelsen eller mission‑kritiske operationer.

I sådanne situationer bør uforklaret adfærd, inkonsistente testresultater eller utilstrækkelige beviser for udgivelsesparathed automatisk stoppe udgivelsen.

Vi har set tilfælde hos vores kunder, hvor en test, der syntes “flaky”, og bestod inkonsekvent uden et tydeligt fejlmønster, i mange tilfælde blev ignoreret. Men velstyrrede processer hos visse af disse kunder krævede due diligence, og med hjælp fra vores platform kunne de spore fejlen til en subtil men kritisk timing‑baseret fejl, som kunne have medført store konsekvenser, hvis den var blevet frigivet, med meget høje omkostninger.

Du har også arbejdet med Ethical AI Governance Group og World Economic Forums arbejdsgruppe for sikre systemer og teknologier. Når AI‑genereret kode og autonom testning bliver dybere forbundet, hvilke governance‑standarder vil virksomheder have brug for at sikre, at hurtigere software‑skabelse ikke introducerer nye systemiske, sikkerheds‑ eller ansvarlighedsrisici?

Jo hurtigere AI kan skabe software, desto stærkere skal verifikations‑ og governance‑laget blive. Dette lag har mange dele. Virksomheder skal have klare grænser for, hvad agenter kan beslutte autonomt, med menneskelig gennemgang påkrævet, når der er usikkerhed omkring forretningsintention, sikkerhed, compliance eller væsentlige semantiske ændringer. De skal også have sporbarhed i, hvad en agent har ændret, hvorfor den ændrede det, og hvilket bevismateriale der understøttede udgivelsesbeslutningen. I sidste ende bør governance måles på kvaliteten og forudsigeligheden af, hvad der når produktion, fx ved specifikt at spore, hvor ofte genereret kode forårsager hændelser inden for 90 dage efter udgivelse, snarere end hvor meget hurtigere AI kan generere kode.

Tak for det gode interview, læsere der ønsker at lære mere, bør besøge Sauce Labs.