Kristin Isaac, CEO y cofundadora de Strudel – Serie de entrevistas

Kristin Isaac, CEO y cofundadora de Strudel, es una líder veterana en tecnología empresarial que ha ocupado puestos senior en LinkedIn, Udemy, ESPN y Disney antes de lanzar Strudel. Ahora se enfoca en abordar uno de los puntos de fricción más grandes en las organizaciones de software: la brecha entre el soporte al cliente y la ingeniería. En Strudel, está construyendo una plataforma impulsada por IA que ayuda a los equipos de soporte técnico a resolver problemas complejos más rápido al conectar las solicitudes de soporte directamente con la inteligencia de ingeniería. Su experiencia en la escalabilidad de equipos, la creación de estrategias de mercado y el impulso del crecimiento en organizaciones globales ha ayudado a dar forma a la rápida tracción temprana y la sólida posición de Strudel en el mercado de IA empresarial y herramientas de desarrollo.

Strudel es una plataforma de IA diseñada para automatizar el soporte técnico avanzado al analizar registros, datos de producción, repositorios de código y historial de soporte para identificar las causas raíz y recomendar soluciones. Su objetivo es reducir el tiempo y el esfuerzo de ingeniería necesario para resolver casos de soporte difíciles, especialmente las escalaciones que normalmente consumen recursos técnicos senior. Al vincular el soporte directamente a los problemas técnicos subyacentes, Strudel se posiciona como una herramienta que puede hacer que las operaciones de soporte empresarial sean más rápidas, eficientes y escalables.

Ha ocupado puestos de liderazgo en organizaciones como LinkedIn, Udemy y Disney antes de fundar Strudel en 2025. ¿Qué experiencias en esos puestos lo convencieron finalmente de que los equipos de ingeniería necesitaban una plataforma de “inteligencia de ingeniería” impulsada por IA, y cómo dio forma a la fundación de Strudel?

Cada empresa en la que trabajé tenía una versión diferente del mismo problema. En Disney, las apuestas eran enormes: si una plataforma de streaming se caía durante un lanzamiento importante, no era solo un golpe a los ingresos, era un momento de la marca. En LinkedIn, la escala era implacable. Había miles de servicios generando ruido, y incluso los mejores equipos luchaban por mantenerse al día. En Udemy, vi a un equipo lean hacer cosas heroicas con herramientas limitadas.

Lo que conectaba a los tres, y a la experiencia de mis cofundadores, Shai Rubin y Brian Kaufman, al liderar equipos de ingeniería, era que los ingenieros estaban pasando más tiempo reconstruyendo el contexto que resolviendo problemas. Alguien recibe una llamada a las 2 am, y antes de que pueda empezar a diagnosticar, está revisando hilos de Slack, paneles de control, tickets de Jira, registros de implementación: solo tratando de entender qué cambió y cuándo. Están jugando a detective antes de poder hacer su trabajo real. Eso es un desperdicio de personas increíblemente talentosas.

Seguí pensando: debe haber una forma más inteligente de presentar lo que realmente importa, cuando importa. Esa es realmente la semilla de Strudel.

Muchas empresas miden el impacto financiero del tiempo de inactividad en términos de ingresos perdidos o penalizaciones por SLA. En su experiencia, ¿cuáles son algunos de los costos menos visibles de los cortes de servicio que las organizaciones subestiman consistentemente?

El número de ingresos llega a la junta directiva, pero el impacto inmediato de los ingresos es solo una fracción de lo que el corte de servicio realmente cuesta. Los que he visto que las organizaciones pasan por alto consistentemente se dividen en algunos grupos.

El primero es la confianza del cliente. Las penalizaciones por SLA son una construcción legal: no capturan al cliente que se marcha silenciosamente, o al prospecto empresarial que vio la página de estado en el momento equivocado y eligió a un competidor. Ese daño es lento, invisible y permanente de una manera que un cheque de reembolso simplemente no es.

El segundo es la rotación y el agotamiento de los ingenieros. La fatiga por estar de guardia es real. Cuando sus mejores ingenieros son repetidamente sacados de incidentes de alto estrés, especialmente aquellos que podrían haberse evitado, comienzan a cuestionar si este es el lugar adecuado para construir su carrera. Reemplazar a un ingeniero senior cuesta cualquier cosa, desde uno hasta dos veces su salario anual cuando se factoriza la contratación, la incorporación y el conocimiento institucional perdido. Nadie lo incluye en la autopsia.

El tercero es el costo de oportunidad. Cada hora que un equipo de ingeniería pasa luchando contra incendios es una hora que no se pasa construyendo un producto. Eso es difícil de poner en una hoja de cálculo, pero acumulado durante meses, silenciosamente hace explotar su hoja de ruta.

Los ingenieros a menudo son apartados de la construcción de nuevas funciones para responder a incidentes de producción. ¿Cómo afecta esto la innovación del producto y el desarrollo a largo plazo?

Crea un impuesto sobre la capacidad del equipo de ingeniería para construir. Cada equipo tiene una cantidad finita de ancho de banda, y cuando una parte significativa de eso se redirige constantemente a incidentes, el efecto acumulado sobre el desarrollo del producto es severo. Los compromisos de la hoja de ruta se pierden. La deuda técnica no se paga. Las características se envían con menos rigor porque hay presión para recuperar el tiempo perdido.

Lo que es particularmente dañino es la imprevisibilidad. Un equipo puede planificar su sprint con buenas intenciones, y luego un incidente importante estalla en un martes y todo lo demás se vuelve secundario. Ese tipo de imprevisibilidad sostenida hace que sea casi imposible construir una cultura de trabajo profundo, que es lo que impulsa los mejores resultados de ingeniería.

También crea un ciclo de refuerzo. La inversión diferida significa más incidentes, lo que significa más lucha contra incendios, lo que significa aún menos tiempo para invertir en los problemas subyacentes. En Strudel, una gran parte de lo que estamos construyendo es específicamente para los equipos de SRE que viven esto todos los días.

Strudel conecta los datos de soporte al cliente, registros, sistemas de producción y repositorios de código para identificar las causas raíz más rápido. ¿Cómo la IA une estos diferentes señales de carácter técnico de una manera que las herramientas de monitoreo tradicionales no pueden?

Las herramientas de monitoreo tradicionales son fundamentalmente sistemas de alerta. Son excelentes para decirte que algo cruzó un umbral: un aumento en la latencia, una tasa de errores en aumento, un pod en crash. Lo que no pueden hacer es razonar a través de dominios.

No saben que el aumento en la tasa de errores en su servicio de pagos ocurrió cuatro minutos después de una implementación en una dependencia, y que un ticket de soporte al cliente que menciona fallos en el pago llegó alrededor del mismo tiempo, y que la última vez que este patrón apareció en sus registros fue hace seis meses durante una migración de base de datos.

Esa correlación entre dominios es lo que la IA habilita. Podemos tratar un ticket de Zendesk, un commit de GitHub, una traza de Datadog (DDOG ) y un registro de CloudWatch como parte de una historia unificada en lugar de puntos de datos aislados. La IA presenta no solo qué está roto, sino la probable causa y dónde, y lo basa en evidencia que un ingeniero humano puede verificar y actuar. No les pedimos a los equipos que confíen en una caja negra. Les damos una hipótesis bien razonada y un impulso.

Describe Strudel como una plataforma que entrega “inteligencia de ingeniería”. ¿Qué significa este concepto en la práctica, y cómo es diferente de las plataformas de observabilidad o AIOps convencionales?

Kristin: La observabilidad es fundamentalmente sobre instrumentación y visibilidad: asegurarse de que la telemetría esté allí y que los equipos puedan consultarla. AIOps, en la mayoría de sus implementaciones actuales, se trata de reducir el ruido de las alertas a través de la correlación y la detección de anomalías basadas en ML. Ambas son genuinamente valiosas, y nos integramos con ellas.

Pero la inteligencia de ingeniería es una capa por encima. Estamos tomando lo que AIOps hace y expandiéndolo. Donde AIOps te dice que algo está mal, la inteligencia de ingeniería te ayuda a entender por qué está mal, dónde empezó y qué hacer al respecto, extrayendo señales de todo su stack, incluyendo fuentes que las herramientas AIOps tradicionales no miran, como tickets de soporte al cliente o cambios de código. El objetivo no es solo reducir el ruido. Es darle a su equipo una imagen completa y accionable para que puedan resolver el problema más rápido y regresar a construir.

Piense en ello como la diferencia entre un detector de humo y un investigador de incendios. La observabilidad y AIOps son el detector de humo: esencial, pero se detiene en la alarma. La inteligencia de ingeniería es lo que viene después: aquí está lo que sucedió, aquí está por qué, aquí está dónde empezó.

Los agentes de IA se están desplegando cada vez más para automatizar flujos de trabajo técnicos complejos. ¿Qué papel ve para los agentes de IA en el diagnóstico y la resolución de incidentes de software en los próximos cinco años?

Creo que la pregunta más interesante no es qué harán los agentes, sino qué dejarán de hacer los ingenieros. Los mejores ingenieros con los que he trabajado no entraron en este campo para pasar sus noches triando alertas o buscando en los registros por un cambio de configuración que alguien hizo un viernes por la tarde. Eso no es por lo que se volvieron buenos en su trabajo. Pero eso es lo que una gran parte de su tiempo se ve consumida por.

En los próximos cinco años, creo que los agentes asumen gran parte de ese trabajo de molienda: el trabajo de coincidencia de patrones, la ensambladura de contexto, el trabajo que es importante pero no donde el talento de ingeniería senior debería estar pasando su tiempo. Eso libera a las personas para centrarse en los problemas complejos, las decisiones arquitectónicas, las cosas que realmente requieren juicio humano.

Lo que me emociona es que esto no es solo un estado futuro: lo estamos viendo jugar ahora, incluyendo en Strudel. Nuestro roadmap completo está orientado a eliminar el trabajo administrativo y de mantenimiento de las placas de los ingenieros. Y lo que estamos encontrando, honestamente, es que cambia lo que es posible para un equipo. Puedes construir más, moverte más rápido y hacerlo con menos personas, porque las personas que tienes están centradas en estrategia y complejidad en lugar de pagar sus cuotas en el trabajo repetitivo. Eso se siente como un cambio significativo en cómo se construyen y estructuran los equipos en el futuro.

Muchas interrupciones del servicio se originan en pequeños errores o cambios de configuración que se filtran a través de las pruebas. ¿Cómo pueden los sistemas de IA identificar patrones sutiles en el código, los registros o las señales de infraestructura lo suficientemente temprano como para prevenir incidentes importantes?

La IA bien diseñada tiene una ventaja real aquí, y no es que sea más inteligente que sus ingenieros: es que nunca olvida y nunca duerme. Un ser humano puede no conectar un patrón de registro sutil hoy con algo que sucedió hace seis meses en una parte completamente diferente del sistema. La IA puede. Está observando todo, todo el tiempo, y tiene una memoria mucho más larga y amplia que cualquier individuo en su equipo.

Además, hay algo más que escucho de los clientes mucho: la prevención es solo tan buena como los datos subyacentes. Si sus registros son inconsistentes, incompletos o fragmentados en una docena de herramientas que no hablan entre sí, la IA está trabajando con una imagen fragmentada. Basura dentro, basura fuera: eso sigue siendo cierto. Pasamos mucho tiempo con los clientes ayudándolos a pensar en la calidad de los datos y la instrumentación porque la mejor IA del mundo no puede presentar una señal que nunca se capturó en primer lugar.

Así que la respuesta es ambos: sí, la IA puede atrapar cosas antes y conectar puntos que los humanos perderían. Pero los equipos que obtienen el mayor valor de ella son aquellos que también han hecho el trabajo para asegurarse de que sus datos sean realmente dignos de razonar.

Las empresas a menudo invierten mucho en herramientas de detección pero aún luchan con el tiempo medio de resolución. ¿Cuáles son las barreras más grandes que impiden que las organizaciones cierren la brecha entre la detección de incidentes y la resolución real de la causa raíz?

La detección es en gran medida un problema resuelto en este punto. La mayoría de los equipos tienen alertas. Saben que algo está mal. La brecha es todo lo que sucede después.

Cuando un ingeniero recibe una llamada, no entra en una situación clara con todo el contexto relevante reunido. Entra en un desastre. Tienen que averiguar qué cambió, cuándo cambió, qué sistema lo tocó, si hay un impacto en el cliente, si está relacionado con algo que sucedió la semana pasada. Están sacando información de Slack, paneles de control, tickets de Jira, registros de implementación: haciendo ese trabajo de ensamblaje manualmente, bajo presión, a menudo en medio de la noche.

La ensambladura del contexto es el cuello de botella. No es que los ingenieros y los equipos de soporte técnico no sepan cómo resolver problemas: es que están pasando los primeros 30 a 60 minutos de cada incidente solo tratando de entender a qué se enfrentan. Esa es la brecha en la que vive Strudel. Nuestra tesis completa es que si puedes entregar a un ingeniero una imagen coherente y respaldada por evidencia de lo que sucedió y por qué, justo cuando lo necesitan, comprimes dramáticamente esa brecha. El trabajo de resolución sigue siendo de ellos. Solo los llevamos a la línea de partida mucho más rápido.

A medida que los sistemas de IA comienzan a analizar datos de producción, código y registros operativos, ¿qué consideraciones de gobernanza o seguridad deberían tener en cuenta los equipos de ingeniería al implementar estas herramientas?

La cosa que siento más fuertemente aquí es esto: los humanos todavía deberían estar revisando el código que se implementa en producción.

He hablado con muchos ingenieros sobre esto, y una cosa que escucho una y otra vez es que la IA escribe errores de manera eficiente y astuta. Realmente astuta, en realidad. De una manera que puede ser genuinamente difícil de atrapar, incluso para ingenieros senior que revisan el código cuidadosamente. Los errores no siempre son obvios. Pueden parecer perfectamente razonables a primera vista.

Así que a medida que la IA escribe más y más del código que termina en producción, creo que vamos a ver más de estos problemas sutiles y difíciles de detectar que se filtran: no porque alguien fuera descuidado, sino porque la naturaleza de los errores generados por la IA es diferente. Más difícil de detectar en la revisión. Más difícil de atrapar en las pruebas.

Honestamente, eso es una de las razones por las que creo que el caso para lo que hace Strudel solo se vuelve más fuerte con el tiempo. Si más errores están llegando a producción, la capacidad de encontrar y resolverlos más rápido se vuelve más importante, no menos. La pregunta de gobernanza no es solo sobre controles de acceso a datos y permisos: aunque esos importan y los equipos deberían ser reflexivos sobre qué datos están dando acceso a cualquier sistema de IA. Es también sobre mantener a los humanos en los puntos de control adecuados, especialmente alrededor de cualquier cosa que toque la producción.

Mirando hacia adelante, ¿cree que el futuro de la ingeniería de confiabilidad se dirigirá hacia infraestructuras de IA en primer lugar, donde los sistemas autónomos monitorean, diagnostican y incluso corrigen problemas antes de que los humanos sean conscientes de ellos? Si es así, ¿cómo se ve ese flujo de trabajo futuro para los ingenieros?

Creo que nos dirigimos en esa dirección, pero soy pragmático sobre la cronología. Sistemas completamente autónomos que resuelven incidentes de producción sin conciencia humana: eso no es donde estamos, y no creo que estemos allí en los próximos años. Y creo que eso está bien.

Lo que creo es que el bucle se vuelve mucho más ajustado y menos doloroso. El futuro que me emociona no es aquel en el que los humanos se eliminan de la ecuación: es aquel en el que los humanos integrados en el proceso pasan su tiempo en las partes que realmente requieren su atención. Decisiones críticas. Situaciones novedosas. Un incidente que nunca se ha visto antes. La IA maneja la coincidencia de patrones, la ensambladura de contexto, la triage rutinaria. Los ingenieros manejan las decisiones.

Para los ingenieros mismos, creo que se ve así: menos tiempo de guardia en medio de la noche para cosas que no necesitan despertarlos, y más tiempo construyendo sistemas que no se rompen en primer lugar. La lucha contra incendios no desaparece por completo. Pero se convierte en la excepción en lugar del estado de ser un ingeniero en una empresa que ejecuta software a escala. Ese es un futuro hacia el que vale la pena construir.

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