Prince Kohli, Presidente e CEO da Sauce Labs – Série de Entrevistas

Prince Kohli, Presidente e CEO da Sauce Labs, é um executivo veterano em tecnologia com ampla experiência que abrange inteligência artificial, software empresarial, computação em nuvem, automação, redes e cibersegurança. Antes de ingressar na Sauce Labs em fevereiro de 2025, passou mais de seis anos como Chief Technology Officer da Automation Anywhere, onde ajudou a avançar tecnologias de automação impulsionadas por IA para grandes empresas. Anteriormente, Kohli atuou como Senior Vice President of Engineering na ThoughtSpot e ocupou cargos de liderança sênior na Ericsson, incluindo a supervisão de organizações globais de R&D que reuniam mais de 10.000 engenheiros. Também trabalhou quase uma década na Citrix liderando iniciativas de plataforma, redes em nuvem, engenharia e operações. No início de sua carreira, co‑fundou a empresa de segurança de aplicações Teros e trabalhou como líder técnico na SGI. Além de seus cargos executivos, Kohli contribuiu para iniciativas de governança tecnológica por meio do Ethical AI Governance Group e participou anteriormente do grupo de trabalho Safe Systems and Technologies do World Economic Forum.

Sauce Labs é uma empresa de qualidade de software e testes contínuos que fornece às empresas infraestrutura e ferramentas para testar aplicações web e móveis em diferentes navegadores, sistemas operacionais, ambientes virtuais e dispositivos reais. Sua plataforma oferece recursos como testes automatizados e manuais, testes visuais, distribuição de aplicativos móveis, relatórios de erros e autoria e análise de testes impulsionados por IA, integrando‑se aos fluxos de trabalho comuns de integração e entrega contínuas. A Sauce Labs tem posicionado sua tecnologia cada vez mais em torno da AURA, sua plataforma de AI‑Unified Release Assurance, que utiliza agentes de IA para ajudar a gerar, executar e analisar testes, mantendo a supervisão humana ao longo de todo o processo de liberação de software. A empresa afirma que sua infraestrutura já suportou mais de 8,7 bilhões de execuções de testes e mais de 300 mil usuários corporativos, baseando‑se em quase duas décadas de dados de testes multiplataforma.

Antes de ingressar na Sauce Labs, você liderou a automação impulsionada por IA na Automation Anywhere e gerenciou grandes organizações de nuvem e engenharia em empresas como Ericsson e Citrix. Como essas experiências moldaram sua visão sobre o problema de qualidade de software, e o que o convenceu a tornar a garantia de lançamento nativa em IA uma prioridade central na Sauce Labs?

Na Ericsson e na Citrix, percebi quão rapidamente um defeito de software pode se propagar e afetar a infraestrutura global, gerando impactos significativos na segurança, nas operações dos clientes, na confiança e na receita. A Automation Anywhere mostrou‑me como a IA altera a velocidade e a estrutura do trabalho, e ficou claro que os testes precisavam ser reconstruídos para o ritmo do software gerado por IA. A Sauce Labs foi pioneira em automação de testes, portanto a garantia de lançamento nativa em IA é o próximo grande problema que fomos construídos para resolver.

A pesquisa da Sauce Labs encontrou que 80% das organizações rastrearam um incidente de produção, interrupção ou defeito que impactou clientes a código gerado por IA. Isso indica principalmente fraquezas no código produzido por IA, ou empresas que adotam ferramentas de codificação com IA sem atualizar seus processos de teste e governança?

O número de 80% indica um problema em todo o sistema de entrega de software. A indústria de IA atraiu mais de um trilhão de dólares em capital privado, grande parte baseado na premissa de que a IA tornará as empresas drasticamente mais produtivas. Contudo, gerar mais código só cria valor se as empresas puderem confiar em sua qualidade e segurança antes de colocá‑lo em produção.

Códigos gerados por IA podem introduzir bugs sutis e problemas de segurança, e as empresas são forçadas a submeter esse código a processos de teste e governança que já lutavam para acompanhar o ritmo. Isso gera um problema de execução de trilhões de dólares: a IA pode acelerar a criação de software, mas sem uma garantia de lançamento modernizada, ela acelera igualmente os defeitos. Cada bug acabará sendo encontrado, portanto as empresas precisam garantir que o detectem antes de um cliente ou atacante.

O relatório afirma que os desenvolvedores estão produzindo 741% mais código, enquanto a velocidade de lançamento aumentou menos de 20%. O que impede os sistemas de validação de acompanhar o ritmo, e onde geralmente surge o maior gargalo dentro do ciclo de vida do desenvolvimento de software?

A geração de código avançou muito à frente da criação, manutenção e análise de testes. Os maiores gargalos geralmente surgem depois que o código é escrito e precisa ser verificado no contexto da jornada do usuário. Isso pode ser muito complexo, muitas vezes mais complexo que o próprio código, pois deve considerar caminhos de ponta a ponta que abrangem funções e objetos de código, com mudanças aparentemente menores na semântica em um ponto gerando grandes efeitos subsequentes. Autorizar esses testes de modo que capturem corretamente e integralmente a intenção da aplicação tem sido tradicionalmente quase impossível, além de exigir uma quantidade muito significativa de trabalho manual e manutenção. Além disso, após a execução dos testes e a ocorrência de falhas, as equipes precisam entender e diagnosticar o problema, incluindo decidir se a falha provém do produto ou de um teste desatualizado. Esse trabalho ainda depende fortemente de revisão manual e do contexto de engenharia.

Mais da metade das empresas pesquisadas admitiram liberar software conscientemente com defeitos críticos, enquanto 66% disseram ter comprometido a qualidade ou os padrões de teste para cumprir um prazo. Por que as organizações aceitam esse nível de risco, e o que precisaria mudar para que a qualidade de software se torne uma prioridade de negócios em vez de um ponto de verificação final de engenharia?

As organizações aceitam o risco porque as metas de lançamento estão ligadas a compromissos imediatos com clientes, receita e produto, e os custos dos defeitos frequentemente surgem mais tarde em várias equipes. A qualidade se torna uma prioridade de negócios somente quando os líderes medem incidentes de produção, impacto ao cliente, exposição à segurança, custos de retrabalho e receita atrasada juntamente com a velocidade de lançamento.

A Sauce Labs está posicionando AURA como uma plataforma de ciclo fechado que cria, executa e analisa testes enquanto aprende com cada lançamento. Como isso difere técnica e operacionalmente da geração de testes assistida por IA, scripts de teste auto‑curativos ou outras ferramentas de automação já usadas por equipes de engenharia?

A maioria das ferramentas de teste com IA aborda uma tarefa específica, como gerar um teste ou reparar um localizador quebrado. A AURA conecta todo o processo ao compreender a intenção da aplicação, criar e executar testes, analisar falhas e alimentar o comportamento de produção de volta ao desenvolvimento. Ela pode lidar automaticamente com muitas alterações e envolver uma pessoa no processo quando o significado ou o comportamento esperado da aplicação mudar. Além disso, os testes que gera são estáveis, ou seja, não precisam ser modificados quando mudanças que não afetam a semântica ocorrem em aplicações, navegadores, dispositivos etc. Por fim, como a AURA incorpora em si mesma uma nuvem de execução de testes, ela pode descarregar todo o processo de um desenvolvedor ou equipe de engenharia de qualidade.

A AURA foi projetada para verificar o software em relação à “intenção de negócio”. Como essa intenção é definida e traduzida em requisitos testáveis, quem é responsável por aprová‑la, e como a plataforma lida com requisitos que são ambíguos, incompletos ou abertos a interpretação?

A intenção de negócio provém dos requisitos do produto, critérios de aceitação, regras de negócio, jornadas de usuário e da forma como os clientes realmente utilizam a aplicação. Os líderes de produto definem o resultado esperado, e as equipes de engenharia e qualidade traduzem esse resultado em comportamentos que o sistema pode verificar. Quando os requisitos são incompletos ou ambíguos, a AURA deve evidenciar a incerteza e solicitar aprovação humana antes de alterar o resultado esperado.

A Sauce Labs relata que as empresas que utilizam a AURA experimentaram 90% menos incidentes de produção, ciclos de lançamento 47% mais rápidos e reconquistaram 38% da capacidade de engenharia. Como esses resultados foram medidos, em quais períodos de implantação, e que validação independente foi usada para distinguir o impacto da AURA de outras mudanças organizacionais ou de engenharia?

Em implantações corporativas, medimos as mudanças em incidentes de produção, velocidade dos ciclos de lançamento e capacidade de engenharia após as equipes implementarem a AURA. Essas implantações observaram mais de 90% menos incidentes de produção, ciclos de lançamento 47% mais rápidos e 38% da capacidade de engenharia reconquistada, com os resultados validados de forma independente. Clientes como Walmart e Keller Williams também relataram ganhos significativos em frequência de lançamentos, cobertura de testes e tempo de ciclo.

A pesquisa constatou que 64% das organizações aumentaram o número de profissionais de garantia de qualidade mesmo com o aumento dos incidentes. Por que as empresas não podem resolver a lacuna de verificação simplesmente contratando mais testadores, e como você espera que as responsabilidades de desenvolvedores, engenheiros de qualidade e equipes de confiabilidade de site mudem à medida que os testes se tornam mais autônomos?

A IA pode aumentar o volume de código muito mais rápido do que uma empresa pode aumentar seu número de testadores, e a adição de pessoas também gera mais transferências e coordenação. Os desenvolvedores precisarão definir a intenção claramente, os engenheiros de qualidade focarão mais em risco, cobertura e governança, e as equipes de confiabilidade de site alimentarão o comportamento de produção de volta ao processo de lançamento. Os agentes podem lidar com a execução e análise repetitivas na escala que esse novo modelo de desenvolvimento exige.

À medida que os agentes de IA assumem responsabilidade por criar, executar e interpretar testes, onde os humanos devem manter a autoridade de decisão? Que tipos de incerteza, risco de segurança ou impacto potencial ao cliente devem interromper automaticamente um lançamento ou acionar revisão humana?

Os humanos devem manter a autoridade final sobre as decisões de lançamento, particularmente quando julgamento, impacto ao cliente ou risco de negócios está envolvido. Os agentes de IA podem automatizar tarefas de teste tediosas, repetitivas e claramente definidas, mas os humanos devem aprovar os lançamentos em produção sempre que o código ou os resultados dos testes não puderem ser totalmente compreendidos, explicados ou reproduzidos. A revisão também deve ser obrigatória quando os requisitos são obscuros, vulnerabilidades de segurança são possíveis, componentes de terceiros não foram validados adequadamente, ou falhas podem afetar receita, dados sensíveis, experiência do cliente ou operações críticas.

Nessas situações, comportamento não explicado, resultados de teste inconsistentes ou evidência insuficiente de prontidão para o lançamento devem interromper automaticamente o lançamento.

Vimos casos em nossos clientes onde um teste que parecia “instável”, passando de forma inconsistente sem um padrão de falha aparente, muitas vezes era ignorado. Contudo, processos bem governados em alguns desses clientes exigiram a devida diligência e, com a ajuda da nossa plataforma, eles conseguiram rastrear a falha até um defeito sutil, porém crítico, baseado em tempo, que poderia ter causado grandes impactos se fosse lançado, com um custo muito alto.

Você também trabalhou com o Ethical AI Governance Group e o grupo de trabalho Safe Systems and Technologies do Fórum Econômico Mundial. À medida que o código gerado por IA e os testes autônomos se conectam mais profundamente, quais padrões de governança as empresas precisarão para garantir que a criação mais rápida de software não introduza novos riscos sistêmicos, de segurança ou de responsabilidade?

Quanto mais rápido a IA pode criar software, mais robusta a camada de verificação e governança precisa ser. Essa camada possui muitas partes. As empresas devem estabelecer limites claros sobre o que os agentes podem decidir autonomamente, exigindo revisão humana quando houver incerteza sobre a intenção de negócio, segurança, conformidade ou mudança semântica significativa. Também precisam de rastreabilidade sobre o que um agente alterou, por que o alterou e quais evidências sustentam a decisão de lançamento. Em última análise, a governança deve ser medida pela qualidade e previsibilidade do que chega à produção, como monitorar especificamente com que frequência o código gerado causa incidentes dentro de 90 dias após o lançamento, e não pela rapidez com que a IA gera código.

Obrigado pela ótima entrevista, leitores que desejam saber mais devem visitar Sauce Labs.