Prince Kohli, President en CEO van Sauce Labs – Interviewreeks

Prince Kohli, President en CEO van Sauce Labs, is een ervaren technologie‑executive met een brede expertise op het gebied van kunstmatige intelligentie, enterprise‑software, cloud‑computing, automatisering, netwerken en cyberbeveiliging. Voor hij in februari 2025 bij Sauce Labs kwam, werkte hij meer dan zes jaar als Chief Technology Officer bij Automation Anywhere, waar hij AI‑gedreven automatiseringstechnologieën voor grote ondernemingen heeft bevorderd. Eerder was Kohli Senior Vice President Engineering bij ThoughtSpot en bekleedde hij senior leiderschapsrollen bij Ericsson, waaronder het toezicht op wereldwijde R&D‑organisaties met meer dan 10.000 engineers. Hij heeft ook bijna tien jaar bij Citrix gewerkt, waar hij platform‑, cloud‑netwerk‑, engineering‑ en operationele initiatieven leidde. In een vroegere fase van zijn carrière was hij mede‑oprichter van het applicatiebeveiligingsbedrijf Teros en werkte hij als technisch leider bij SGI. Naast zijn leidinggevende functies heeft Kohli bijgedragen aan technologische governance‑initiatieven via de Ethical AI Governance Group en eerder deelgenomen aan de werkgroep Safe Systems and Technologies van het World Economic Forum.

Sauce Labs is een software‑kwaliteits‑ en continue‑testbedrijf dat ondernemingen voorziet van infrastructuur en tools voor het testen van web‑ en mobiele applicaties op verschillende browsers, besturingssystemen, virtuele omgevingen en echte apparaten. Het platform ondersteunt onder meer geautomatiseerd en handmatig testen, visueel testen, distributie van mobiele apps, foutrapportage en door AI aangedreven test‑authoring en analytics, en integreert met gangbare continuous‑integration‑ en delivery‑workflows. Sauce Labs positioneert zijn technologie steeds meer rond AURA, zijn AI‑Unified Release Assurance platform, dat AI‑agents inzet om tests te genereren, uit te voeren en te analyseren, met behoud van menselijke controle gedurende het gehele release‑proces. Het bedrijf meldt dat zijn infrastructuur meer dan 8,7 miljard testuitvoeringen en meer dan 300.000 enterprise‑gebruikers heeft ondersteund, gebaseerd op bijna twee decennia aan cross‑platform testdata.

Voor dat u bij Sauce Labs kwam, leidde u AI‑gedreven automatisering bij Automation Anywhere en beheerde u grote cloud‑ en engineering‑organisaties bij bedrijven waaronder Ericsson en Citrix. Hoe hebben die ervaringen uw kijk op het software‑kwaliteitsprobleem gevormd, en wat overtuigde u om AI‑native release assurance tot een centrale prioriteit bij Sauce Labs te maken?

Bij Ericsson en Citrix zag ik hoe snel een software‑defect zich kan verspreiden en wereldwijde infrastructuur kan beïnvloeden, met grote gevolgen voor beveiliging, klantoperaties, vertrouwen en omzet. Automation Anywhere liet me zien hoe AI de snelheid en structuur van werk verandert, en het werd duidelijk dat testen opnieuw moet worden opgebouwd voor het tempo van AI‑gegenereerde software. Sauce Labs was een pionier op het gebied van testautomatisering, dus AI‑native release assurance is het volgende grote probleem dat wij oplossen.

Het onderzoek van Sauce Labs wees uit dat 80 % van de organisaties een productie‑incident, uitval of klant‑impact defect heeft herleid tot AI‑gegenereerde code. Duidt dit voornamelijk op zwaktes in de door AI geproduceerde code, of op bedrijven die AI‑codeertools adopteren zonder hun test‑ en governanceprocessen bij te werken?

Het cijfer van 80 % wijst op een probleem in het volledige software‑leveringsysteem. De AI‑industrie heeft meer dan een biljoen dollar aan privé‑kapitaal aangetrokken, grotendeels gebaseerd op de veronderstelling dat AI bedrijven aanzienlijk productiever maakt. Maar meer code genereren levert alleen waarde op als bedrijven zeker kunnen zijn van de kwaliteit en veiligheid ervan voordat ze deze in productie nemen.

AI‑gegenereerde code kan subtiele bugs en beveiligingsproblemen introduceren, en ondernemingen worden gedwongen die code door test‑ en governanceprocessen te leiden die al moeite hadden om het tempo bij te houden. Dat creëert een executie‑probleem van een biljoen dollar: AI kan softwarecreatie versnellen, maar zonder gemoderniseerde release assurance versnelt het even gemakkelijk defecten. Elke bug zal uiteindelijk worden tegengekomen, dus moeten bedrijven ervoor zorgen dat ze die vinden voordat een klant of aanvaller dat doet.

Het rapport stelt dat ontwikkelaars 741 % meer code produceren terwijl de releasesnelheid minder dan 20 % is gestegen. Wat verhindert validatiesystemen om gelijke tred te houden, en waar ontstaat doorgaans de grootste knelpunt in de software‑ontwikkelingslevenscyclus?

Codegeneratie loopt ver voor op het maken, onderhouden en analyseren van tests. De grootste knelpunten verschijnen meestal nadat de code is geschreven en moet worden geverifieerd in de context van de gebruikersreis. Dat kan vaak zeer complex zijn, vaak complexer dan de code zelf, omdat het rekening moet houden met end‑to‑end paden die code‑functies en objecten omvatten, waarbij ogenschijnlijk kleine semantische wijzigingen op één plek grote downstream‑effecten veroorzaken. Het opstellen van tests die de intentie van de applicatie correct en volledig vastleggen, is traditioneel bijna onmogelijk geweest en vereist bovendien een aanzienlijke hoeveelheid handmatig werk en onderhoud. Bovendien moeten teams, nadat tests zijn uitgevoerd en iets faalt, het probleem begrijpen en diagnosticeren, inclusief bepalen of een fout afkomstig is van het product of van een verouderde test. Dat werk blijft sterk afhankelijk van handmatige beoordeling en technische context.

Meer dan de helft van de ondervraagde ondernemingen gaf toe bewust software met kritieke defecten uit te brengen, terwijl 66 % zei dat ze kwaliteit of testnormen hebben gecompromitteerd om een deadline te halen. Waarom accepteren organisaties dit risiconiveau, en wat moet er veranderen zodat softwarekwaliteit een zakelijke prioriteit wordt in plaats van een laatste engineering‑checkpoint?

Organisaties accepteren het risico omdat release‑doelstellingen gekoppeld zijn aan directe klant‑, omzet‑ en productverplichtingen, en defectkosten vaak later bij verschillende teams naar voren komen. Kwaliteit wordt pas een zakelijke prioriteit wanneer leiders productie‑incidenten, klantimpact, beveiligingsrisico’s, herwerk‑kosten en vertraagde omzet meten naast de releasesnelheid.

Sauce Labs positioneert AURA als een gesloten‑lus platform dat tests opstelt, uitvoert en analyseert terwijl het van elke release leert. Hoe verschilt dit technisch en operationeel van AI‑ondersteunde testgeneratie, zelf‑herstellende test‑scripts of andere automatiseringstools die al door engineering‑teams worden gebruikt?

De meeste AI‑testtools richten zich op een specifieke taak, zoals het genereren van een test of het repareren van een kapotte locator. AURA verbindt het volledige proces door de intentie van de applicatie te begrijpen, tests op te stellen en uit te voeren, fouten te analyseren en productiegedrag terug te voeren naar de ontwikkeling. Het kan automatisch veel wijzigingen afhandelen en een persoon in het proces betrekken wanneer de betekenis of het verwachte gedrag van de applicatie verandert. Bovendien zijn de door AURA gegenereerde tests stabiel, wat betekent dat ze niet aangepast hoeven te worden wanneer wijzigingen die de semantiek niet beïnvloeden, optreden in applicaties, browsers, apparaten en dergelijke. Ten slotte, omdat AURA een test‑executie‑cloud in zich heeft, kan het het volledige proces ontlasten van een ontwikkelaar of kwaliteit‑engineeringteam.

AURA is ontworpen om software te verifiëren tegen “zakelijke intentie”. Hoe wordt die intentie gedefinieerd en vertaald naar testbare eisen, wie is verantwoordelijk voor de goedkeuring, en hoe gaat het platform om met eisen die dubbelzinnig, onvolledig of interpretatie‑gevoelig zijn?

Zakelijke intentie komt voort uit productvereisten, acceptatiecriteria, bedrijfsregels, gebruikersreizen en de manier waarop klanten de applicatie daadwerkelijk gebruiken. Productleiders definiëren het verwachte resultaat, en engineering‑ en kwaliteitsteams vertalen dat resultaat naar gedrag dat het systeem kan verifiëren. Wanneer eisen onvolledig of dubbelzinnig zijn, moet AURA de onzekerheid zichtbaar maken en om menselijke goedkeuring vragen voordat het verwachte resultaat wordt aangepast.

Sauce Labs meldt dat ondernemingen die AURA gebruiken 90 % minder productie‑incidenten, 47 % snellere release‑cycli en 38 % teruggewonnen engineering‑capaciteit hebben ervaren. Hoe werden deze resultaten gemeten, over welke implementatieperioden, en welke onafhankelijke validatie werd gebruikt om de impact van AURA te onderscheiden van andere organisatorische of engineering‑veranderingen?

Bij enterprise‑implementaties hebben we veranderingen gemeten in productie‑incidenten, releasesnelheid en engineering‑capaciteit nadat teams AURA hadden geïmplementeerd. Die implementaties zagen meer dan 90 % minder productie‑incidenten, 47 % snellere release‑cycli en 38 % teruggewonnen engineering‑capaciteit, met de resultaten onafhankelijk gevalideerd. Klanten zoals Walmart en Keller Williams hebben ook aanzienlijke verbeteringen gemeld in release‑frequentie, testdekking en cyclustijd.

Uit het onderzoek bleek dat 64 % van de organisaties het QA‑personeel heeft vergroot terwijl incidenten toch bleven stijgen. Waarom kunnen ondernemingen de verificatiekloof niet simpelweg oplossen door meer testers aan te nemen, en hoe verwacht u dat de verantwoordelijkheden van ontwikkelaars, quality‑engineers en site‑reliability‑teams veranderen naarmate testen autonomer worden?

AI kan de code‑volume veel sneller laten groeien dan een bedrijf zijn test‑personeel kan uitbreiden, en extra mensen introduceren bovendien meer overdrachten en coördinatie. Ontwikkelaars moeten de intentie duidelijk definiëren, quality‑engineers zullen zich meer richten op risico, dekking en governance, en site‑reliability‑teams zullen productiegedrag terugvoeren naar het release‑proces. Agents kunnen repetitieve uitvoering en analyse aan kunnen op de schaal die dit nieuwe ontwikkelingsmodel vereist.

Naarmate AI‑agents meer verantwoordelijkheid krijgen voor het opstellen, uitvoeren en interpreteren van tests, waar moeten mensen de besluitvormingsautoriteit behouden? Welke soorten onzekerheid, beveiligingsrisico’s of potentiële klantimpact moeten automatisch een release stoppen of een menselijke review activeren?

Mensen moeten de uiteindelijke autoriteit over release‑beslissingen behouden, vooral wanneer oordeel, klantimpact of bedrijfsrisico’s een rol spelen. AI‑agents kunnen saaie, repeterende en duidelijk gedefinieerde testtaken automatiseren, maar mensen moeten productie‑releases goedkeuren wanneer code of testresultaten niet volledig begrepen, uitgelegd of gereproduceerd kunnen worden. Een review moet ook verplicht zijn wanneer eisen onduidelijk zijn, beveiligingskwetsbaarheden mogelijk zijn, derde‑partij componenten niet voldoende gevalideerd zijn, of fouten invloed kunnen hebben op omzet, gevoelige data, klantbeleving of mission‑critical operaties.

In die situaties moet onverklaard gedrag, inconsistente testresultaten of onvoldoende bewijs van release‑gereedheid automatisch de release stoppen.

We hebben bij enkele klanten gevallen gezien waarin een test die “flaky” leek, onregelmatig slaagde zonder een duidelijk foutpatroon, vaak werd genegeerd. Maar goed beheerde processen bij sommige van deze klanten vereisten zorgvuldigheid en met behulp van ons platform konden zij de fout traceren naar een subtiel maar kritiek timing‑gerelateerd defect dat, indien vrijgegeven, tot grote impact had kunnen leiden, met zeer hoge kosten.

U heeft ook samengewerkt met de Ethical AI Governance Group en de Safe Systems and Technologies werkgroep van het World Economic Forum. Naarmate AI‑gegenereerde code en autonome testing steeds dieper met elkaar verweven raken, welke governance‑standaarden hebben ondernemingen nodig om te waarborgen dat snellere softwarecreatie geen nieuwe systemische, beveiligings‑ of verantwoordingsrisico’s introduceert?

Hoe sneller AI software kan creëren, hoe sterker de verificatie‑ en governance‑laag moet worden. Deze laag bestaat uit vele onderdelen. Ondernemingen moeten duidelijke grenzen stellen aan wat agents autonoom mogen beslissen, met menselijke review wanneer er onzekerheid bestaat over zakelijke intentie, beveiliging, compliance of betekenisvolle semantische verandering. Ze hebben ook traceerbaarheid nodig van wat een agent heeft aangepast, waarom het is aangepast en welk bewijs de release‑beslissing ondersteunt. Uiteindelijk moet governance worden gemeten aan de hand van de kwaliteit en voorspelbaarheid van wat productie bereikt, bijvoorbeeld door specifiek bij te houden hoe vaak gegenereerde code incidenten veroorzaakt binnen 90 dagen na release, en niet aan de hand van hoe veel sneller AI code kan genereren.

Dank u voor het geweldige interview, lezers die meer willen weten, kunnen terecht op Sauce Labs.