Prince Kohli, Presidente e CEO di Sauce Labs – Serie di Interviste

Prince Kohli, Presidente e CEO di Sauce Labs, è un dirigente tecnologico veterano con un’esperienza ampia che spazia dall’intelligenza artificiale al software enterprise, dal cloud computing all’automazione, alle reti e alla cybersecurity. Prima di entrare in Sauce Labs nel febbraio 2025, ha trascorso più di sei anni come Chief Technology Officer di Automation Anywhere, dove ha contribuito a far progredire le tecnologie di automazione guidate dall’AI per grandi imprese. In precedenza, Kohli è stato Senior Vice President of Engineering presso ThoughtSpot e ha ricoperto ruoli di leadership senior in Ericsson, inclusa la supervisione di organizzazioni globali di R&D composte da oltre 10.000 ingegneri. Ha inoltre lavorato quasi un decennio in Citrix, guidando iniziative di piattaforma, networking cloud, ingegneria e operazioni. All’inizio della sua carriera, ha co‑fondato la società di sicurezza delle applicazioni Teros e ha lavorato come technical lead presso SGI. Oltre ai ruoli esecutivi, Kohli ha contribuito a iniziative di governance tecnologica tramite l’Ethical AI Governance Group e ha partecipato in passato al gruppo di lavoro Safe Systems and Technologies del World Economic Forum.

Sauce Labs è una società di qualità del software e testing continuo che fornisce alle imprese infrastrutture e strumenti per testare applicazioni web e mobile su browser, sistemi operativi, ambienti virtuali e dispositivi reali. La sua piattaforma supporta funzionalità tra cui testing automatizzato e manuale, testing visivo, distribuzione di app mobile, segnalazione di errori e authoring e analisi dei test potenziati dall’AI, integrandosi con i flussi di lavoro comuni di integrazione e consegna continua. Sauce Labs sta sempre più posizionando la sua tecnologia attorno ad AURA, la piattaforma AI‑Unified Release Assurance, che utilizza agenti AI per aiutare a generare, eseguire e analizzare i test mantenendo la supervisione umana durante l’intero processo di rilascio software. L’azienda afferma che la sua infrastruttura ha supportato più di 8,7 miliardi di esecuzioni di test e oltre 300.000 utenti enterprise, basandosi su quasi due decenni di dati di testing cross‑platform.

Prima di entrare in Sauce Labs, hai guidato l’automazione basata sull’AI presso Automation Anywhere e gestito grandi organizzazioni cloud e di ingegneria in aziende tra cui Ericsson e Citrix. In che modo queste esperienze hanno plasmato la tua visione del problema della qualità del software, e cosa ti ha convinto a fare dell’assicurazione di rilascio AI‑native una priorità centrale in Sauce Labs?

In Ericsson e Citrix ho visto quanto rapidamente un difetto software possa propagarsi e influire su infrastrutture globali, creando impatti significativi su sicurezza, operazioni dei clienti, fiducia e ricavi. Automation Anywhere mi ha mostrato come l’AI cambi la velocità e la struttura del lavoro, rendendo evidente che il testing doveva essere ricostruito per il ritmo del software generato dall’AI. Sauce Labs ha aperto la strada all’automazione dei test, quindi l’assicurazione di rilascio AI‑native è il prossimo grande problema che siamo pronti a risolvere.

La ricerca di Sauce Labs ha rilevato che l’80 % delle organizzazioni ha tracciato un incidente in produzione, un’interruzione o un difetto che ha impattato i clienti a codice generato dall’AI. Questo indica principalmente debolezze nel codice prodotto dall’AI, oppure il fatto che le imprese adottano strumenti di coding AI senza aggiornare i loro processi di testing e governance?

La percentuale dell’80 % evidenzia un problema che attraversa l’intero sistema di consegna del software. L’industria dell’AI ha attirato più di un trilione di dollari di capitale privato, gran parte dei quali basato sulla promessa che l’AI renda le aziende drasticamente più produttive. Tuttavia, generare più codice crea valore solo se le aziende possono essere certe della sua qualità e sicurezza prima di portarlo in produzione.

Il codice generato dall’AI può introdurre bug sottili e vulnerabilità di sicurezza e le imprese sono costrette a far passare quel codice attraverso processi di testing e governance già in difficoltà nel tenere il passo. Questo genera un problema di esecuzione da un trilione di dollari: l’AI può accelerare la creazione del software, ma senza un’assicurazione di rilascio modernizzata accelera altrettanto i difetti. Ogni bug verrà inevitabilmente scoperto, quindi le aziende devono assicurarsi di trovarlo prima che lo faccia un cliente o un attaccante.

Il rapporto afferma che gli sviluppatori stanno producendo il 741 % di codice in più mentre la velocità di rilascio è aumentata di meno del 20 %. Cosa impedisce ai sistemi di validazione di tenere il passo e dove tipicamente emerge il collo di bottiglia più grande nel ciclo di vita dello sviluppo software?

La generazione di codice è avanzata molto più rapidamente della creazione, manutenzione e analisi dei test. I colli di bottiglia più grandi compaiono di solito dopo che il codice è stato scritto e deve essere verificato nel contesto del percorso utente. Questo può essere estremamente complesso, spesso più complesso del codice stesso, poiché deve tenere conto di percorsi end‑to‑end che attraversano funzioni e oggetti del codice, con cambiamenti apparentemente minori in una parte che generano grandi effetti a valle. Autore questi test in modo che catturino correttamente e completamente l’intento dell’applicazione è stato tradizionalmente quasi impossibile, oltre a richiedere una notevole quantità di lavoro manuale e manutenzione. Inoltre, dopo l’esecuzione dei test e il verificarsi di un fallimento, i team devono comprendere e diagnosticare il problema, decidendo se il fallimento provenga dal prodotto o da un test obsoleto. Questo lavoro dipende ancora fortemente da revisioni manuali e dal contesto ingegneristico.

Più della metà delle imprese intervistate ha ammesso di rilasciare consapevolmente software con difetti critici, mentre il 66 % ha dichiarato di aver compromesso la qualità o gli standard di testing per rispettare una scadenza. Perché le organizzazioni accettano questo livello di rischio e cosa dovrebbe cambiare affinché la qualità del software diventi una priorità a livello di business anziché un semplice checkpoint ingegneristico finale?

Le organizzazioni accettano il rischio perché gli obiettivi di rilascio sono legati a impegni immediati con clienti, ricavi e prodotti, e i costi dei difetti spesso si manifestano più tardi, coinvolgendo più team. La qualità diventa una priorità aziendale solo quando i leader misurano incidenti in produzione, impatti sui clienti, esposizione alla sicurezza, costi di rifacimento e ricavi ritardati insieme alla velocità di rilascio.

Sauce Labs sta posizionando AURA come una piattaforma a ciclo chiuso che crea, esegue e analizza i test imparando da ogni rilascio. Come differisce tecnicamente e operativamente dall’autogenerazione di test assistita dall’AI, dagli script di test auto‑curanti o da altri strumenti di automazione già utilizzati dai team di ingegneria?

La maggior parte degli strumenti di testing AI affronta un compito specifico, come generare un test o riparare un locator rotto. AURA collega l’intero processo comprendendo l’intento dell’applicazione, creando ed eseguendo i test, analizzando i fallimenti e reinserendo il comportamento di produzione nello sviluppo. Può gestire automaticamente molte modifiche e coinvolgere una persona quando il significato o il comportamento atteso dell’applicazione cambia. Inoltre, i test che genera sono stabili, cioè non necessitano di modifiche quando avvengono cambiamenti che non impattano la semantica in applicazioni, browser, dispositivi e simili. Infine, poiché AURA incorpora al suo interno un cloud di esecuzione dei test, è in grado di scaricare l’intero processo da sviluppatori o team di quality engineering.

AURA è progettata per verificare il software rispetto all’“intento di business”. Come viene definito tale intento e tradotto in requisiti testabili, chi è responsabile della sua approvazione e come la piattaforma gestisce requisiti ambigui, incompleti o soggetti a interpretazione?

L’intento di business deriva dai requisiti di prodotto, criteri di accettazione, regole di business, percorsi utente e dal modo in cui i clienti effettivamente utilizzano l’applicazione. I leader di prodotto definiscono il risultato atteso, e i team di ingegneria e qualità traducono quel risultato in comportamenti che il sistema può verificare. Quando i requisiti sono incompleti o ambigui, AURA dovrebbe evidenziare l’incertezza e richiedere l’approvazione umana prima di modificare il risultato atteso.

Sauce Labs riferisce che le imprese che utilizzano AURA hanno registrato il 90 % di incidenti in produzione in meno, cicli di rilascio più veloci del 47 % e il recupero del 38 % della capacità ingegneristica. Come sono stati misurati questi risultati, su quali periodi di deployment e quale validazione indipendente è stata usata per distinguere l’impatto di AURA da altri cambiamenti organizzativi o ingegneristici?

Su scala enterprise, abbiamo misurato le variazioni di incidenti in produzione, velocità dei cicli di rilascio e capacità ingegneristica dopo che i team hanno implementato AURA. Quei deployment hanno mostrato più del 90 % di incidenti in produzione in meno, cicli di rilascio più veloci del 47 % e il 38 % di capacità ingegneristica recuperata, con i risultati validati in modo indipendente. Clienti come Walmart e Keller Williams hanno inoltre segnalato guadagni significativi in frequenza di rilascio, copertura dei test e tempo di ciclo.

La ricerca ha scoperto che il 64 % delle organizzazioni ha aumentato il personale di assurance della qualità nonostante gli incidenti continuassero a crescere. Perché le imprese non possono colmare il divario di verifica semplicemente assumendo più tester, e come prevedi che cambino le responsabilità di sviluppatori, ingegneri della qualità e team di site reliability man mano che il testing diventa più autonomo?

L’AI può aumentare il volume di codice molto più rapidamente di quanto un’azienda possa aumentare il proprio organico di testing, e aggiungere persone genera anche più passaggi e coordinamento. Gli sviluppatori dovranno definire l’intento in modo chiaro, gli ingegneri della qualità si concentreranno maggiormente su rischio, copertura e governance, e i team di site reliability reinseriranno il comportamento di produzione nel processo di rilascio. Gli agenti potranno gestire l’esecuzione e l’analisi ripetitive alla scala richiesta da questo nuovo modello di sviluppo.

Man mano che gli agenti AI assumono la responsabilità di creare, eseguire e interpretare i test, dove devono gli esseri umani mantenere l’autorità decisionale? Quali tipi di incertezza, rischio di sicurezza o potenziale impatto sul cliente dovrebbero fermare automaticamente un rilascio o innescare una revisione umana?

Gli esseri umani devono mantenere l’autorità finale sulle decisioni di rilascio, soprattutto quando sono in gioco giudizio, impatto sul cliente o rischio di business. Gli agenti AI possono automatizzare compiti di testing noiosi, ripetibili e chiaramente definiti, ma gli umani dovrebbero approvare i rilasci in produzione ogni volta che il codice o i risultati dei test non possono essere pienamente compresi, spiegati o replicati. La revisione dovrebbe essere obbligatoria anche quando i requisiti sono poco chiari, esistono potenziali vulnerabilità di sicurezza, componenti di terze parti non sono stati adeguatamente validati, o i fallimenti potrebbero influire su ricavi, dati sensibili, esperienza del cliente o operazioni mission‑critical.

In queste situazioni, comportamenti inspiegabili, risultati di test incoerenti o evidenza insufficiente di prontezza al rilascio dovrebbero fermare automaticamente il rilascio.

Abbiamo osservato casi nei nostri clienti in cui un test che sembrava “flaky”, con passaggi incoerenti senza un chiaro schema di fallimento, veniva spesso ignorato. Tuttavia, processi ben governati in alcuni di questi clienti hanno richiesto la dovuta diligenza e, con l’aiuto della nostra piattaforma, sono riusciti a tracciare il fallimento a un difetto sottile ma critico basato sul timing, che avrebbe potuto causare impatti maggiori se rilasciato, con un costo molto elevato.

Hai anche collaborato con l’Ethical AI Governance Group e con il gruppo di lavoro Safe Systems and Technologies del World Economic Forum. Man mano che il codice generato dall’AI e il testing autonomo diventano più strettamente collegati, quali standard di governance le imprese dovranno adottare per garantire che la creazione più rapida di software non introduca nuovi rischi sistemici, di sicurezza o di responsabilità?

più veloce è la creazione di software da parte dell’AI, più forte deve diventare lo strato di verifica e governance. Questo strato ha molte componenti.  Le imprese devono definire confini chiari su ciò che gli agenti possono decidere autonomamente, richiedendo una revisione umana quando vi è incertezza sull’intento di business, sicurezza, conformità o cambiamenti semantici significativi. Devono inoltre garantire tracciabilità su cosa l’agente ha modificato, perché lo ha modificato e quali evidenze hanno supportato la decisione di rilascio. In definitiva, la governance dovrebbe essere misurata dalla qualità e prevedibilità di ciò che arriva in produzione, ad esempio tracciando specificamente con che frequenza il codice generato causa incidenti entro 90 giorni dal rilascio, non dalla velocità con cui l’AI può generare codice.

Grazie per la splendida intervista, i lettori che desiderano saperne di più dovrebbero visitare Sauce Labs.