Prince Kohli, presidente y director ejecutivo de Sauce Labs – Serie de entrevistas

Prince Kohli, presidente y director ejecutivo de Sauce Labs, es un ejecutivo tecnológico veterano con una amplia experiencia que abarca inteligencia artificial, software empresarial, computación en la nube, automatización, redes y ciberseguridad. Antes de unirse a Sauce Labs en febrero de 2025, pasó más de seis años como director de tecnología (Chief Technology Officer) de Automation Anywhere, donde ayudó a impulsar tecnologías de automatización impulsadas por IA para grandes empresas. Anteriormente, Kohli se desempeñó como vicepresidente senior de ingeniería en ThoughtSpot y ocupó cargos de liderazgo senior en Ericsson, incluida la supervisión de organizaciones globales de I&D con más de 10 000 ingenieros. También pasó casi una década en Citrix liderando iniciativas de plataforma, redes en la nube, ingeniería y operaciones. Al inicio de su carrera, cofundó la empresa de seguridad de aplicaciones Teros y trabajó como líder técnico en SGI. Además de sus cargos ejecutivos, Kohli ha contribuido a iniciativas de gobernanza tecnológica a través del Ethical AI Governance Group y participó previamente en el grupo de trabajo Safe Systems and Technologies del Foro Económico Mundial.

Sauce Labs es una empresa de calidad de software y pruebas continuas que brinda a las organizaciones infraestructura y herramientas para probar aplicaciones web y móviles en distintos navegadores, sistemas operativos, entornos virtuales y dispositivos reales. Su plataforma admite capacidades como pruebas automatizadas y manuales, pruebas visuales, distribución de aplicaciones móviles, informes de errores y creación y análisis de pruebas impulsados por IA, integrándose con flujos de trabajo comunes de integración y entrega continuas. Sauce Labs está posicionando cada vez más su tecnología en torno a AURA, su plataforma de Garantía de Lanzamiento Unificada por IA, que utiliza agentes de IA para ayudar a generar, ejecutar y analizar pruebas manteniendo la supervisión humana durante todo el proceso de lanzamiento de software. La compañía afirma que su infraestructura ha soportado más de 8.7 mil millones de ejecuciones de pruebas y más de 300 000 usuarios empresariales, basándose en casi dos décadas de datos de pruebas multiplataforma.

Antes de unirte a Sauce Labs, lideraste la automatización impulsada por IA en Automation Anywhere y gestionaste importantes organizaciones de nube e ingeniería en empresas como Ericsson y Citrix. ¿Cómo han moldeado esas experiencias tu visión del problema de la calidad del software, y qué te convenció de hacer de la garantía de lanzamiento nativa de IA una prioridad central en Sauce Labs?

En Ericsson y Citrix, vi cuán rápido puede propagarse un defecto de software y afectar la infraestructura global, generando impactos importantes en la seguridad, las operaciones y la confianza de los clientes, y en los ingresos. Automation Anywhere me mostró cómo la IA cambia la velocidad y la estructura del trabajo, y quedó claro que las pruebas deben reconstruirse para el ritmo del software generado por IA. Sauce Labs fue pionera en la automatización de pruebas, por lo que la garantía de lanzamiento nativa de IA es el próximo gran problema que estamos diseñados para resolver.

La investigación de Sauce Labs encontró que el 80 % de las organizaciones han rastreado un incidente de producción, una interrupción o un defecto que afecta a los clientes a código generado por IA. ¿Esto indica principalmente debilidades en el código producido por IA, o que las empresas están adoptando herramientas de codificación con IA sin actualizar sus procesos de pruebas y gobernanza?

La cifra del 80 % señala un problema en todo el sistema de entrega de software. La industria de IA ha atraído más de un billón de dólares en capital privado, gran parte basado en la premisa de que la IA hará a las empresas mucho más productivas. Sin embargo, generar más código solo crea valor si las compañías pueden estar seguras de su calidad y seguridad antes de llevarlo a producción.

El código generado por IA puede introducir errores sutiles y problemas de seguridad, y las empresas se ven obligadas a someter ese código a procesos de pruebas y gobernanza que ya tenían dificultades para seguir el ritmo. Eso crea un problema de ejecución de un billón de dólares: la IA puede acelerar la creación de software, pero sin una garantía de lanzamiento modernizada, también acelera los defectos. Cada error eventualmente será encontrado, por lo que las compañías deben asegurarse de detectarlo antes que un cliente o un atacante.

El informe indica que los desarrolladores están produciendo un 741 % más de código mientras la velocidad de lanzamiento ha aumentado menos del 20 %. ¿Qué impide que los sistemas de validación mantengan el ritmo, y dónde suele aparecer el mayor cuello de botella dentro del ciclo de vida del desarrollo de software?

La generación de código ha avanzado mucho más que la creación, el mantenimiento y el análisis de pruebas. Los mayores cuellos de botella suelen aparecer después de que el código está escrito y necesita verificarse dentro del contexto del recorrido del usuario. Esto puede ser muy complejo, a menudo más complejo que el propio código, ya que debe considerar rutas de extremo a extremo que abarcan funciones y objetos del código, donde cambios aparentemente menores en la semántica en un punto generan grandes efectos posteriores. Redactar estas pruebas de manera que capturen correctamente e integralmente la intención de la aplicación ha sido tradicionalmente casi imposible, además de requerir una cantidad muy significativa de trabajo manual y mantenimiento. Además, después de que las pruebas se ejecutan y algo falla, los equipos deben comprender y diagnosticar el problema, incluyendo decidir si la falla proviene del producto o de una prueba desactualizada. Ese trabajo aún depende en gran medida de la revisión manual y del contexto de ingeniería.

Más de la mitad de las empresas encuestadas reconocieron liberar software conscientemente con defectos críticos, mientras que el 66 % dijo haber comprometido la calidad o los estándares de pruebas para cumplir con una fecha límite. ¿Por qué las organizaciones aceptan este nivel de riesgo y qué tendría que cambiar para que la calidad del software se convierta en una prioridad a nivel empresarial en lugar de ser solo un punto de control final de ingeniería?

Las organizaciones aceptan el riesgo porque los objetivos de lanzamiento están vinculados a compromisos inmediatos con clientes, ingresos y productos, y los costos de los defectos a menudo aparecen más tarde en varios equipos. La calidad se convierte en una prioridad empresarial solo cuando los líderes miden los incidentes de producción, el impacto en el cliente, la exposición a la seguridad, los costos de retrabajo y los ingresos retrasados junto con la velocidad de lanzamiento.

Sauce Labs está posicionando AURA como una plataforma de bucle cerrado que crea, ejecuta y analiza pruebas mientras aprende de cada lanzamiento. ¿En qué se diferencia técnica y operativamente de la generación de pruebas asistida por IA, los scripts de prueba auto‑curativos u otras herramientas de automatización ya utilizadas por los equipos de ingeniería?

La mayoría de las herramientas de pruebas con IA abordan una tarea específica, como generar una prueba o reparar un localizador roto. AURA conecta todo el proceso al comprender la intención de la aplicación, crear y ejecutar pruebas, analizar fallas y devolver el comportamiento de producción al desarrollo. Puede manejar automáticamente muchos cambios e involucrar a una persona cuando el significado o el comportamiento esperado de la aplicación ha cambiado. Además, las pruebas que genera son estables, lo que significa que no necesitan modificarse cuando ocurren cambios que no afectan la semántica en aplicaciones, navegadores, dispositivos, etc. Finalmente, dado que AURA incorpora en sí misma una nube de ejecución de pruebas, puede descargar todo el proceso de un desarrollador o del equipo de ingeniería de calidad.

AURA está diseñada para verificar el software contra la “intención empresarial”. ¿Cómo se define esa intención y se traduce en requisitos verificables, quién es responsable de aprobarla y cómo maneja la plataforma los requisitos que son ambiguos, incompletos o sujetos a interpretación?

La intención empresarial proviene de los requisitos del producto, los criterios de aceptación, las reglas de negocio, los recorridos de usuario y la forma en que los clientes realmente utilizan la aplicación. Los líderes de producto definen el resultado esperado, y los equipos de ingeniería y calidad traducen ese resultado en un comportamiento que el sistema pueda verificar. Cuando los requisitos están incompletos o son ambiguos, AURA debe exponer la incertidumbre y solicitar la aprobación humana antes de modificar el resultado esperado.

Sauce Labs informa que las empresas que usan AURA han experimentado un 90 % menos de incidentes en producción, ciclos de lanzamiento un 47 % más rápidos y una recuperación del 38 % de la capacidad de ingeniería. ¿Cómo se midieron estos resultados, durante qué periodos de implementación y qué validación independiente se utilizó para distinguir el impacto de AURA de otros cambios organizacionales o de ingeniería?

En las implementaciones empresariales, medimos los cambios en incidentes de producción, la velocidad de los ciclos de lanzamiento y la capacidad de ingeniería después de que los equipos implementaron AURA. Esas implementaciones observaron más del 90 % menos de incidentes en producción, ciclos de lanzamiento un 47 % más rápidos y una recuperación del 38 % de la capacidad de ingeniería, con los resultados validados de forma independiente. Clientes como Walmart y Keller Williams también han reportado mejoras significativas en la frecuencia de lanzamientos, la cobertura de pruebas y el tiempo de ciclo.

La investigación encontró que el 64 % de las organizaciones aumentó el número de personal de aseguramiento de calidad aun cuando los incidentes siguieron aumentando. ¿Por qué las empresas no pueden cerrar la brecha de verificación simplemente contratando más evaluadores y cómo esperas que cambien las responsabilidades de desarrolladores, ingenieros de calidad y equipos de confiabilidad del sitio a medida que las pruebas se vuelvan más autónomas?

La IA puede aumentar el volumen de código mucho más rápido de lo que una empresa puede incrementar su personal de pruebas, y añadir personas también genera más transferencias y coordinación. Los desarrolladores deberán definir la intención con claridad, los ingenieros de calidad se centrarán más en el riesgo, la cobertura y la gobernanza, y los equipos de confiabilidad del sitio retroalimentarán el comportamiento de producción al proceso de lanzamiento. Los agentes pueden manejar la ejecución y el análisis repetitivos a la escala que requiere este nuevo modelo de desarrollo.

A medida que los agentes de IA asumen la responsabilidad de crear, ejecutar e interpretar pruebas, ¿dónde deben los humanos conservar la autoridad de toma de decisiones? ¿Qué tipos de incertidumbre, riesgo de seguridad o posible impacto al cliente deberían detener automáticamente un lanzamiento o activar una revisión humana?

Los humanos deben conservar la autoridad final sobre las decisiones de lanzamiento, particularmente cuando están involucrados el juicio, el impacto al cliente o el riesgo empresarial. Los agentes de IA pueden automatizar tareas de prueba tediosas, repetitivas y claramente definidas, pero los humanos deben aprobar los lanzamientos a producción siempre que el código o los resultados de las pruebas no puedan ser comprendidos, explicados o reproducidos completamente. La revisión también debe ser obligatoria cuando los requisitos son poco claros, existen posibles vulnerabilidades de seguridad, los componentes de terceros no han sido validados adecuadamente o las fallas podrían afectar los ingresos, datos sensibles, la experiencia del cliente o operaciones críticas.

En esas situaciones, un comportamiento inexplicado, resultados de pruebas inconsistentes o evidencia insuficiente de la preparación para el lanzamiento deberían detener automáticamente el lanzamiento.

Hemos observado casos en nuestros clientes donde una prueba que parecía “inestable”, aprobándose de forma inconsistente sin un patrón de fallos evidente, a menudo era ignorada. Sin embargo, procesos bien gobernados en algunos de estos clientes requirieron la debida diligencia y, con la ayuda de nuestra plataforma, pudieron rastrear la falla hasta un defecto sutil pero crítico basado en el tiempo que podría haber provocado impactos importantes si se hubiera liberado, con un costo muy alto.

También has trabajado con el Ethical AI Governance Group y el grupo de trabajo Safe Systems and Technologies del Foro Económico Mundial. A medida que el código generado por IA y las pruebas autónomas se conectan más profundamente, ¿qué normas de gobernanza necesitarán las empresas para garantizar que la creación de software más rápida no introduzca nuevos riesgos sistémicos, de seguridad o de responsabilidad?

Cuanto más rápido la IA pueda crear software, más robusta debe ser la capa de verificación y gobernanza. Esta capa tiene muchas partes. Las empresas deben establecer límites claros sobre lo que los agentes pueden decidir de forma autónoma, requiriendo revisión humana cuando exista incertidumbre sobre la intención empresarial, la seguridad, el cumplimiento o un cambio semántico significativo. También necesitan trazabilidad sobre qué cambió un agente, por qué lo cambió y qué evidencia respaldó la decisión de lanzamiento. En última instancia, la gobernanza debe medirse por la calidad y predictibilidad de lo que llega a producción, como rastrear específicamente con qué frecuencia el código generado causa incidentes dentro de los 90 días posteriores al lanzamiento, no por cuán rápido la IA puede generar código.

Gracias por la excelente entrevista; los lectores que deseen obtener más información deben visitar Sauce Labs.