Moshe Sambol, VP de Soluciones de Cliente en Lightrun – Serie de Entrevistas

Moshe Sambol, VP de Soluciones de Cliente en Lightrun – aporta más de dos décadas de experiencia que abarca ingeniería de software, arquitectura, infraestructura en la nube y liderazgo técnico orientado al cliente. Antes de unirse a Lightrun en 2022, pasó casi una década en Google, donde ocupó varios puestos de liderazgo, incluido el de Gerente de Ingeniería de Cliente de Google Cloud, ayudando a las organizaciones a adoptar y escalar las tecnologías de Google Cloud. Al comienzo de su carrera, Sambol ocupó puestos de liderazgo en ingeniería y desarrollo en Oracle, Sun Microsystems, BMC Software y JPMorgan Chase. En Lightrun, inicialmente lideró la Ingeniería de Soluciones globales antes de convertirse en VP de Soluciones de Cliente, donde se centra en ayudar a los clientes a adoptar la tecnología de Insights de Tiempo de Ejecución de la empresa y traducir sus capacidades en ganancias medibles de productividad empresarial y de desarrollador.

Lightrun es una plataforma de ingeniería de confiabilidad nativa de IA diseñada para brindar a los desarrolladores y agentes de IA una visibilidad directa de cómo se comporta el software mientras se ejecuta. Su tecnología puede capturar dinámicamente registros, instantáneas, métricas, trazas, valores de variables y contexto de ejecución de aplicaciones en vivo sin requerir cambios de código o redepliegues. La empresa está extendiendo cada vez más esta inteligencia de tiempo de ejecución a la desarrollo de software asistido por IA a través de Lightrun MCP, que utiliza el Protocolo de Contexto de Modelo para proporcionar asistentes de codificación y herramientas agénticas con contexto de aplicación en vivo en lugar de confiar únicamente en código fuente estático. Esto permite que los sistemas de IA investiguen problemas de producción, validen hipótesis contra el comportamiento de ejecución real y apoyen el análisis de causa raíz al incorporar controles empresariales como acceso basado en roles y redacción de datos sensibles.

Su carrera ha abarcado desarrollo de software y arquitectura prácticos, ingeniería de cliente en la nube en Google, ingeniería de soluciones globales y ahora soluciones de cliente en Lightrun. ¿Cómo ha moldeado esta combinación de construir software y trabajar directamente con clientes empresariales su comprensión de lo que separa una demostración impresionante de un agente de IA de un sistema que se puede confiar en producción?

Hay una gran diferencia entre mostrar lo que un agente de IA puede hacer y demostrar que se puede confiar en él en un entorno empresarial. Esto se debe a que los agentes son solo una parte de un sistema listo para producción. El marco que lo rodea es igual de importante. Debe hacer cumplir el acceso de menor privilegio, monitorear la actividad, preservar un registro de auditoría, prevenir acciones inaceptablemente arriesgadas y traer a un humano cuando sea necesario.

Los sistemas agénticos son inherentemente diferentes del software tradicional, porque los desarrolladores no prescriben exactamente cómo funcionará el sistema. Establecemos un objetivo, proporcionamos herramientas y orientación, y el modelo determina cómo proceder. Esa flexibilidad es poderosa, pero también hace que el comportamiento del sistema sea más difícil de predecir.

Para las empresas, especialmente aquellas en industrias reguladas, los flujos de trabajo de producción que generalmente funcionan o tardan una cantidad impredecible de tiempo en completarse no son viables. Los entornos de producción contienen datos sensibles, código fuente y propiedad intelectual, por lo que las organizaciones necesitan poder prevenir que los agentes expongan esa información o tomen rutas creativas pero inaceptables para lograr sus objetivos. Esto se está volviendo cada vez más importante, ya que cada semana trae un nuevo ejemplo de un sistema de IA que, en su afán de alcanzar un objetivo, termina siendo vulnerable a o causa una explotación de seguridad.

La mayoría de los líderes con los que hablo todavía evalúan a los agentes de la misma manera que evaluarían a un nuevo empleado: en función de sus capacidades, juicio y producción. La verdadera pregunta no es si el agente es lo suficientemente inteligente. Es si el sistema que lo rodea puede atrapar y contener los momentos en que no lo es.

Muchas empresas inicialmente creyeron que construir un agente de IA era en gran medida una cuestión de escribir una invitación efectiva. ¿Qué malentendieron las organizaciones sobre los requisitos de ingeniería, arquitectura y operativos detrás de los agentes listos para producción?

Creo que el mayor malentendido fue una creencia casi ingenua en el poder de la IA para resolver cualquier desafío, una vez que se le dio una invitación bien escrita, contexto relevante y herramientas adecuadas. Los equipos conectaron su LLM con código, documentación, tickets y telemetría histórica, y luego esperaron que razonara con precisión hasta la decisión correcta.

Lo que no construyeron fue un modelo de verificación para cada paso del razonamiento de la IA. Una de las grandes fortalezas de la IA es que utiliza un razonamiento probabilístico, encontrando y tomando una de las muchas posibles rutas para llegar a un destino. En entornos de producción complejos e interconectados, esa misma fortaleza introduce un riesgo grave: una sola decisión puede desencadenar retrocesos posteriores, fallos silenciosos u otros comportamientos inesperados que amenazan la resiliencia operativa de un sistema en ejecución.

Es ahí donde se vuelve esencial la dirección determinista. El razonamiento del agente puede permanecer probabilístico, pero los puntos de control alrededor de sus acciones no pueden serlo. Para un agente que participa en un flujo de trabajo de ingeniería, esto requiere un paso de verificación que comprueba su acción hipotizada siguiente contra la realidad de producción, una puerta determinista en lugar de otra suposición probabilística. Necesita ver cuál será la consecuencia de esa decisión y aprobarla solo una vez que haya determinado que la acción es segura.

Al observar la primera oleada de agentes empresariales desarrollados internamente, ¿cuáles son los errores arquitectónicos más comunes que está viendo, y qué problemas se pueden corregir de forma incremental en lugar de requerir una reconstrucción completa?

La principal preocupación a la que siempre regreso es la validación. Los agentes pueden convertirse en una caja negra: recopilan información de una variedad de fuentes y luego toman decisiones que parecen razonables en principio, pero que pueden no ser apropiadas para las realidades de un entorno de producción complejo y desordenado.

Eso apunta a un cambio más fundamental, y es algo que hablamos constantemente en Lightrun mientras ayudamos a los clientes a construir automatizaciones agénticas para sus organizaciones de ingeniería. Los equipos necesitan reconstruir el flujo agéntico en sí y colocar puertas en las acciones del agente, para asegurarse de que el uso de herramientas esté sujeto a supervisión, auditoría y revisión. Proporcionar al agente en sí un fuerte bucle de retroalimentación, incluida la observabilidad de tiempo de ejecución en vivo, centra su contexto en lo que realmente está sucediendo en este momento. Ese acceso es lo que permite al agente validar sus propias decisiones de diseño, análisis de causa raíz y recomendaciones de mitigación de errores contra la realidad de producción en lugar de contra suposiciones basadas en análisis estático de código o telemetría antigua.

Una reconstrucción dramática no es la única opción. Lo que se puede hacer de forma incremental, y no es revolucionario pero es esencial, es invertir en las habilidades que guían el comportamiento del agente. Las habilidades cuidadosamente elaboradas y evaluadas empujan al agente en la dirección de un flujo de trabajo determinista. Los equipos no necesitan re-arquitectar todo el sistema para obtener ese beneficio. Necesitan tratar el diseño de habilidades con el mismo rigor que darían a cualquier otra lógica de producción.

¿Por qué algunos agentes funcionan bien durante las pruebas controladas pero comienzan a producir resultados inconsistentes, incompletos o engañosos cuando se exponen a usuarios reales, datos cambiantes, herramientas externas y entornos de producción complejos?

Las pruebas controladas eliminan la mayoría de la variabilidad que definirá la realidad de producción con la que la IA tiene que lidiar. Los datos están curados, el comportamiento de las herramientas es predecible, los permisos son conocidos y cubrimos un camino que anticipamos. Cuando se lanza un agente para interactuar con usuarios reales y sus efectos en sistemas en vivo, no se está comparando lo mismo con lo mismo.

Los usuarios introducen solicitudes ambiguas y ejecutan acciones concurrentes, el estado del sistema está en constante flujo, el agente a menudo tiene que trabajar con datos parciales y las herramientas externas traen su propia latencia y modos de falla encima de eso. Debido a que el modelo es probabilístico, cada nueva variable crea otro lugar donde el flujo de trabajo puede divergir o compounding un error anterior.

La parte peligrosa es que el agente puede seguir pareciendo que funciona correctamente mientras produce respuestas incorrectas pero plausibles, construidas a partir de datos parciales o basadas en suposiciones arraigadas en información desactualizada. Es por eso que los agentes de producción necesitan una evaluación continua que siga ejecutándose después del lanzamiento, un manejo explícito de datos faltantes y fallas de herramientas, y una verificación en vivo de una decisión antes de que complete una acción de alto impacto.

Lightrun pone un gran énfasis en dar a los sistemas de IA acceso al contexto de tiempo de ejecución. ¿Qué información proporciona el contexto de tiempo de ejecución que las métricas, trazas y registros convencionales pueden pasar por alto, y por qué es esta información particularmente importante para diagnosticar fallos de agente?

La observabilidad convencional muestra los síntomas externos del comportamiento del sistema, a menudo agregados, muestreados o filtrados a través de paneles y alertas que se activan en umbrales. Están usualmente dependientes de decisiones tomadas por los desarrolladores en el momento en que se escribió el código: ¿qué información será de interés en el futuro? ¿Qué vale la pena registrar o medir? El contexto de tiempo de ejecución desconecta la visibilidad de la necesidad de saber de antemano qué podría ser de interés y proporciona datos granulares que muestran qué está sucediendo bajo el capó y cómo llegamos allí.

La verdadera brecha es entre datos estáticos y dinámicos. Los registros, métricas y trazas convencionales son estáticos y producen un relato histórico de lo que sucedió. El contexto de tiempo de ejecución de Lightrun es dinámico. Le da al agente la capacidad de colocar nueva instrumentación en código en ejecución, bajo demanda, y observar los valores de variables exactas, argumentos de función, estado de objeto, pila de llamadas o condiciones de rama a medida que ocurren.

Esta distinción es particularmente importante para diagnosticar fallos en código generado por el agente, porque estos son frecuentemente silenciosos. Un agente puede elegir la herramienta incorrecta, pasar el argumento incorrecto o actuar sobre una suposición desactualizada, y aún completar su tarea sin desencadenar ningún error. Un fallo como ese no se mostrará en la telemetría estática, porque nadie sabía de antemano instrumentar para ello. El comportamiento inesperado requiere una investigación dinámica directamente en el sistema en ejecución, colocando nueva instrumentación exactamente donde el modelo del mundo del agente se desvió de la realidad, en lugar de confiar en lo que ya se estaba grabando.

Eso es lo que hace que el contexto de tiempo de ejecución dinámico sea la capa de verificación natural para las decisiones generadas por la IA en ingeniería.

¿Cómo pueden el Protocolo de Contexto de Modelo (MCP) y capas de integración similares permitir que los agentes de codificación aprendan del comportamiento de ejecución real sin darles acceso excesivo o inseguro a los sistemas de producción?

MCP y otros accesos controlados a herramientas externas (por ejemplo, envolturas de CLI) permiten que un agente llame a una capacidad específica y delimitada en lugar de tener un acceso amplio al sistema y confiar en que se comporte. Un agente conectado a través de un servidor MCP para contexto de tiempo de ejecución puede solicitar evidencia de solo lectura, el valor de una variable, una ruta de llamada, si se excedió un umbral, sin tocar el acceso de escritura, sin la capacidad de redeployar nada y sin necesidad de credenciales permanentes para el entorno subyacente.

Al rediseñar un agente de primera generación, ¿cómo deben abordar las empresas los permisos de herramienta, la memoria, la recuperación de datos, la evaluación, la supervisión humana y los procedimientos de respaldo como partes de una arquitectura cohesiva en lugar de características separadas?

No se puede soldar estas piezas de forma independiente porque cada una cambia a las demás. Los mejores lugares para empezar son el marco, el arnés que controla el bucle del agente y la orquestación general del flujo de trabajo que une a varios agentes y otros actores. Para un flujo de trabajo de análisis de causa raíz, por ejemplo, los equipos deben decidir qué evidencia se requiere, qué sistemas puede inspeccionar el agente, si puede publicar una conclusión o solo borrador, cuándo un humano debe aprobar el siguiente paso y qué sucede si la evidencia de tiempo de ejecución no está disponible.

Una vez que ese contrato esté claro, el arnés y el marco proporcionan los mecanismos para hacer cumplir esas pautas. Las puertas MCP se pueden aprovechar para limitar el acceso del agente a capacidades específicas relevantes para su propósito. Las herramientas pueden otorgarse con el menor privilegio. La memoria puede supervisarse, con datos sensibles redactados de forma determinista. La recuperación puede diseñarse alrededor de la evidencia que necesita el flujo de trabajo.

La evaluación, la supervisión y el respaldo luego cierran el círculo. El sistema debe medir si las conclusiones son correctas y están respaldadas, traer a un humano cuando el riesgo o la incertidumbre cruzan un umbral definido y detenerse o retroceder a una recomendación de solo lectura cuando no pueda reunir suficiente evidencia. Un registro de auditoría compartido debe conectar el desencadenante, los permisos, la evidencia, las llamadas a herramientas, las aprobaciones, la acción y el resultado. Eso es lo que hace que estos componentes sean una arquitectura de producción en lugar de seis características separadas.

¿Qué salvaguardias deben rodear a los agentes que pueden inspeccionar aplicaciones en vivo o participar en flujos de trabajo de ingeniería de confiabilidad del sitio, particularmente en entornos regulados donde los controles de acceso, la privacidad, la auditoría y la estabilidad operativa son críticos?

Esta fue una de las preguntas de diseño centrales cuando construimos Lightrun AI SRE. Un AI SRE opera cerca de algunos de los sistemas más sensibles de una organización, así que lo diseñamos como un actor operativo privilegiado, no como un asistente de chat. Una decisión importante fue separar el plano de inspección del plano de acción. El AI SRE recopila evidencia a través de integraciones de solo lectura y la instrumentación de tiempo de ejecución sandboxed de Lightrun, con acceso restringido por identidad, inquilino, servicio y entorno. Puede inspeccionar la ejecución en vivo y generar evidencia faltante, pero la capa de inspección de tiempo de ejecución no puede modificar el estado de la aplicación.

En un entorno regulado, ese límite debe estar respaldado por RBAC, SSO, aislamiento de inquilinos, redacción de PII, controles de retención y un registro de auditoría que muestra qué herramientas y evidencia respaldaron cada conclusión. También necesitamos límites operativos sobre la cantidad de datos que se pueden recopilar, con qué frecuencia se puede consultar el tiempo de ejecución y qué acciones requieren aprobación. Si la evidencia está faltante o una conclusión no se puede verificar, el AI SRE debe decirlo y entregar la decisión a un humano en lugar de actuar como si supiera más de lo que sabe. El objetivo es la autonomía controlada: lo suficientemente útil como para acelerar una investigación, pero lo suficientemente limitado como para permanecer seguro para el sistema en vivo.

A medida que las empresas van más allá de los agentes experimentales, ¿qué medidas deben determinar si un agente está genuinamente listo para producción, y cómo espera que evolucione la relación entre los agentes de IA y los ingenieros humanos en los próximos años?

Evaluaría la preparación para producción según con qué frecuencia las acciones de un agente de IA producen los resultados deseados, sus conclusiones se sostienen contra lo que realmente era cierto en producción, las conclusiones no respaldadas se detectan antes de la acción y si falla de manera visible y segura cuando la evidencia no está allí. Para los agentes de ingeniería, la precisión de los resultados verificados, la cobertura de la evidencia, el tiempo para confirmar la causa raíz, la tasa de retroceso exitosa y los resultados posteriores a la acción son las métricas centrales en las que debemos centrarnos.

En los próximos años, espero que los agentes asuman más la recopilación de evidencia y la investigación de primer paso, así como la supervisión de los flujos de trabajo agénticos y el aprendizaje continuo a partir de la experiencia y la retroalimentación, mientras que los ingenieros establecen políticas, resuelven ambigüedades, aprueban acciones de alto riesgo y guían los sistemas agénticos de auto-mejora. La confianza se expandirá flujo de trabajo por flujo de trabajo. Los agentes que puedan rastrear sus conclusiones hasta la evidencia en vivo y divulgar claramente lo que no pudieron verificar ganarán una mayor autonomía. Aquellos que no puedan, permanecerán limitados a tareas de bajo riesgo y bajos estakes, independientemente de lo fluido que suenen.

Gracias por la gran entrevista, los lectores que deseen aprender más pueden visitar Lightrun.