Prince Kohli, Prezes i dyrektor generalny Sauce Labs – Seria wywiadów

Prince Kohli, Prezes i dyrektor generalny Sauce Labs, jest doświadczonym menedżerem technologicznym z rozległym doświadczeniem obejmującym sztuczną inteligencję, oprogramowanie korporacyjne, przetwarzanie w chmurze, automatyzację, sieci i cyberbezpieczeństwo. Przed dołączeniem do Sauce Labs w lutym 2025 r. spędził ponad sześć lat jako dyrektor techniczny (Chief Technology Officer) w Automation Anywhere, gdzie pomógł rozwijać technologie automatyzacji oparte na AI dla dużych przedsiębiorstw. Wcześniej Kohli był starszym wiceprezesem ds. inżynierii w ThoughtSpot oraz pełnił wysokie stanowiska kierownicze w Ericsson, w tym nadzorował globalne organizacje B&R liczące ponad 10 000 inżynierów. Pracował także prawie dekadę w Citrix, prowadząc inicjatywy platform, sieci w chmurze, inżynierii i operacji. Na początku kariery współzałożył firmę bezpieczeństwa aplikacji Teros i pracował jako lider techniczny w SGI. Oprócz ról wykonawczych, Kohli przyczynia się do inicjatyw zarządzania technologią poprzez Ethical AI Governance Group oraz wcześniej uczestniczył w grupie roboczej World Economic Forum ds. bezpiecznych systemów i technologii.

Sauce Labs jest firmą zajmującą się jakością oprogramowania i ciągłym testowaniem, dostarczającą przedsiębiorstwom infrastrukturę i narzędzia do testowania aplikacji internetowych i mobilnych na przeglądarkach, systemach operacyjnych, środowiskach wirtualnych i rzeczywistych urządzeniach. Jej platforma obsługuje m.in. testowanie automatyczne i manualne, testy wizualne, dystrybucję aplikacji mobilnych, raportowanie błędów oraz tworzenie i analizę testów zasilaną AI, integrując się z typowymi procesami ciągłej integracji i dostarczania. Sauce Labs coraz częściej pozycjonuje swoją technologię wokół AURA, platformy AI‑Unified Release Assurance, która wykorzystuje agenty AI do generowania, wykonywania i analizowania testów, zachowując jednocześnie nadzór człowieka przez cały proces wydania oprogramowania. Firma podaje, że jej infrastruktura obsłużyła ponad 8,7 miliarda uruchomień testów i ponad 300 000 użytkowników korporacyjnych, bazując na prawie dwóch dekadach danych z testów wieloplatformowych.

Przed dołączeniem do Sauce Labs prowadziłeś automatyzację napędzaną AI w Automation Anywhere oraz zarządzałeś dużymi organizacjami chmurowymi i inżynieryjnymi w firmach takich jak Ericsson i Citrix. Jak te doświadczenia ukształtowały Twoje spojrzenie na problem jakości oprogramowania i co przekonało Cię, by uczynić AI‑natywne zapewnienie wydania centralnym priorytetem w Sauce Labs?

W Ericsson i Citrix zobaczyłem, jak szybko defekt oprogramowania może rozprzestrzenić się i wpłynąć na infrastrukturę na całym świecie, powodując poważne konsekwencje dla bezpieczeństwa, operacji klientów, zaufania i przychodów. Automation Anywhere pokazało mi, jak AI zmienia tempo i strukturę pracy, i stało się jasne, że testowanie musi zostać przebudowane, aby nadążać za tempem tworzenia oprogramowania generowanego przez AI. Sauce Labs zrewolucjonizowało automatyzację testów, więc AI‑natywne zapewnienie wydania jest następnym dużym wyzwaniem, które jesteśmy gotowi rozwiązać.

Badania Sauce Labs wykazały, że 80 % organizacji zidentyfikowało incydent produkcyjny, awarię lub defekt wpływający na klienta, którego przyczyną był kod generowany przez AI. Czy wskazuje to przede wszystkim na słabości w kodzie tworzonym przez AI, czy na fakt, że przedsiębiorstwa przyjmują narzędzia kodowania AI bez aktualizacji procesów testowania i zarządzania?

Wskaźnik 80 % wskazuje na problem w całym systemie dostarczania oprogramowania. Przemysł AI przyciągnął ponad bilion dolarów prywatnego kapitału, w dużej mierze opierając się na założeniu, że AI znacząco zwiększy produktywność firm. Jednak generowanie większej ilości kodu przynosi wartość tylko wtedy, gdy firmy mogą mieć pewność co do jego jakości i bezpieczeństwa, zanim trafi on do produkcji.

Kod generowany przez AI może wprowadzać subtelne błędy i luki bezpieczeństwa, a przedsiębiorstwa są zmuszone wprowadzać ten kod do procesów testowania i zarządzania, które już i tak mają trudności z nadążaniem. Powoduje to problem o wartości bilionów dolarów: AI może przyspieszyć tworzenie oprogramowania, ale bez zmodernizowanego zapewnienia wydania równie łatwo przyspiesza powstawanie defektów. Każdy błąd w końcu zostanie wykryty, więc firmy muszą go znaleźć, zanim napotka go klient lub atakujący.

Raport stwierdza, że deweloperzy produkują o 741 % więcej kodu, podczas gdy tempo wydania wzrosło o mniej niż 20 %. Co uniemożliwia systemom walidacji nadążanie i gdzie najczęściej pojawia się największe wąskie gardło w cyklu życia oprogramowania?

Generowanie kodu wyprzedziło tworzenie, utrzymanie i analizę testów. Największe wąskie gardła zwykle pojawiają się po napisaniu kodu i konieczności jego weryfikacji w kontekście ścieżki użytkownika. Może to być bardzo złożone, często bardziej złożone niż sam kod, ponieważ musi uwzględniać ścieżki end‑to‑end obejmujące funkcje i obiekty kodu, przy czym drobne zmiany w semantyce w jednym miejscu wywołują duże skutki w dalszych etapach. Tworzenie testów, które prawidłowo i w pełni odzwierciedlają intencję aplikacji, było tradycyjnie prawie niemożliwe i wymagało ogromnej ilości ręcznej pracy i utrzymania. Ponadto, po uruchomieniu testów i wystąpieniu niepowodzenia, zespoły muszą zrozumieć i zdiagnozować problem, w tym zdecydować, czy niepowodzenie wynika z produktu, czy z przestarzałego testu. Ta praca wciąż w dużej mierze zależy od ręcznej analizy i kontekstu inżynieryjnego.

Ponad połowa ankietowanych przedsiębiorstw przyznała, że świadomie wypuszcza oprogramowanie z krytycznymi defektami, a 66 % przyznało, że obniżyło standardy jakości lub testowania, aby dotrzymać terminu. Dlaczego organizacje akceptują tak wysokie ryzyko i co musiałoby się zmienić, aby jakość oprogramowania stała się priorytetem biznesowym, a nie jedynie końcowym punktem kontrolnym inżynierii?

Organizacje akceptują ryzyko, ponieważ cele wydania są powiązane z natychmiastowymi zobowiązaniami wobec klientów, przychodów i produktów, a koszty defektów często ujawniają się później w różnych zespołach. Jakość staje się priorytetem biznesowym dopiero wtedy, gdy liderzy mierzą incydenty produkcyjne, wpływ na klientów, narażenie na zagrożenia bezpieczeństwa, koszty poprawek i opóźnione przychody wraz z prędkością wydania.

Sauce Labs pozycjonuje AURA jako zamkniętą platformę, która tworzy, wykonuje i analizuje testy, ucząc się przy każdym wydaniu. Jak to różni się technicznie i operacyjnie od AI‑wspomaganego generowania testów, samonaprawiających się skryptów testowych lub innych narzędzi automatyzacji już używanych przez zespoły inżynieryjne?

Większość narzędzi AI do testowania rozwiązuje konkretną czynność, np. generowanie testu lub naprawę zepsutego lokalizatora. AURA łączy cały proces, rozumie intencję aplikacji, tworzy i wykonuje testy, analizuje niepowodzenia i zwraca zachowanie produkcyjne do rozwoju. Może automatycznie obsługiwać wiele zmian i wciągać człowieka do procesu, gdy zmieni się znaczenie aplikacji lub oczekiwane zachowanie. Dodatkowo generowane przez nią testy są stabilne, co oznacza, że nie wymagają modyfikacji przy zmianach nie wpływających na semantykę w aplikacjach, przeglądarkach, urządzeniach itp. Wreszcie, ponieważ AURA zawiera własną chmurę wykonawczą testów, może odciążyć cały proces od programisty lub zespołu inżynierii jakości.

AURA ma na celu weryfikację oprogramowania pod kątem „intencji biznesowej”. Jak ta intencja jest definiowana i przekształcana w wymagania testowalne, kto jest odpowiedzialny za jej zatwierdzenie i jak platforma radzi sobie z wymaganiami niejasnymi, niekompletnymi lub otwartymi na interpretację?

Intencja biznesowa pochodzi z wymagań produktowych, kryteriów akceptacji, reguł biznesowych, ścieżek użytkownika oraz sposobu, w jaki klienci faktycznie korzystają z aplikacji. Liderzy produktu definiują oczekiwany rezultat, a zespoły inżynieryjne i jakości przekształcają ten rezultat w zachowanie, które system może zweryfikować. Gdy wymagania są niekompletne lub niejasne, AURA powinna uwidocznić niepewność i poprosić o zatwierdzenie człowieka przed zmianą oczekiwanego wyniku.

Sauce Labs informuje, że przedsiębiorstwa korzystające z AURA odnotowały o 90 % mniej incydentów produkcyjnych, 47 % szybsze cykle wydań i odzyskały 38 % pojemności inżynieryjnej. Jak te wyniki zostały zmierzone, w jakich okresach wdrożeń i jaką niezależną weryfikację zastosowano, aby odróżnić wpływ AURA od innych zmian organizacyjnych lub inżynieryjnych?

W ramach wdrożeń w przedsiębiorstwach mierzyliśmy zmiany w incydentach produkcyjnych, szybkości cykli wydań i pojemności inżynieryjnej po wprowadzeniu AURA. Te wdrożenia wykazały ponad 90 % mniej incydentów produkcyjnych, 47 % szybsze cykle wydań i 38 % odzyskanej pojemności inżynieryjnej, a wyniki zostały niezależnie zweryfikowane. Klienci tacy jak Walmart i Keller Williams również zgłosili znaczące zyski w częstotliwości wydań, pokryciu testów i czasie cyklu.

Badania wykazały, że 64 % organizacji zwiększyło liczbę pracowników ds. zapewnienia jakości, mimo że incydenty nadal rosły. Dlaczego przedsiębiorstwa nie mogą po prostu rozwiązać luki weryfikacyjnej, zatrudniając więcej testerów, i jak przewidujesz zmianę ról deweloperów, inżynierów jakości i zespołów site reliability w miarę jak testowanie stanie się bardziej autonomiczne?

AI może zwiększyć wolumen kodu znacznie szybciej niż firma może zwiększyć liczbę testerów, a dodawanie ludzi generuje dodatkowe przekazy i koordynację. Deweloperzy będą musieli jasno definiować intencję, inżynierowie jakości skoncentrują się bardziej na ryzyku, pokryciu i zarządzaniu, a zespoły site reliability będą zwracać zachowanie produkcyjne do procesu wydania. Agenci będą mogli obsługiwać powtarzalne wykonania i analizy w skali wymaganej przez ten nowy model rozwoju.

Gdy agenci AI przejmą odpowiedzialność za tworzenie, uruchamianie i interpretację testów, w jakich obszarach ludzie muszą zachować decyzyjny autorytet? Jakie rodzaje niepewności, ryzyka bezpieczeństwa lub potencjalnego wpływu na klienta powinny automatycznie zatrzymać wydanie lub wywołać przegląd człowieka?

Ludzie muszą zachować ostateczny autorytet nad decyzjami o wydaniu, szczególnie gdy w grę wchodzi osąd, wpływ na klienta lub ryzyko biznesowe. Agenci AI mogą automatyzować nudne, powtarzalne i jasno określone zadania testowe, ale ludzie powinni zatwierdzać wydania produkcyjne, gdy kod lub wyniki testów nie mogą być w pełni zrozumiane, wyjaśnione lub odtworzone. Przegląd powinien być również obowiązkowy, gdy wymagania są niejasne, istnieje możliwość luk bezpieczeństwa, komponenty zewnętrzne nie zostały wystarczająco zweryfikowane lub niepowodzenia mogą wpłynąć na przychody, wrażliwe dane, doświadczenie klienta lub operacje krytyczne.

W takich sytuacjach niewyjaśnione zachowanie, niespójne wyniki testów lub niewystarczające dowody gotowości do wydania powinny automatycznie zatrzymać wydanie.

Widzieliśmy przypadki u naszych klientów, w których test wydawał się „chwiejny”, przechodząc niekonsekwentnie bez widocznego wzorca niepowodzeń, i często był ignorowany. Jednak dobrze zarządzane procesy u niektórych z tych klientów wymagały due diligence i dzięki naszej platformie udało się zlokalizować niepowodzenie do subtelnego, lecz krytycznego defektu opartego na synchronizacji, który mógłby spowodować poważne skutki po wydaniu, generując bardzo wysokie koszty.

Współpracowałeś również z Ethical AI Governance Group oraz grupą roboczą World Economic Forum ds. bezpiecznych systemów i technologii. W miarę jak kod generowany przez AI i autonomiczne testowanie stają się coraz bardziej powiązane, jakie standardy zarządzania będą potrzebne przedsiębiorstwom, aby zapewnić, że szybsze tworzenie oprogramowania nie wprowadza nowych ryzyk systemowych, bezpieczeństwa lub odpowiedzialności?

Im szybciej AI może tworzyć oprogramowanie, tym silniejsza musi być warstwa weryfikacji i zarządzania. Warstwa ta ma wiele elementów. Przedsiębiorstwa muszą jasno określić granice, w jakich agenci mogą decydować autonomicznie, wymagając przeglądu człowieka, gdy istnieje niepewność co do intencji biznesowej, bezpieczeństwa, zgodności lub istotnej zmiany semantycznej. Muszą także zapewnić możliwość śledzenia, co agent zmienił, dlaczego to zmienił i jakie dowody wspierały decyzję o wydaniu. Ostatecznie zarządzanie powinno być mierzone jakość i przewidywalnością tego, co trafia do produkcji, na przykład poprzez śledzenie, jak często generowany kod powoduje incydenty w ciągu 90 dni od wydania, a nie tym, jak szybciej AI może generować kod.

Dziękujemy za wywiad, czytelnicy, którzy chcą dowiedzieć się więcej, powinni odwiedzić Sauce Labs.