Entrevistas
Kristin Isaac, CEO y cofundadora de Strudel – Serie de entrevistas
Kristin Isaac, CEO y cofundadora de Strudel es una veterana líder de tecnología empresarial que ha ocupado puestos senior en LinkedIn, Udemy, ESPN y Disney antes de lanzar Strudel. Ahora se centra en abordar uno de los mayores puntos de fricción 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 escalada 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 fuerte posición de Strudel en el mercado de IA empresarial y herramientas para desarrolladores.
Strudel es una plataforma de IA diseñada para automatizar el soporte técnico avanzado analizando registros, datos de producción, repositorios de código y historial de soporte pasado 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 los tipos de escalaciones que normalmente consumen recursos técnicos senior. Al vincular el soporte directamente con 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 la convencieron finalmente de que los equipos de ingeniería necesitaban una nueva clase de 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 que generaban ruido, y incluso los mejores equipos luchaban por mantenerse al día. En Udemy, vi a un equipo lean hacer cosas heroicas con una herramienta limitada.
Lo que conectaba a los tres, y a la experiencia de mis cofundadores, Shai Rubin y Brian Kaufman, al liderar equipos de ingeniería, fue 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, 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.
Me seguí preguntando: ¿hay una forma más inteligente de mostrar 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 de SLA. En su experiencia, ¿cuáles son algunos de los costos menos visibles de los tiempos de inactividad que las organizaciones subestiman consistentemente?
El número de ingresos llega a la junta directiva, pero el impacto inmediato en los ingresos es solo una fracción de lo que el tiempo de inactividad realmente cuesta. Los que he visto que las organizaciones pasan por alto consistentemente se dividen en varios grupos.
El primero es la confianza del cliente. Las penalizaciones de SLA son un constructo legal: no capturan al cliente que se despide silenciosamente, o al prospecto empresarial que vio su 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 de 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 entre una y dos veces su salario anual cuando se considera la contratación, la incorporación y la pérdida de conocimientos institucionales. Nadie lo incluye en el informe post-mortem.
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 estallar su hoja de ruta.
Los ingenieros a menudo son sacados de la construcción de nuevas funciones para responder a incidentes de producción. ¿Cómo afecta esto la innovación del producto y los planes de 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 de productos es grave. Los compromisos de la hoja de ruta se pierden. La deuda técnica no se paga. Las funciones se envían con menos rigor porque hay presión para recuperar el tiempo perdido.
Lo que es particularmente dañino es la imprevisibilidad de ello. Un equipo puede planificar su sprint con buenas intenciones, y luego un incidente importante estalla 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, lo que en última instancia impulsa los mejores resultados de ingeniería.
También crea un ciclo auto-reforzante. 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 está específicamente para los equipos de SRE que viven esto todos los días.
Strudel conecta los datos de soporte al cliente, los registros, los sistemas de producción y los repositorios de código para identificar las causas raíz más rápido. ¿Cómo combina la IA 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 de latencia, una tasa de error en aumento, un pod que se estrelló. Lo que no pueden hacer es razonar a través de dominios.
No saben que el aumento de la tasa de error 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 mencionaba fallos de 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 permite la IA. Podemos tratar un ticket de Zendesk, un compromiso de GitHub, una traza de Datadog y un registro de CloudWatch como parte de una historia unificada en lugar de puntos de datos aislados. La IA muestra no solo qué está roto, sino el por qué probable y dónde, y lo basa en evidencia que un ingeniero humano puede verificar y actuar. No estamos pidiendo a los equipos que confíen en una caja negra. Les estamos dando una hipótesis bien razonada y una ventaja.
Describe Strudel como una plataforma que entrega “inteligencia de ingeniería”. ¿Qué significa este concepto en la práctica, y cómo difiere de las plataformas de observabilidad o AIOps convencionales?
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 alerta 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 hace AIOps 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, incluidas fuentes que las herramientas AIOps tradicionales ni siquiera 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 la construcción.
Piénselo 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 cree que desempeñarán 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 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.
En los próximos cinco años, creo que los agentes asumen gran parte de esa monotonía: el trabajo de coincidencia de patrones, la construcción de contexto, 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 es emocionante para mí es que esto no es solo un estado futuro: lo estamos viendo desarrollarse ahora, incluido 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 se centran en estrategia y complejidad en lugar de pagar sus deudas en lo repetitivo. Eso se siente como un cambio significativo en cómo se construyen y estructuran los equipos en el futuro.
Muchas interrupciones se originan en pequeños errores o cambios de configuración que se filtran en 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 elaborada tiene una ventaja real aquí, y no es que sea más inteligente que sus ingenieros: es que nunca olvida y nunca duerme. Un humano puede no conectar un patrón sutil de registro hoy con algo que sucedió hace seis meses en una parte completamente diferente del sistema. La IA puede. Está vigilando todo, todo el tiempo, y tiene una memoria mucho más larga y más amplia que cualquier individuo en su equipo.
Eso dicho, también 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 todavía es 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 superficiar una señal que nunca se capturó en primer lugar.
Así que la respuesta es ambos: sí, la IA puede detectar cosas más temprano y conectar puntos que los humanos podrían perder. Pero los equipos que obtienen el mayor valor de ello 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 extrayendo de Slack, de paneles, de tickets de Jira, de registros de implementación: haciendo ese trabajo de ensamblaje manualmente, bajo presión, a menudo en medio de la noche.
Ese ensamblaje de contexto es el cuello de botella. No es que los ingenieros y los equipos de soporte no sepan cómo resolver problemas: es que están pasando los primeros 30 a 60 minutos de cada incidente solo tratando de entender qué están mirando en realidad. 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 es aún 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 base 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 que los humanos todavía deberían revisar el código que se envía a 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, de hecho. De una manera que puede ser genuinamente difícil de detectar, 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 veremos 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 de lo que hace Strudel solo se vuelve más fuerte con el tiempo. Si más errores están llegando a la 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 esas cosas importan y los equipos deberían ser reflexivos sobre qué datos están dando acceso a cualquier sistema de IA. También se trata de mantener a los humanos en los puntos de control correctos, especialmente alrededor de cualquier cosa que toque la producción.
Mirando hacia adelante, ¿cree que el futuro de la ingeniería de confiabilidad se desplazará hacia una infraestructura de IA en primer lugar, donde los sistemas autónomos monitorean, diagnostican e incluso corrigen problemas antes de que los humanos sean conscientes de ellos? Si es así, ¿cómo se ve el flujo de trabajo futuro para los ingenieros?
Creo que nos dirigimos en esa dirección, pero soy pragmática sobre la cronología. Sistemas autónomos completamente resolviendo 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 está bien.
Lo que creo es que el bucle se vuelve mucho más ajustado y mucho menos doloroso. El futuro que me emociona no es uno donde los humanos se eliminan de la ecuación: es uno donde los humanos integrados en el proceso pasan su tiempo en las partes que realmente requieren su atención. Decisiones de juicio. Situaciones novedosas. Un incidente que nunca se ha visto antes. La IA maneja la coincidencia de patrones, el ensamblaje 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 ingeniero en una empresa que ejecuta software a escala. Ese es un futuro hacia el que vale la pena construir.
