Prince Kohli, Președinte și CEO al Sauce Labs – Seria de interviuri

Prince Kohli, Președinte și CEO al Sauce Labs, este un executiv veterân în tehnologie cu o experiență vastă ce acoperă inteligența artificială, software-ul enterprise, cloud computing, automatizare, rețelistică și securitate cibernetică. Înainte de a se alătura Sauce Labs în februarie 2025, a petrecut peste șase ani în funcția de Chief Technology Officer la Automation Anywhere, unde a contribuit la dezvoltarea tehnologiilor de automatizare bazate pe AI pentru mari companii. Anterior, Kohli a ocupat poziția de Senior Vice President of Engineering la ThoughtSpot și a deținut roluri de conducere senioră la Ericsson, inclusiv supravegherea organizațiilor globale de cercetare și dezvoltare, cu peste 10.000 de ingineri. De asemenea, a petrecut aproape un deceniu la Citrix, conducând inițiative de platformă, rețelistică cloud, inginerie și operațiuni. La începutul carierei, a co‑fondat compania de securitate a aplicațiilor Teros și a lucrat ca lider tehnic la SGI. Pe lângă rolurile executive, Kohli a contribuit la inițiative de guvernanță tehnologică prin Ethical AI Governance Group și a participat anterior la grupul de lucru Safe Systems and Technologies al Forumului Economic Mondial.

Sauce Labs este o companie de calitate a software‑ului și testare continuă care oferă întreprinderilor infrastructură și instrumente pentru testarea aplicațiilor web și mobile pe diferite browsere, sisteme de operare, medii virtuale și dispozitive reale. Platforma sa susține capabilități precum testarea automată și manuală, testarea vizuală, distribuirea aplicațiilor mobile, raportarea erorilor și crearea și analiza testelor alimentate de AI, integrându‑se cu fluxurile de lucru comune de integrare și livrare continuă. Sauce Labs își poziționează din ce în ce mai mult tehnologia în jurul AURA, platforma AI‑Unified Release Assurance, care folosește agenți AI pentru a genera, executa și analiza teste, menținând supravegherea umană pe parcursul procesului de lansare a software‑ului. Compania afirmă că infrastructura sa a susținut peste 8,7 miliarde de execuții de teste și peste 300.000 de utilizatori enterprise, bazându‑se pe aproape două decenii de date de testare cross‑platform.

Înainte de a te alătura Sauce Labs, ai condus automatizarea bazată pe AI la Automation Anywhere și ai gestionat mari organizații de cloud și inginerie la companii precum Ericsson și Citrix. Cum au modelat aceste experiențe perspectiva ta asupra problemei calității software‑ului și ce te-a convins să faci asigurarea lansărilor native AI o prioritate centrală la Sauce Labs?

La Ericsson și Citrix, am observat cât de rapid se poate răspândi un defect de software și cum poate afecta infrastructura globală, generând impacturi majore asupra securității, operațiunilor clienților, încrederii și veniturilor. Automation Anywhere mi-a arătat cum AI schimbă viteza și structura muncii, și a devenit evident că testarea trebuie reconstruită pentru ritmul software‑ului generat de AI. Sauce Labs a fost pionier în automatizarea testelor, așa că asigurarea lansărilor native AI este următoarea problemă majoră pe care suntem pregătiți să o rezolvăm.

Cercetarea realizată de Sauce Labs a constatat că 80 % dintre organizații au identificat un incident de producție, o întrerupere sau un defect cu impact asupra clienților provenind din cod generat de AI. Indică acest lucru în primul rând slăbiciuni în codul produs de AI sau adoptarea de către întreprinderi a instrumentelor de programare AI fără a-și actualiza procesele de testare și guvernanță?

Procentajul de 80 % indică o problemă în întregul sistem de livrare a software‑ului. Industria AI a atras peste un trilion de dolari în capital privat, mare parte bazat pe ideea că AI va face afacerile mult mai productive. Totuși, generarea unui volum mai mare de cod aduce valoare numai dacă companiile pot avea încredere în calitatea și securitatea acestuia înainte de a-l introduce în producție.

Codul generat de AI poate introduce buguri subtile și probleme de securitate, iar întreprinderile sunt obligate să supună acel cod proceselor de testare și guvernanță care deja întâmpinau dificultăți în a ține pasul. Aceasta creează o problemă de execuție de un trilion de dolari: AI poate accelera crearea de software, dar fără o asigurare a lansărilor modernizată, accelerează la fel de ușor defectele. Fiecare bug va fi în cele din urmă întâlnit, așa că companiile trebuie să se asigure că îl descoperă înainte ca un client sau un atacator să o facă.

Raportul afirmă că dezvoltatorii produc cu 741 % mai mult cod, în timp ce viteza de lansare a crescut cu mai puțin de 20 %. Ce împiedică sistemele de validare să țină pasul și unde apare de obicei cel mai mare blocaj în ciclul de viață al dezvoltării software‑ului?

Generarea de cod a depășit cu mult crearea, mentenanța și analiza testelor. Cele mai mari blocaje apar de obicei după ce codul este scris și trebuie verificat în contextul parcursului utilizatorului. Acest lucru poate fi foarte complex, adesea mai complex decât codul în sine, deoarece trebuie să țină cont de căi end‑to‑end care cuprind funcții și obiecte de cod, iar modificări aparent minore în semantică într-un loc pot genera efecte majore în aval. Crearea acestor teste astfel încât să surprindă corect și complet intenția aplicației a fost tradițional aproape imposibilă, necesitând și o cantitate foarte semnificativă de muncă manuală și mentenanță. În plus, după ce testele rulează și ceva eșuează, echipele trebuie să înțeleagă și să diagnosticheze problema, inclusiv să decidă dacă eșecul provine din produs sau dintr-un test învechit. Această muncă depinde în continuare în mare măsură de revizuirea manuală și de contextul ingineresc.

Mai mult de jumătate dintre întreprinderile chestionate au recunoscut că au lansat în mod conștient software cu defecte critice, în timp ce 66 % au declarat că au compromis calitatea sau standardele de testare pentru a respecta un termen limită. De ce acceptă organizațiile acest nivel de risc și ce ar trebui să se schimbe pentru ca calitatea software‑ului să devină o prioritate la nivel de afacere, nu doar un punct de control final al ingineriei?

Organizațiile acceptă riscul deoarece obiectivele de lansare sunt legate de angajamente imediate față de clienți, venituri și produse, iar costurile defectelor apar adesea ulterior în mai multe echipe. Calitatea devine o prioritate de afacere doar când liderii măsoară incidentele de producție, impactul asupra clienților, expunerea la securitate, costurile de refacere și veniturile întârziate, alături de viteza de lansare.

Sauce Labs poziționează AURA ca o platformă în buclă închisă care creează, execută și analizează teste în timp ce învață din fiecare lansare. Cum diferă aceasta din punct de vedere tehnic și operațional de generarea de teste asistată de AI, scripturile de testare auto‑vindecătoare sau alte instrumente de automatizare deja utilizate de echipele de inginerie?

Majoritatea instrumentelor de testare AI se concentrează pe o sarcină specifică, cum ar fi generarea unui test sau repararea unui locator defect. AURA leagă întregul proces prin înțelegerea intenției aplicației, crearea și execuția testelor, analizarea eșecurilor și retransmiterea comportamentului de producție în dezvoltare. Poate gestiona automat numeroase schimbări și poate implica o persoană în proces atunci când sensul sau comportamentul așteptat al aplicației s-a modificat. În plus, testele pe care le generează sunt stabile, adică nu necesită modificări când apar schimbări care nu afectează semantica în aplicații, browsere, dispozitive etc. În final, deoarece AURA include în sine un cloud de execuție a testelor, poate descărca întregul proces de pe un dezvoltator sau o echipă de inginerie a calității.

AURA este concepută pentru a verifica software‑ul în raport cu „intenția de business”. Cum este definită această intenție și transpusă în cerințe testabile, cine este responsabil pentru aprobarea ei și cum gestionează platforma cerințele care sunt ambigue, incomplete sau deschise la interpretare?

Intenția de business provine din cerințele produsului, criteriile de acceptare, regulile de business, parcursurile utilizatorilor și modul în care clienții utilizează efectiv aplicația. Liderii de produs definesc rezultatul așteptat, iar echipele de inginerie și calitate traduc acel rezultat în comportamente pe care sistemul le poate verifica. Când cerințele sunt incomplete sau ambigue, AURA ar trebui să evidențieze incertitudinea și să solicite aprobarea umană înainte de a modifica rezultatul așteptat.

Sauce Labs raportează că întreprinderile care utilizează AURA au înregistrat cu 90 % mai puține incidente de producție, cicluri de lansare cu 47 % mai rapide și au recâștigat 38 % din capacitatea de inginerie. Cum au fost măsurate aceste rezultate, pe ce perioade de implementare și ce validare independentă a fost folosită pentru a distinge impactul AURA de alte schimbări organizaționale sau de inginerie?

În cadrul implementărilor la nivel de întreprindere, am măsurat modificările în incidentele de producție, viteza ciclurilor de lansare și capacitatea de inginerie după ce echipele au implementat AURA. Aceste implementări au înregistrat peste 90 % mai puține incidente de producție, cicluri de lansare cu 47 % mai rapide și 38 % din capacitatea de inginerie recâștigată, cu rezultatele validate independent. Clienți precum Walmart și Keller Williams au raportat, de asemenea, creșteri semnificative în frecvența lansărilor, acoperirea testelor și timpul ciclului.

Cercetarea a constatat că 64 % dintre organizații au crescut numărul de personal în asigurarea calității, chiar și atunci când incidentele au continuat să crească. De ce nu pot întreprinderile rezolva golul de verificare simplu prin angajarea a mai mulți testeri și cum așteptați să se schimbe responsabilitățile dezvoltatorilor, inginerilor de calitate și echipelor de fiabilitate a site‑ului pe măsură ce testarea devine mai autonomă?

AI poate crește volumul de cod mult mai repede decât o companie poate crește numărul de testeri, iar adăugarea de persoane creează, de asemenea, mai multe transferuri și coordonări. Dezvoltatorii vor trebui să definească clar intenția, inginerii de calitate se vor concentra mai mult pe risc, acoperire și guvernanță, iar echipele de fiabilitate a site‑ului vor retransmite comportamentul de producție în procesul de lansare. Agenții pot gestiona execuția și analiza repetitivă la scară, așa cum necesită acest nou model de dezvoltare.

Pe măsură ce agenții AI preiau responsabilitatea de a crea, rula și interpreta teste, unde trebuie oamenilor să păstreze autoritatea decizională? Ce tipuri de incertitudine, risc de securitate sau impact potențial asupra clienților ar trebui să oprească automat o lansare sau să declanșeze o revizuire umană?

Oamenii trebuie să păstreze autoritatea finală asupra deciziilor de lansare, în special atunci când sunt implicate judecata, impactul asupra clienților sau riscul de business. Agenții AI pot automatiza sarcini de testare plictisitoare, repetitive și clar definite, dar oamenii ar trebui să aprobe lansările în producție ori de câte ori codul sau rezultatele testelor nu pot fi pe deplin înțelese, explicate sau reproduse. Revizuirea ar trebui să fie obligatorie și când cerințele sunt neclare, vulnerabilitățile de securitate sunt posibile, componentele terțe nu au fost validate adecvat sau eșecurile ar putea afecta veniturile, date sensibile, experiența clienților sau operațiunile critice pentru misiune.

În astfel de situații, comportamentul neexplicat, rezultatele de testare inconsistente sau dovezile insuficiente privind pregătirea lansării ar trebui să oprească automat lansarea.

Am observat cazuri la clienții noștri în care un test care părea „flaky”, trecând în mod inconsistent fără un model evident de eșec, era adesea ignorat. Totuși, procesele bine guvernate la anumiți dintre acești clienți au impus diligență și, cu ajutorul platformei noastre, au reușit să urmărească eșecul până la un defect subtil, dar critic, bazat pe sincronizare, care ar fi putut genera impacturi majore dacă ar fi fost lansat, cu un cost foarte ridicat.

Ai colaborat și cu Ethical AI Governance Group și cu grupul de lucru Safe Systems and Technologies al Forumului Economic Mondial. Pe măsură ce codul generat de AI și testarea autonomă devin tot mai interconectate, ce standarde de guvernanță vor avea nevoie întreprinderile pentru a se asigura că crearea mai rapidă de software nu introduce noi riscuri sistemice, de securitate sau de responsabilitate?

Cu cât AI poate crea software mai repede, cu atât stratul de verificare și guvernanță trebuie să devină mai puternic. Acest strat are multe componente. Întreprinderile trebuie să stabilească limite clare privind ceea ce pot decide agenții autonom, cu revizuire umană necesară atunci când există incertitudine privind intenția de business, securitatea, conformitatea sau o schimbare semantică semnificativă. De asemenea, ele au nevoie de trasabilitate asupra a ceea ce a modificat un agent, de ce a făcut modificarea și ce dovezi au susținut decizia de lansare. În final, guvernanța ar trebui măsurată prin calitatea și predictibilitatea a ceea ce ajunge în producție, cum ar fi monitorizarea specifică a frecvenței cu care codul generat cauzează incidente în decurs de 90 de zile de la lansare, nu prin cât de repede AI poate genera cod.

Vă mulțumim pentru interviul excelent, cititorii care doresc să afle mai multe ar trebui să viziteze Sauce Labs.