Prince Kohli, Sauce Labsin presidentti ja toimitusjohtaja – Haastattelusarja

Prince Kohli, Sauce Labsin presidentti ja toimitusjohtaja, on kokenut teknologiaylinjohtaja, jonka laaja kokemus kattaa tekoälyn, yritysohjelmistot, pilvipalvelut, automaation, verkottumisen ja kyberturvallisuuden. Ennen kuin hän liittyi Sauce Labsiin helmikuussa 2025, hän vietti yli kuusi vuotta Automation Anywheren teknologiajohtajana, jossa hän auttoi edistämään suuryrityksille suunnattuja tekoälypohjaisia automaatioteknologioita. Aikaisemmin Kohli toimi ThoughtSpotin vanhempana varapuheenjohtajana insinööritoiminnassa ja hänellä oli johtavia tehtäviä Ericssonilla, mukaan lukien globaalien R&D‑organisaatioiden, joissa työskentelee yli 10 000 insinööriä, valvonta. Hän työskenteli lähes vuosikymmenen ajan Citrixilla johtaen alustan, pilviväyläverkot, insinööri- ja operatiivisia aloitteita. Uransa alussa hän oli mukana perustamassa sovellusturvallisuusyritystä Teros ja toimi teknisenä johtajana SGI:ssä. Johtotehtäviensä ohella Kohli on osallistunut teknologiagovernanssihankkeisiin Ethical AI Governance Groupin kautta ja aiemmin toiminut World Economic Forumin Safe Systems and Technologies -työryhmässä.

Sauce Labs on ohjelmistolaadun ja jatkuvan testauksen yritys, joka tarjoaa organisaatioille infrastruktuuria ja työkaluja verkkosovellusten ja mobiilisovellusten testaamiseen eri selaimilla, käyttöjärjestelmillä, virtuaaliympäristöissä ja todellisilla laitteilla. Sen alusta tukee ominaisuuksia, kuten automatisoitu ja manuaalinen testaus, visuaalitestaus, mobiilisovellusten jakelu, virheraportointi sekä tekoälypohjainen testien kirjoittaminen ja analytiikka, ja se integroituu tavallisiin jatkuvan integraation ja toimituksen työnkulkuihin. Sauce Labs asettaa yhä enemmän teknologiansa AURA:n, sen AI-Unified Release Assurance -alustan, ympärille, joka käyttää tekoälyagentteja testien luomiseen, suorittamiseen ja analysointiin säilyttäen ihmisen valvonnan koko ohjelmistojulkaisuprosessin ajan. Yritys kertoo, että sen infrastruktuuri on tukenut yli 8,7 miljardia testisuoritusta ja yli 300 000 yrityskäyttäjää, hyödyntäen lähes kahta vuosikymmentä poikkialustatestausdataa.

Ennen liittymistäsi Sauce Labsiin johdit tekoälypohjaista automaatiota Automation Anywheressa ja johdit suuria pilvi- ja insinööritoimintoja yrityksissä, kuten Ericsson ja Citrix. Miten nämä kokemukset ovat muokanneet näkemystäsi ohjelmistolaadun ongelmasta, ja mikä vakuutti sinut tekemään AI‑natiivisesta julkaisun varmistuksesta keskeisen prioriteetin Sauce Labsissa?

Ericssonilla ja Citrixilla huomasin, kuinka nopeasti ohjelmistovirhe voi levitä ja vaikuttaa maailmanlaajuiseen infrastruktuuriin, aiheuttaen merkittäviä vaikutuksia turvallisuuteen, asiakkaiden toimintaan, luottamukseen ja liikevaihtoon. Automation Anywhere osoitti minulle, miten tekoäly muuttaa työn nopeutta ja rakennetta, ja kävi selväksi, että testaus on rakennettava uudelleen tekoälyn tuottaman ohjelmiston vauhdille. Sauce Labs oli testiautomaation edelläkävijä, joten AI‑natiivinen julkaisun varmistus on seuraava suuri haaste, jonka ratkaisemiseen olemme suunniteltu.

Sauce Labsin tutkimus havaitsi, että 80 % organisaatioista on jäljittänyt tuotantotapahtuman, katkoksen tai asiakasta vaikuttavan virheen AI‑luotuun koodiin. Viittaako tämä ensisijaisesti tekoälyn tuottaman koodin heikkouksiin vai yritysten AI‑koodausvälineiden käyttöönottoon ilman testaus- ja hallintaprosessien päivittämistä?

80 %:n luku osoittaa ongelman koko ohjelmistotoimitusketjussa. AI‑ala on houkutellut yli biljoona dollaria yksityistä pääomaa, josta suuri osa perustuu oletukseen, että tekoäly tekee yrityksistä merkittävästi tuottavampia. Koodin tuottaminen lisää arvoa vain, jos yritykset voivat olla varmoja sen laadusta ja turvallisuudesta ennen kuin se siirretään tuotantoon.

Tekoälyn luoma koodi voi sisältää hienovaraisia virheitä ja turvallisuusongelmia, ja yritykset joutuvat pakottamaan tämän koodin testaus- ja hallintaprosesseihin, jotka jo kamppailivat pysyäkseen mukana. Tämä aiheuttaa biljoonaluokan toteutusongelman: AI voi nopeuttaa ohjelmiston luomista, mutta ilman modernisoitua julkaisun varmistusta se nopeuttaa yhtä helposti virheitä. Jokainen virhe tulee lopulta esiin, joten yritysten on varmistettava, että ne löytävät sen ennen asiakasta tai hyökkääjää.

Raportti kertoo, että kehittäjät tuottavat 741 % enemmän koodia, kun taas julkaisunopeus on kasvanut alle 20 %. Mikä estää validointijärjestelmiä pysymästä tahdissa, ja missä suurin pullonkaula tavallisesti ilmenee ohjelmistokehityksen elinkaarella?

Koodin generointi on edennyt paljon testien luomisen, ylläpidon ja analyysin edelle. Suurimmat pullonkaulat ilmenevät yleensä sen jälkeen, kun koodi on kirjoitettu ja se täytyy tarkistaa käyttäjäpolun kontekstissa. Tämä voi olla hyvin monimutkaista, usein monimutkaisempaa kuin itse koodi, koska sen on otettava huomioon päästä‑päähän -polut, jotka kattavat koodifunktiot ja -objektit, ja näennäisesti vähäiset semanttiset muutokset yhdessä paikassa voivat aiheuttaa suuria vaikutuksia myöhemmin. Tällaisen testin kirjoittaminen niin, että se täysin ja oikein tallentaa sovelluksen tarkoituksen, on perinteisesti ollut lähes mahdotonta, ja se vaatii merkittävän määrän manuaalista työtä ja ylläpitoa. Lisäksi, kun testit ajetaan ja jokin epäonnistuu, tiimien on ymmärrettävä ja diagnosoitava ongelma, mukaan lukien päätettävä, onko epäonnistuminen tuotteen vai vanhentuneen testin aiheuttama. Tämä työ riippuu edelleen voimakkaasti manuaalisesta tarkastuksesta ja insinööri‑kontekstista.

Yli puolet kyselyyn vastanneista yrityksistä myönsi tietoisesti julkaisseensa ohjelmistoja kriittisillä virheillä, kun taas 66 % kertoi heikentävänsä laatua tai testausstandardeja aikataulun saavuttamiseksi. Miksi organisaatiot hyväksyvät tällaisen riskitason, ja mitä tulisi muuttua, jotta ohjelmistolaatu nousisi liiketoimintatason prioriteetiksi eikä vain viimeiseksi insinöörivaiheeksi?

Organisaatiot hyväksyvät riskin, koska julkaisutavoitteet liittyvät välittömiin asiakas-, liike‑ ja tuotesitoumuksiin, ja virhekustannukset ilmenevät usein myöhemmin useiden tiimien kesken. Laadusta tulee liiketoiminnan prioriteetti vain, kun johtajat mittaavat tuotantotapahtumia, asiakasvaikutuksia, turvallisuusaltistuksia, uudelleentyöstökustannuksia ja viivästynyttä liikevaihtoa yhdessä julkaisunopeuden kanssa.

Sauce Labs asettaa AURA:n suljetun silmukan alustaksi, joka kirjoittaa, suorittaa ja analysoi testejä oppien jokaisesta julkaisusta. Miten tämä eroaa teknisesti ja operatiivisesti AI‑avusteisesta testin generoinnista, itseparantavista testiskripteistä tai muista automaatiotyökaluista, joita insinööritiimit jo käyttävät?

Useimmat AI‑testausvälineet keskittyvät tiettyyn tehtävään, kuten testin luomiseen tai rikkoutuneen paikantimen korjaamiseen. AURA yhdistää koko prosessin ymmärtämällä sovelluksen tarkoituksen, kirjoittamalla ja suorittamalla testit, analysoimalla epäonnistumiset ja syöttämällä tuotantokäyttäytymisen takaisin kehitykseen. Se voi automaattisesti käsitellä monia muutoksia ja tuoda ihmisen prosessiin, kun sovelluksen merkitys tai odotettu käyttäytyminen on muuttunut. Lisäksi sen luomat testit ovat vakaita, eli niitä ei tarvitse muokata, kun sovelluksissa, selaimissa, laitteissa tai vastaavissa tapahtuu muutoksia, jotka eivät vaikuta semantiikkaan. Lopuksi, koska AURA sisältää sisäisesti testien suorituksen pilvipalvelun, se pystyy siirtämään koko prosessin pois kehittäjän tai laadunvarmistustiimin vastuulta.

AURA on suunniteltu varmistamaan ohjelmisto “liiketoimintatarkoituksen” mukaisesti. Miten tämä tarkoitus määritellään ja käännetään testattaviksi vaatimuksiksi, kuka on vastuussa sen hyväksymisestä, ja miten alusta käsittelee vaatimuksia, jotka ovat epäselviä, puutteellisia tai tulkinnanvaraisia?

Liiketoimintatarkoitus perustuu tuotteen vaatimuksiin, hyväksymiskriteereihin, liiketoimintasääntöihin, käyttäjäpolkuihin ja siihen, miten asiakkaat todellisuudessa käyttävät sovellusta. Tuotejohtajat määrittelevät odotetun lopputuloksen, ja insinööri‑ ja laadunvarmistustiimit kääntävät sen käyttäytymiseksi, jonka järjestelmä voi tarkistaa. Kun vaatimukset ovat puutteellisia tai epäselviä, AURA tuo esiin epävarmuuden ja pyytää ihmisen hyväksynnän ennen odotetun tuloksen muuttamista.

Sauce Labs raportoi, että AURAa käyttävät yritykset ovat kokeneet 90 % vähemmän tuotantotapahtumia, 47 % nopeammat julkaisusyklit ja 38 % takaisin saadun insinööri‑kapasiteetin. Miten nämä tulokset mitattiin, millä käyttöönottojaksoilla, ja mitä riippumatonta validointia käytettiin erottamaan AURA:n vaikutus muista organisaatio‑ tai insinööri‑muutoksista?

Yritys‑käyttöönottojen aikana mittasimme tuotantotapahtumien, julkaisusyklin nopeuden ja insinööri‑kapasiteetin muutoksia sen jälkeen, kun tiimit ottivat AURA:n käyttöön. Näissä käyttöönottoissa havaittiin yli 90 % vähemmän tuotantotapahtumia, 47 % nopeammat julkaisusyklit ja 38 % insinööri‑kapasiteettia palautettu, ja tulokset vahvistettiin riippumattomasti. Asiakkaat kuten Walmart ja Keller Williams ovat myös raportoineet merkittäviä parannuksia julkaisutiheyteen, testikattavuuteen ja sykliin.

Tutkimus havaitsi, että 64 % organisaatioista lisäsi laadunvarmistuksen henkilöstömäärää, vaikka tapahtumat jatkuivat kasvua. Miksi yritykset eivät voi ratkaista validointikatkoa pelkästään palkkaamalla lisää testaajia, ja miten odotat kehittäjien, laadunvarmistusinsinöörien ja sivuston luotettavuustiimien vastuiden muuttuvan, kun testaus muuttuu autonomisemmaksi?

Tekoäly voi lisätä koodimäärää paljon nopeammin kuin yritys voi kasvattaa testaushenkilöstöään, ja henkilöstön lisääminen tuo mukanaan myös enemmän siirtoja ja koordinointia. Kehittäjien on määriteltävä tarkoitus selkeästi, laadunvarmistusinsinöörit keskittyvät enemmän riskiin, kattavuuteen ja hallintoon, ja sivuston luotettavuustiimit syöttävät tuotantokäyttäytymisen takaisin julkaisuprosessiin. Agentit voivat hoitaa toistuvaa suoritusta ja analyysiä siinä mittakaavassa, jonka tämä uusi kehitys­malli vaatii.

Kun AI‑agentit saavat vastuuta testien kirjoittamisesta, suorittamisesta ja tulkinnasta, missä ihmisten on säilytettävä päätöksentekovalta? Minkälaiset epävarmuustekijät, turvallisuusriskit tai mahdolliset asiakasvaikutukset tulisi automaattisesti pysäyttää julkaisu tai käynnistää ihmisen tarkastus?

Ihmisten on säilytettävä lopullinen valta julkaisupäätöksiin, erityisesti kun päätökseen liittyy harkintaa, asiakasvaikutusta tai liiketoimintariskiä. AI‑agentit voivat automatisoida tylsiä, toistuvia ja selkeästi määriteltyjä testitehtäviä, mutta ihmisten tulisi hyväksyä tuotantojulkaisun, kun koodia tai testituloksia ei voida täysin ymmärtää, selittää tai toistaa. Tarkastus on myös pakollista, kun vaatimukset ovat epäselviä, turvallisuusaukot mahdollisia, kolmannen osapuolen komponentteja ei ole riittävästi validoitu tai epäonnistumiset voisivat vaikuttaa liikevaihtoon, arkaluonteisiin tietoihin, asiakaskokemukseen tai kriittisiin toimintoihin.

Näissä tilanteissa selittämätön käyttäytyminen, epäjohdonmukaiset testitulokset tai riittämätön näyttö julkaisukelpoisuudesta tulisi automaattisesti pysäyttää julkaisu.

Olemme nähneet asiakkaidemme tapauksia, joissa testit, jotka vaikuttivat “epävakailta”, eli läpäisy epäsäännöllisesti ilman selkeää epäonnistumismallia, jätettiin monissa tapauksissa huomiotta. Kuitenkin hyvin hallituissa prosesseissa joillakin näistä asiakkaista vaadittiin tarkkaa huolellisuutta, ja alustamme avulla he pystyivät jäljittämään epäonnistumisen hienovaraiseksi mutta kriittiseksi ajoitukseen perustuvaksi virheeksi, joka olisi voinut aiheuttaa merkittäviä vaikutuksia, jos se olisi julkaistu, ja aiheuttaisi erittäin korkeat kustannukset.

Olet myös työskennellyt Ethical AI Governance Groupin ja World Economic Forumin Safe Systems and Technologies -työryhmän kanssa. Kun AI‑luotu koodi ja autonominen testaus syventyvät toisiinsa, millaisia hallintastandardeja yritysten on noudatettava varmistaakseen, että nopeampi ohjelmistojen luominen ei tuo mukanaan uusia systeemisiä, turvallisuus‑ tai vastuukysymyksiä?

Mitä nopeammin AI voi luoda ohjelmistoja, sitä vahvemmaksi tarkistus‑ ja hallintakerros on kehitettävä. Tämä kerros koostuu monista osista.  Yritysten on asetettava selkeät rajat sille, mitä agentit voivat päätellä itsenäisesti, ja ihmisen tarkastus on pakollinen, kun liiketoimintatarkoituksen, turvallisuuden, vaatimustenmukaisuuden tai merkittävän semanttisen muutoksen ympärillä on epävarmuutta. He tarvitsevat myös jäljitettävyyden siihen, mitä agentti muutti, miksi se muutti sitä ja millä todisteilla julkaisupäätös perustui. Lopulta hallintaa tulisi mitata tuotantoon päätyvän työn laadun ja ennustettavuuden perusteella, esimerkiksi seuraamalla tarkasti, kuinka usein tuotettua koodia aiheuttaa tapahtumia 90 päivän sisällä julkaisusta, eikä sen perusteella, kuinka paljon nopeammin AI voi tuottaa koodia.

Kiitos erinomaisesta haastattelusta, lukijat, jotka haluavat oppia lisää, kannattaa käydä Sauce Labs -sivustolla.