Prince Kohli, president och VD för Sauce Labs – intervjuserie

Prince Kohli, president och VD för Sauce Labs, är en erfaren teknikchef med omfattande erfarenhet inom artificiell intelligens, företagsprogramvara, molntjänster, automation, nätverk och cybersäkerhet. Innan han började på Sauce Labs i februari 2025 tillbringade han mer än sex år som Chief Technology Officer på Automation Anywhere, där han bidrog till att utveckla AI‑driven automations‑teknik för stora företag. Tidigare var Kohli Senior Vice President of Engineering på ThoughtSpot och hade ledande befattningar på Ericsson, bland annat med ansvar för globala R&D‑organisationer med över 10 000 ingenjörer. Han tillbringade också nästan ett decennium på Citrix och ledde plattform, molnnätverk, ingenjörs‑ och driftinitiativ. Tidigare i sin karriär var han medgrundare till applikationssäkerhetsföretaget Teros och arbetade som teknisk ledare på SGI. Vid sidan av sina chefsroller har Kohli bidragit till teknikstyrningsinitiativ genom Ethical AI Governance Group och tidigare deltagit i World Economic Forums arbetsgrupp för säkra system och teknologier.

Sauce Labs är ett företag för mjukvarukvalitet och kontinuerlig testning som tillhandahåller företag infrastruktur och verktyg för testning av webb‑ och mobilapplikationer över webbläsare, operativsystem, virtuella miljöer och riktiga enheter. Plattformen stödjer funktioner som automatiserad och manuell testning, visuell testning, distribution av mobilappar, felrapportering samt AI‑driven testförfattning och analys, samtidigt som den integreras med vanliga arbetsflöden för kontinuerlig integration och leverans. Sauce Labs positionerar i allt högre grad sin teknik kring AURA, deras AI‑Unified Release Assurance‑plattform, som använder AI‑agenter för att hjälpa till att generera, köra och analysera tester samtidigt som mänsklig tillsyn behålls genom hela mjukvarusläppprocessen. Företaget uppger att deras infrastruktur har stöd för mer än 8.7 miljarder testkörningar och över 300 000 företagsanvändare, baserat på nästan två decennier av tvärplattformstestdata.

Innan du gick med i Sauce Labs, ledde du AI‑driven automation på Automation Anywhere och ansvarade för stora moln‑ och ingenjörsorganisationer på företag inklusive Ericsson och Citrix. Hur har dessa erfarenheter format din syn på mjukvarukvalitetsproblemet, och vad övertygade dig om att göra AI‑native release assurance till en central prioritet på Sauce Labs?

På Ericsson och Citrix såg jag hur snabbt ett mjukvarufel kan spridas och påverka global infrastruktur, vilket skapar stora effekter på säkerhet, kunddrift, förtroende och intäkter. Automation Anywhere visade mig hur AI förändrar hastigheten och strukturen i arbetet, och det blev tydligt att testning måste byggas om för takten i AI‑genererad mjukvara. Sauce Labs var pionjär inom testautomation, så AI‑native release assurance är det nästa stora problemet vi är byggda för att lösa.

Sauce Labs’ forskning visade att 80 % av organisationerna har spårat ett produktionsincident, driftstopp eller kundpåverkande fel till AI‑genererad kod. Påpekar detta främst svagheter i den kod som AI producerar, eller att företag använder AI‑kodningsverktyg utan att uppdatera sina test‑ och styrningsprocesser?

Den 80 %‑siffran pekar på ett problem i hela mjukvaruleveranssystemet. AI‑branschen har lockat mer än en biljon dollar i privat kapital, mycket av det baserat på att AI gör företag dramatiskt mer produktiva. Men att generera mer kod skapar bara värde om företag kan vara säkra på dess kvalitet och säkerhet innan den tas i produktion.

AI‑genererad kod kan introducera subtila buggar och säkerhetsproblem och företag tvingas föra den koden genom test‑ och styrningsprocesser som redan hade svårt att hänga med. Det skapar ett trillion‑dollar‑exekveringsproblem: AI kan påskynda mjukvaruskapande, men utan moderniserad release‑assurance påskyndar det lika lätt fel. Alla buggar kommer så småningom att påträffas, så företag måste säkerställa att de hittar dem innan en kund eller angripare gör det.

Rapporten visar att utvecklare producerar 741 % mer kod medan leveranshastigheten har ökat med mindre än 20 %. Vad hindrar valideringssystemen från att hålla takten, och var uppstår vanligtvis den största flaskhalsen i mjukvaruutvecklingslivscykeln?

Kodgenerering har gått långt före skapande, underhåll och analys av tester. De största flaskhalsarna uppstår vanligtvis efter att koden skrivits och måste verifieras i samband med användarresan. Detta kan ofta vara mycket komplext, ibland mer komplext än själva koden, eftersom det måste ta hänsyn till end‑to‑end‑vägar som sträcker sig över kodfunktioner och objekt, där till synes små semantiska förändringar på ett ställe skapar stora nedströms effekter. Att skapa dessa tester på ett sätt som korrekt och fullständigt fångar applikationens avsikt har traditionellt varit nästan omöjligt, och kräver dessutom en mycket stor mängd manuellt arbete och underhåll. Dessutom, efter att tester körts och något misslyckas, måste teamen förstå och diagnostisera problemet, inklusive att avgöra om ett fel beror på produkten eller ett föråldrat test. Detta arbete är fortfarande starkt beroende av manuell granskning och ingenjörskontext.

Mer än hälften av de undersökta företagen erkände att de medvetet släppte mjukvara med kritiska fel, medan 66 % sade att de komprometterade kvalitet eller teststandarder för att möta en deadline. Varför accepterar organisationer denna risknivå, och vad måste förändras för att mjukvarukvalitet ska bli en affärsprioritet snarare än en sista ingenjörskontroll?

Organisationer accepterar risken eftersom leveransmål är kopplade till omedelbara kund-, intäkts‑ och produktåtaganden, och felkostnader ofta visar sig senare över flera team. Kvalitet blir en affärsprioritet först när ledare mäter produktionsincidenter, kundpåverkan, säkerhetsexponering, omarbetningskostnader och försenade intäkter tillsammans med leveranshastigheten.

Sauce Labs positionerar AURA som en sluten slinga‑plattform som skapar, kör och analyserar tester samtidigt som den lär sig av varje release. Hur skiljer sig detta tekniskt och operativt från AI‑assisterad testgenerering, självläkande testskript eller andra automationsverktyg som redan används av ingenjörsteam?

De flesta AI‑testverktyg hanterar en specifik uppgift, såsom att generera ett test eller reparera en trasig locator. AURA kopplar samman hela processen genom att förstå applikationens avsikt, skapa och köra tester, analysera fel och föra tillbaka produktionsbeteende till utvecklingen. Den kan automatiskt hantera många förändringar och involvera en person när applikationens betydelse eller förväntade beteende har förändrats. Dessutom är de tester den genererar stabila, vilket betyder att de inte behöver modifieras när förändringar som inte påverkar semantiken sker i applikationer, webbläsare, enheter och liknande. Slutligen, eftersom AURA inbäddar en testexekveringsmoln i sig själv, kan den avlasta hela processen från en utvecklare eller kvalitetsteknikteam.

AURA är utformat för att verifiera mjukvara mot “affärsavsikt”. Hur definieras den avsikten och översätts till testbara krav, vem är ansvarig för att godkänna den, och hur hanterar plattformen krav som är tvetydiga, ofullständiga eller öppna för tolkning?

Affärsavsikt härrör från produktkrav, acceptanskriterier, affärsregler, användarresor och det sätt som kunder faktiskt använder applikationen på. Produktledare definierar det förväntade resultatet, och ingenjörs‑ och kvalitetsteam översätter detta resultat till beteende som systemet kan verifiera. När krav är ofullständiga eller tvetydiga bör AURA visa osäkerheten och begära mänskligt godkännande innan det förväntade resultatet ändras.

Sauce Labs rapporterar att företag som använder AURA har upplevt 90 % färre produktionsincidenter, 47 % snabbare release‑cykler och återvunnit 38 % av ingenjörskapaciteten. Hur mättes dessa resultat, över vilka implementeringsperioder, och vilken oberoende validering användes för att särskilja AURAs påverkan från andra organisatoriska eller ingenjörsmässiga förändringar?

Genom företagsimplementationer mätte vi förändringar i produktionsincidenter, release‑cykelns hastighet och ingenjörskapacitet efter att team implementerat AURA. Dessa implementationer visade mer än 90 % färre produktionsincidenter, 47 % snabbare release‑cykler och 38 % återvunnen ingenjörskapacitet, med resultaten oberoende validerade. Kunder som Walmart och Keller Williams har också rapporterat betydande förbättringar i release‑frekvens, testtäckning och cykeltid.

Forskningen fann att 64 % av organisationerna ökade antalet kvalitetssäkringspersonal även när incidenterna fortsatte att öka. Varför kan företag inte lösa verifieringsgapet bara genom att anställa fler testare, och hur förväntar du dig att ansvarsområdena för utvecklare, kvalitetstekniker och site‑reliability‑team förändras när testning blir mer autonom?

AI kan öka kodvolymen mycket snabbare än ett företag kan öka sin testpersonal, och att lägga till fler personer skapar också fler överlämningar och samordning. Utvecklare kommer behöva definiera avsikt tydligt, kvalitetstekniker kommer fokusera mer på risk, täckning och styrning, och site‑reliability‑team kommer föra tillbaka produktionsbeteende till release‑processen. Agenter kan hantera repetitiv exekvering och analys i den skala som denna nya utvecklingsmodell kräver.

När AI‑agenter får ansvar för att skapa, köra och tolka tester, var måste människor behålla beslutsfattande myndighet? Vilken typ av osäkerhet, säkerhetsrisk eller potentiell kundpåverkan bör automatiskt stoppa en release eller utlösa mänsklig granskning?

Människor måste behålla slutgiltig myndighet över release‑beslut, särskilt när omdöme, kundpåverkan eller affärsrisk är inblandade. AI‑agenter kan automatisera tråkiga, repetitiva och tydligt definierade testuppgifter, men människor bör godkänna produktionsreleaser när kod eller testresultat inte kan förstås, förklaras eller reproduceras fullt ut. Granskning bör också vara obligatorisk när krav är oklara, säkerhetsbrister är möjliga, tredjepartskomponenter inte har validerats tillräckligt, eller fel kan påverka intäkter, känslig data, kundupplevelse eller kritiska verksamhetsprocesser.

I sådana situationer bör oförklarat beteende, inkonsekventa testresultat eller otillräckliga bevis på releasens beredskap automatiskt stoppa releasen.

Vi har sett fall hos våra kunder där ett test som verkade “flaky”, och som passerade inkonsekvent utan ett tydligt felmönster, ofta ignorerades. Men välstyrda processer hos vissa av dessa kunder krävde noggrannhet och med hjälp av vår plattform kunde de spåra felet till ett subtilt men kritiskt tidsbaserat fel som kunde ha lett till stora konsekvenser om det släpptes, med mycket hög kostnad.

Du har också arbetat med Ethical AI Governance Group och World Economic Forums arbetsgrupp för säkra system och teknologier. När AI‑genererad kod och autonom testning blir allt mer sammankopplade, vilka styrningsstandarder behöver företag för att säkerställa att snabbare mjukvaruskapande inte introducerar nya systematiska, säkerhets‑ eller ansvarsrisker?

Ju snabbare AI kan skapa mjukvara, desto starkare måste verifierings‑ och styrningslagret bli. Detta lager har många delar. Företag måste ha tydliga gränser för vad agenter får besluta autonomt, med mänsklig granskning när det finns osäkerhet kring affärsavsikt, säkerhet, efterlevnad eller meningsfull semantisk förändring. De behöver också spårbarhet för vad en agent ändrade, varför den ändrade det och vilket bevis som stödde release‑beslutet. I slutändan bör styrning mätas på kvaliteten och förutsägbarheten i det som når produktion, exempelvis genom att specifikt spåra hur ofta genererad kod orsakar incidenter inom 90 dagar efter release, inte hur mycket snabbare AI kan generera kod.

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