Prince Kohli, Präsident und CEO von Sauce Labs – Interviewreihe

Prince Kohli, Präsident und CEO von Sauce Labs, ist ein erfahrener Technologie‑Manager mit umfangreicher Erfahrung in den Bereichen Künstliche Intelligenz, Unternehmenssoftware, Cloud‑Computing, Automatisierung, Netzwerke und Cybersicherheit. Bevor er im Februar 2025 zu Sauce Labs kam, war er mehr als sechs Jahre lang Chief Technology Officer bei Automation Anywhere, wo er die KI‑gestützten Automatisierungstechnologien für Großunternehmen vorantrieb. Zuvor war Kohli Senior Vice President of Engineering bei ThoughtSpot und bekleidete leitende Positionen bei Ericsson, darunter die Aufsicht über globale R&D‑Organisationen mit mehr als 10.000 Ingenieuren. Außerdem verbrachte er fast ein Jahrzehnt bei Citrix, wo er Plattform‑, Cloud‑Netzwerk‑, Ingenieur‑ und Betriebsinitiativen leitete. Zu Beginn seiner Karriere gründete er das Anwendungssicherheitsunternehmen Teros und arbeitete als technischer Leiter bei SGI. Neben seinen Führungspositionen hat Kohli zu Technologie‑Governance‑Initiativen über die Ethical AI Governance Group beigetragen und zuvor an der Arbeitsgruppe „Safe Systems and Technologies“ des Weltwirtschaftsforums teilgenommen.

Sauce Labs ist ein Unternehmen für Software‑Qualität und kontinuierliches Testen, das Unternehmen mit Infrastruktur und Werkzeugen zum Testen von Web‑ und Mobilanwendungen über Browser, Betriebssysteme, virtuelle Umgebungen und reale Geräte versorgt. Seine Plattform unterstützt Funktionen wie automatisiertes und manuelles Testen, visuelles Testen, Mobile‑App‑Verteilung, Fehlermeldungen sowie KI‑gestützte Test‑Erstellung und Analytik und lässt sich in gängige Continuous‑Integration‑ und Delivery‑Workflows integrieren. Sauce Labs positioniert seine Technologie zunehmend rund um AURA, seine KI‑vereinheitlichte Release‑Assurance‑Plattform, die KI‑Agenten nutzt, um Tests zu generieren, auszuführen und zu analysieren, wobei die menschliche Aufsicht während des gesamten Software‑Release‑Prozesses erhalten bleibt. Das Unternehmen gibt an, dass seine Infrastruktur mehr als 8,7 Milliarden Testausführungen und über 300 000 Unternehmens‑Nutzer unterstützt hat und dabei auf fast zwei Jahrzehnte plattformübergreifende Testdaten zurückgreift.

Bevor Sie zu Sauce Labs kamen, leiteten Sie KI‑gestützte Automatisierung bei Automation Anywhere und führten große Cloud‑ und Ingenieur‑Organisationen bei Unternehmen wie Ericsson und Citrix. Wie haben diese Erfahrungen Ihre Sicht auf das Problem der Software‑Qualität geprägt und was hat Sie überzeugt, KI‑native Release‑Assurance zu einer zentralen Priorität bei Sauce Labs zu machen?

Bei Ericsson und Citrix habe ich gesehen, wie schnell sich ein Software‑Defekt ausbreiten und die weltweite Infrastruktur beeinträchtigen kann, was erhebliche Auswirkungen auf Sicherheit, Kundenbetrieb, Vertrauen und Umsatz hat. Automation Anywhere zeigte mir, wie KI die Geschwindigkeit und Struktur der Arbeit verändert, und es wurde klar, dass das Testen an das Tempo von KI‑generierter Software angepasst werden muss. Sauce Labs war Vorreiter bei der Test‑Automatisierung, daher ist KI‑native Release‑Assurance das nächste große Problem, das wir lösen wollen.

Die Forschung von Sauce Labs hat ergeben, dass 80 % der Organisationen ein Produktions‑Incident, einen Ausfall oder einen kundenrelevanten Defekt auf KI‑generierten Code zurückführen konnten. Zeigt das hauptsächlich Schwächen im von KI erzeugten Code oder darauf, dass Unternehmen KI‑Coding‑Tools einsetzen, ohne ihre Test‑ und Governance‑Prozesse zu aktualisieren?

Die 80‑Prozent‑Zahl weist auf ein Problem im gesamten Software‑Lieferungsprozess hin. Die KI‑Branche hat mehr als eine Billion Dollar an privatem Kapital angezogen, das größtenteils darauf basiert, dass KI Unternehmen deutlich produktiver macht. Doch das Erzeugen von mehr Code schafft nur dann Wert, wenn Unternehmen von dessen Qualität und Sicherheit überzeugt sein können, bevor er in die Produktion geht.

KI‑generierter Code kann subtile Fehler und Sicherheitsprobleme einführen, und Unternehmen sind gezwungen, diesen Code durch Test‑ und Governance‑Prozesse zu schleusen, die bereits Mühe hatten, Schritt zu halten. Das erzeugt ein Billionen‑Dollar‑Ausführungsproblem: KI kann die Softwareerstellung beschleunigen, aber ohne modernisierte Release‑Assurance beschleunigt sie ebenso leicht Defekte. Jeder Bug wird irgendwann entdeckt, daher müssen Unternehmen sicherstellen, dass sie ihn finden, bevor ein Kunde oder Angreifer ihn tut.

Der Bericht stellt fest, dass Entwickler 741 % mehr Code produzieren, während die Release‑Geschwindigkeit um weniger als 20 % gestiegen ist. Was hindert Validierungssysteme daran, Schritt zu halten, und wo entsteht typischerweise der größte Engpass im Software‑Entwicklungs‑Lebenszyklus?

Die Code‑Generierung hat die Erstellung, Wartung und Analyse von Tests weit überholt. Die größten Engpässe entstehen in der Regel, nachdem der Code geschrieben wurde und im Kontext der Nutzerreise verifiziert werden muss. Das kann sehr komplex sein, oft komplexer als der Code selbst, da es End‑zu‑End‑Pfade berücksichtigen muss, die Code‑Funktionen und Objekte umfassen, wobei scheinbar kleine semantische Änderungen an einer Stelle große nachgelagerte Auswirkungen haben. Das Verfassen von Tests, die die Absicht der Anwendung korrekt und vollständig erfassen, war traditionell fast unmöglich und erfordert einen erheblichen manuellen Aufwand und Wartung. Darüber hinaus müssen Teams nach einem Testlauf und einem Fehlschlag das Problem verstehen und diagnostizieren, einschließlich der Entscheidung, ob der Fehler vom Produkt oder von einem veralteten Test stammt. Diese Arbeit hängt nach wie vor stark von manueller Überprüfung und technischem Kontext ab.

Mehr als die Hälfte der befragten Unternehmen gab zu, bewusst Software mit kritischen Defekten zu veröffentlichen, während 66 % angaben, die Qualität oder Teststandards zugunsten einer Frist zu kompromittieren. Warum akzeptieren Organisationen dieses Risiko, und was müsste sich ändern, damit Software‑Qualität zu einer geschäftlichen Priorität wird und nicht nur ein abschließender Engineering‑Checkpunkt bleibt?

Organisationen akzeptieren das Risiko, weil Release‑Ziele an unmittelbare Kunden-, Umsatz‑ und Produktverpflichtungen gebunden sind und Defekt‑Kosten häufig erst später in mehreren Teams sichtbar werden. Qualität wird erst dann zu einer geschäftlichen Priorität, wenn Führungskräfte Produktions‑Incidents, Kundenauswirkungen, Sicherheitsrisiken, Nacharbeitskosten und verzögerten Umsatz zusammen mit der Release‑Geschwindigkeit messen.

Sauce Labs positioniert AURA als eine geschlossene Plattform, die Tests erstellt, ausführt und analysiert und dabei aus jedem Release lernt. Wie unterscheidet sich das technisch und operativ von KI‑unterstützter Testgenerierung, selbstheilenden Test‑Skripten oder anderen Automatisierungstools, die bereits von Engineering‑Teams verwendet werden?

Die meisten KI‑Testtools lösen eine spezifische Aufgabe, etwa das Generieren eines Tests oder das Reparieren eines fehlerhaften Locators. AURA verbindet den gesamten Prozess, indem es die Anwendungsabsicht versteht, Tests erstellt und ausführt, Fehler analysiert und das Produktionsverhalten zurück in die Entwicklung speist. Es kann viele Änderungen automatisch bewältigen und eine Person in den Prozess einbinden, wenn sich die Bedeutung oder das erwartete Verhalten der Anwendung geändert hat. Zudem sind die von AURA erzeugten Tests stabil, das heißt, sie müssen nicht angepasst werden, wenn Änderungen, die die Semantik nicht beeinflussen, in Anwendungen, Browsern, Geräten usw. auftreten. Schließlich enthält AURA eine eigene Test‑Ausführungs‑Cloud, sodass der gesamte Prozess von Entwicklern oder Qualität‑Engineering‑Teams ausgelagert werden kann.

AURA ist darauf ausgelegt, Software gegen das „Geschäfts‑Intent“ zu prüfen. Wie wird dieser Intent definiert und in testbare Anforderungen übersetzt, wer ist für die Genehmigung verantwortlich und wie geht die Plattform mit Anforderungen um, die mehrdeutig, unvollständig oder interpretationsfähig sind?

Der Geschäfts‑Intent stammt aus Produktanforderungen, Akzeptanzkriterien, Geschäftsregeln, Nutzerreisen und der Art und Weise, wie Kunden die Anwendung tatsächlich nutzen. Produktverantwortliche definieren das erwartete Ergebnis, und Engineering‑ und Qualitätsteams übersetzen dieses Ergebnis in ein Verhalten, das das System verifizieren kann. Wenn Anforderungen unvollständig oder mehrdeutig sind, sollte AURA die Unsicherheit sichtbar machen und vor einer Änderung des erwarteten Ergebnisses eine menschliche Genehmigung einholen.

Sauce Labs berichtet, dass Unternehmen, die AURA einsetzen, 90 % weniger Produktions‑Incidents, 47 % schnellere Release‑Zyklen und eine Rückgewinnung von 38 % der Engineering‑Kapazität verzeichnen. Wie wurden diese Ergebnisse gemessen, über welchen Deploy‑Zeitraum und welche unabhängige Validierung wurde verwendet, um den Einfluss von AURA von anderen organisatorischen oder technischen Änderungen zu unterscheiden?

Bei den Unternehmenseinsätzen haben wir die Veränderungen bei Produktions‑Incidents, der Geschwindigkeit der Release‑Zyklen und der Engineering‑Kapazität gemessen, nachdem Teams AURA implementiert hatten. Diese Einsätze verzeichneten mehr als 90 % weniger Produktions‑Incidents, 47 % schnellere Release‑Zyklen und eine Rückgewinnung von 38 % der Engineering‑Kapazität, wobei die Ergebnisse unabhängig validiert wurden. Kunden wie Walmart und Keller Williams haben ebenfalls signifikante Verbesserungen bei Release‑Häufigkeit, Testabdeckung und Zykluszeit gemeldet.

Die Forschung ergab, dass 64 % der Organisationen die Qualitätssicherungs‑Mitarbeiterzahl erhöhten, obwohl die Incidents weiter stiegen. Warum können Unternehmen die Verifikationslücke nicht einfach durch die Einstellung weiterer Tester schließen, und wie erwarten Sie, dass sich die Verantwortlichkeiten von Entwicklern, Qualitätstechnikern und Site‑Reliability‑Teams ändern, wenn das Testen autonomer wird?

KI kann das Code‑Volumen viel schneller erhöhen, als ein Unternehmen seine Test‑Mitarbeiterzahl steigern kann, und das Hinzufügen von Personal erzeugt zudem mehr Übergaben und Koordination. Entwickler müssen die Intention klar definieren, Qualitätstechnikern wird es stärker um Risiko, Abdeckung und Governance gehen, und Site‑Reliability‑Teams werden das Produktionsverhalten zurück in den Release‑Prozess speisen. Agenten können wiederholte Ausführungen und Analysen in dem Umfang bewältigen, den dieses neue Entwicklungsmodell erfordert.

Wenn KI‑Agenten mehr Verantwortung für das Erstellen, Ausführen und Interpretieren von Tests übernehmen, wo müssen Menschen die Entscheidungsbefugnis behalten? Welche Arten von Unsicherheit, Sicherheitsrisiken oder potenziellen Kundenauswirkungen sollten einen Release automatisch stoppen oder eine menschliche Überprüfung auslösen?

Menschen müssen die endgültige Entscheidungsbefugnis über Releases behalten, insbesondere wenn Urteil, Kundenauswirkungen oder Geschäftsrisiken im Spiel sind. KI‑Agenten können lästige, wiederholbare und klar definierte Testaufgaben automatisieren, doch Menschen sollten Produktions‑Releases genehmigen, wann immer Code oder Testergebnisse nicht vollständig verstanden, erklärt oder reproduziert werden können. Eine Überprüfung sollte zudem obligatorisch sein, wenn Anforderungen unklar sind, Sicherheitslücken möglich sind, Drittanbieter‑Komponenten nicht ausreichend validiert wurden oder Fehler Umsatz, sensible Daten, Kundenerfahrungen oder geschäftskritische Abläufe beeinträchtigen könnten.

In solchen Situationen sollten unerklärtes Verhalten, inkonsistente Testergebnisse oder unzureichende Nachweise zur Release‑Bereitschaft den Release automatisch stoppen.

Wir haben bei Kunden Fälle beobachtet, in denen ein scheinbar „flaky“ Test, der inkonsistent bestand, häufig ignoriert wurde. Doch gut geregelte Prozesse bei einigen dieser Kunden erforderten Sorgfalt, und mit Hilfe unserer Plattform konnten sie den Fehler auf einen subtilen, aber kritischen zeitbasierten Defekt zurückführen, der bei einer Veröffentlichung zu erheblichen Auswirkungen und hohen Kosten geführt hätte.

Sie haben zudem mit der Ethical AI Governance Group und der Arbeitsgruppe „Safe Systems and Technologies“ des Weltwirtschaftsforums zusammengearbeitet. Da KI‑generierter Code und autonomes Testen immer stärker verknüpft werden, welche Governance‑Standards benötigen Unternehmen, um sicherzustellen, dass die schnellere Softwareerstellung keine neuen systemischen, Sicherheits‑ oder Verantwortungsrisiken einführt?

Je schneller KI Software erzeugen kann, desto stärker muss die Verifikations‑ und Governance‑Schicht werden. Diese Schicht besteht aus vielen Teilen. Unternehmen müssen klare Grenzen dafür setzen, was Agenten autonom entscheiden dürfen, wobei eine menschliche Überprüfung erforderlich ist, wenn Unsicherheit bezüglich Geschäfts‑Intent, Sicherheit, Compliance oder bedeutender semantischer Änderungen besteht. Sie benötigen zudem Nachvollziehbarkeit darüber, was ein Agent geändert hat, warum er es geändert hat und welche Evidenz die Release‑Entscheidung unterstützt. Letztlich sollte Governance anhand der Qualität und Vorhersagbarkeit dessen gemessen werden, was in die Produktion gelangt, etwa indem gezielt verfolgt wird, wie häufig generierter Code innerhalb von 90 Tagen nach dem Release Incidents verursacht, und nicht danach, wie viel schneller KI Code generieren kann.

Vielen Dank für das großartige Interview, Leser, die mehr erfahren möchten, sollten Sauce Labs besuchen.