Prince Kohli, prezident a generální ředitel společnosti Sauce Labs – série rozhovorů

Prince Kohli, prezident a generální ředitel společnosti Sauce Labs, je zkušený technologický manažer s rozsáhlou praxí v oblasti umělé inteligence, podnikových softwarových řešení, cloud computingu, automatizace, sítí a kybernetické bezpečnosti. Před nástupem do Sauce Labs v únoru 2025 strávil více než šest let jako technický ředitel (Chief Technology Officer) společnosti Automation Anywhere, kde pomáhal rozvíjet technologie automatizace řízené AI pro velké podniky. Dříve působil Kohli jako senior viceprezident pro inženýrství ve společnosti ThoughtSpot a zastával seniorní vedoucí pozice ve společnosti Ericsson, včetně dohledu nad globálními výzkumnými a vývojovými (R&D) organizacemi s více než 10 000 inženýry. Také téměř deset let pracoval ve společnosti Citrix, kde vedl iniciativy v oblasti platformy, cloudových sítí, inženýrství a provozu. Na začátku své kariéry spoluzaložil společnost zaměřenou na bezpečnost aplikací Teros a pracoval jako technický vedoucí ve společnosti SGI. Vedle svých výkonných rolí přispěl Kohli k iniciativám v oblasti správy technologií prostřednictvím Ethical AI Governance Group a dříve se podílel na pracovní skupině Safe Systems and Technologies Světového ekonomického fóra.

Sauce Labs je společnost zaměřená na kvalitu softwaru a kontinuální testování, která poskytuje podnikom infrastrukturu a nástroje pro testování webových a mobilních aplikací napříč prohlížeči, operačními systémy, virtuálními prostředími i reálnými zařízeními. Její platforma podporuje funkce jako automatizované i manuální testování, vizuální testování, distribuci mobilních aplikací, hlášení chyb a tvorbu testů a analytiku poháněnou AI, a integruje se se standardními workflow kontinuální integrace a doručování. Sauce Labs čím dál více staví svou technologii kolem AURA, platformy AI-Unified Release Assurance, která využívá AI agenty k tvorbě, spouštění a analýze testů při zachování lidského dohledu během celého procesu vydávání softwaru. Společnost uvádí, že její infrastruktura podpořila více než 8,7 miliardy testovacích provedení a přes 300 000 podnikových uživatelů, čerpajíc z téměř dvou desetiletí dat o cross‑platformním testování.

Než jste nastoupil do Sauce Labs, vedl jste AI‑řízenou automatizaci ve společnosti Automation Anywhere a řídil významné cloudové a inženýrské organizace ve firmách jako Ericsson a Citrix. Jak tyto zkušenosti formovaly váš pohled na problém kvality softwaru a co vás přesvědčilo učinit AI‑nativní zajištění vydání hlavní prioritou ve Sauce Labs?

V Ericsson a Citrix jsem viděl, jak rychle se může chyba v softwaru rozšířit a ovlivnit celosvětovou infrastrukturu, což má zásadní dopad na bezpečnost, provoz zákazníků, důvěru i příjmy. Automation Anywhere mi ukázala, jak AI mění rychlost a strukturu práce, a bylo jasné, že testování musí být přestavěno pro tempo softwaru generovaného AI. Sauce Labs byla průkopníkem v automatizaci testů, takže AI‑nativní zajištění vydání je další hlavní problém, který jsme vytvořeni řešit.

Sauce Labs’ research zjistila, že 80 % organizací spojilo incident v produkci, výpadek nebo závadu dopadající na zákazníky s kódem vytvořeným AI. Ukazuje to především na slabiny samotného kódu, nebo na to, že podniky zavádějí AI nástroje pro programování, aniž by aktualizovaly testování a řízení?

Číslo 80 % poukazuje na problém v celém systému dodávky softwaru. AI průmysl přilákal více než bilion dolarů soukromého kapitálu, z velké části založeného na předpokladu, že AI výrazně zvýší produktivitu firem. Avšak generování většího množství kódu přináší hodnotu jen tehdy, když si společnosti mohou být jisti jeho kvalitou a bezpečností, než jej uvedou do produkce.

Kód generovaný AI může zavádět jemné chyby a bezpečnostní problémy a podniky jsou nuceny tento kód prosazovat skrze testovací a řídící procesy, které už měly potíže držet krok. To vytváří trilionový problém s realizací: AI může urychlit tvorbu softwaru, ale bez modernizovaného zajištění vydání stejně snadno urychluje i chyby. Každá chyba se nakonec objeví, takže firmy musí zajistit, že ji najdou dříve, než ji objeví zákazník nebo útočník.

Zpráva uvádí, že vývojáři vytvářejí o 741 % více kódu, zatímco tempo vydávání verzí vzrostlo o méně než 20 %. Co brání validačním systémům držet krok a kde obvykle vzniká největší úzké hrdlo v životním cyklu vývoje softwaru?

Generování kódu předběhlo tvorbu, údržbu a analýzu testů. Největší úzká místa se obvykle objevují po napsání kódu, kdy je třeba jej ověřit v kontextu uživatelské cesty. To může být často velmi složité, často složitější než samotný kód, protože je třeba zohlednit end‑to‑end cesty, které zahrnují funkce a objekty kódu, přičemž zdánlivě drobné změny v semantice na jednom místě mohou mít velké následky. Vytvořit tyto testy tak, aby správně a úplně zachytily záměr aplikace, bylo tradičně téměř nemožné a vyžaduje značné množství manuální práce a údržby. Navíc po spuštění testů a výskytu selhání musí týmy pochopit a diagnostikovat problém, včetně rozhodnutí, zda selhání pochází z produktu nebo ze zastaralého testu. Tato práce stále silně závisí na manuálním přezkoumání a kontextu inženýrství.

Více než polovina dotázaných podniků přiznala, že vědomě vydává software s kritickými chybami, a 66 % uvedlo, že kvůli termínu slevilo ze standardů kvality či testování. Proč organizace přijímají takovou míru rizika a co se musí změnit, aby se kvalita softwaru stala prioritou celé firmy, nikoli jen závěrečnou technickou kontrolou?

Více než polovina dotazovaných podniků přiznala, že vědomě uvádí software s kritickými chybami, zatímco 66 % uvedlo, že snížilo kvalitu nebo testovací standardy, aby splnili termín. Proč organizace akceptují takovou úroveň rizika a co by se muselo změnit, aby se kvalita softwaru stala obchodní prioritou spíše než posledním kontrolním bodem inženýrství?

Organizace přijímají riziko, protože cíle vydání jsou spojeny s okamžitými závazky vůči zákazníkům, příjmům a produktům, a náklady na chyby se často projeví později v několika týmech. Kvalita se stane obchodní prioritou jen tehdy, když vedoucí měří incidenty v produkci, dopad na zákazníky, bezpečnostní expozice, náklady na opravy a zpožděné příjmy vedle rychlosti vydání.

Sauce Labs představuje AURA jako platformu s uzavřenou zpětnovazební smyčkou, která vytváří, provádí a analyzuje testy a učí se z každého vydání. Jak se technicky a provozně liší od generování testů s pomocí AI, samoopravných testovacích skriptů nebo jiných automatizačních nástrojů, které technické týmy již používají?

Většina AI testovacích nástrojů řeší konkrétní úkol, například generování testu nebo opravu poškozeného lokátoru. AURA propojuje celý proces tím, že rozumí záměru aplikace, vytváří a spouští testy, analyzuje selhání a vrací chování v produkci zpět do vývoje. Dokáže automaticky zvládat mnoho změn a zapojit člověka do procesu, když se změní význam nebo očekávané chování aplikace. Navíc testy, které generuje, jsou stabilní, což znamená, že je není nutné upravovat, když dochází ke změnám, které neovlivňují sémantiku v aplikacích, prohlížečích, zařízeních a podobně. Nakonec, protože AURA obsahuje vlastní cloud pro spouštění testů, může celý proces odlehčit vývojáři nebo týmu kvality.

AURA má ověřovat software podle „obchodního záměru“. Jak se tento záměr definuje a převádí na testovatelné požadavky, kdo jej schvaluje a jak platforma nakládá s požadavky, které jsou nejednoznačné, neúplné nebo připouštějí různé výklady?

Obchodní záměr vychází z požadavků na produkt, akceptačních kritérií, obchodních pravidel, uživatelských cest a způsobu, jakým zákazníci aplikaci skutečně používají. Vedoucí produktů definují očekávaný výsledek a inženýrské a kvalitní týmy tento výsledek převádějí na chování, které systém může ověřit. Když jsou požadavky neúplné nebo nejasné, AURA by měla upozornit na nejistotu a požádat o lidské schválení před změnou očekávaného výsledku.

Sauce Labs uvádí, že podniky používající AURA zaznamenaly o 90 % méně incidentů v produkci, o 47 % rychlejší cykly vydávání a získaly zpět 38 % technické kapacity. Jak se tyto výsledky měřily, za jak dlouhá období nasazení a jaké nezávislé ověření odlišilo dopad AURA od ostatních organizačních či technických změn?

V rámci podnikového nasazení jsme měřili změny v incidentách v produkci, rychlosti cyklu vydání a kapacitě inženýrství po zavedení AURA. Tato nasazení zaznamenala více než 90 % méně incidentů v produkci, 47 % rychlejší cykly vydání a 38 % získané kapacity inženýrství, přičemž výsledky byly nezávisle ověřeny. Zákazníci jako Walmart a Keller Williams také hlásili významné zlepšení frekvence vydání, pokrytí testy a doby cyklu.

Výzkum zjistil, že 64 % organizací zvýšilo počet pracovníků zajišťujících kvalitu, i když incidentů nadále přibývalo. Proč nemohou podniky vyřešit mezeru v ověřování pouhým náborem dalších testerů a jak se podle vás změní odpovědnosti vývojářů, specialistů kvality a týmů spolehlivosti s tím, jak bude testování autonomnější?

AI může zvýšit objem kódu mnohem rychleji, než může společnost zvýšit počet testerů, a přidání lidí také vytváří více předání a koordinace. Vývojáři budou muset jasně definovat záměr, inženýři kvality se budou více soustředit na riziko, pokrytí a řízení, a týmy pro spolehlivost budou vracet chování v produkci zpět do procesu vydání. Agenti mohou zvládat opakované spouštění a analýzu v rozsahu, který tento nový vývojový model vyžaduje.

Jak AI agenti přebírají odpovědnost za vytváření, spouštění a interpretaci testů, kde si lidé musí zachovat rozhodovací pravomoc? Jaké druhy nejistoty, bezpečnostních rizik nebo možného dopadu na zákazníky by měly automaticky zastavit vydání nebo vyvolat lidskou kontrolu?

Lidé musí zachovat konečnou pravomoc nad rozhodnutími o vydání, zejména když jde o úsudek, dopad na zákazníka nebo obchodní riziko. AI agenti mohou automatizovat nudné, opakující se a jasně definované testovací úkoly, ale lidé by měli schvalovat vydání do produkce vždy, když kód nebo výsledky testů nelze plně pochopit, vysvětlit nebo reprodukovat. Kontrola by měla být také povinná, když jsou požadavky nejasné, existuje možnost bezpečnostních zranitelností, komponenty třetích stran nebyly dostatečně ověřeny nebo selhání by mohla ovlivnit příjmy, citlivá data, zkušenost zákazníka nebo kritické operace.

V takových situacích by mělo automaticky zastavit vydání nevysvětlené chování, nekonzistentní výsledky testů nebo nedostatečné důkazy o připravenosti k vydání.

Viděli jsme u našich zákazníků případy, kdy test, který se jevil jako „nestálý“, procházel nepravidelně bez zjevného vzoru selhání, byl v mnoha případech ignorován. Avšak dobře řízené procesy u některých z těchto zákazníků vyžadovaly náležitou péči a s pomocí naší platformy dokázaly sledovat selhání až k jemné, ale kritické časové chybě, která by při vydání mohla způsobit značné dopady a vysoké náklady.

Pracoval jste také s Ethical AI Governance Group a pracovní skupinou Světového ekonomického fóra Safe Systems and Technologies. Jaké standardy řízení budou podniky potřebovat s hlubším propojením kódu generovaného AI a autonomního testování, aby rychlejší tvorba softwaru nepřinesla nová systémová či bezpečnostní rizika nebo nejasnou odpovědnost?

Čím rychleji AI dokáže vytvářet software, tím silnější musí být vrstva ověřování a řízení. Tato vrstva má mnoho částí. Podniky musí mít jasně vymezené hranice toho, co mohou agenti rozhodovat autonomně, a lidské přezkoumání je vyžadováno, když existuje nejistota ohledně obchodního záměru, bezpečnosti, souladu nebo významné sémantické změny. Také potřebují sledovatelnost toho, co agent změnil, proč to změnil a jaké důkazy podpořily rozhodnutí o vydání. Nakonec by mělo být řízení měřeno kvalitou a předvídatelností toho, co se dostane do produkce, například konkrétním sledováním, jak často generovaný kód způsobí incidenty během 90 dnů od vydání, a nikoli tím, jak rychleji AI dokáže kód generovat.

Děkujeme za skvělý rozhovor, čtenáři, kteří se chtějí dozvědět více, by měli navštívit Sauce Labs.

Zdroje původního článku: businesswire.com [1]