Últimos reportajes
Temas destacados
Trending
La IA puede estar acelerando el desarrollo de software, pero los sistemas utilizados para supervisar ese software no necesariamente han avanzado al mismo ritmo. Para Bob Quillin, cofundador y CEO de ControlTheory, esto se está convirtiendo en un problema a medida que los agentes de IA y los ingenieros desarrollan y ponen en producción más código a una velocidad para la que la observabilidad tradicional nunca fue diseñada.
El argumento de Quillin no es que el código generado por IA sea intrínsecamente malo. Es que las premisas en las que se basa la observabilidad convencional están empezando a dejar de ser válidas. Los equipos ya no pueden anticipar todos los fallos que merece la pena supervisar; el coste de recopilar y almacenar volúmenes cada vez mayores de telemetría puede ser considerable y el comportamiento en tiempo de ejecución no siempre llega a las personas – o agentes – responsables del código.
Esta es la idea en la que se basa Dstl8 de ControlTheory, que la compañía describe como un «bucle de feedback en tiempo de ejecución» en lugar de otra plataforma de observabilidad. En lugar de limitarse a informar de lo ocurrido después de la implementación, Dstl8 analiza la telemetría en su origen, relaciona el comportamiento en tiempo de ejecución con las implementaciones, diagnostica el problema subyacente y devuelve esa información a las herramientas de desarrollo. Su enfoque incluye el análisis del lenguaje utilizado realmente en los registros para identificar señales como el sentimiento, los patrones, las anomalías y la gravedad, en lugar de depender únicamente de umbrales predefinidos.
En esta entrevista, Quillin explica qué ocurre cuando se acelera la velocidad de desarrollo de software, por qué ControlTheory cree que la telemetría debería depurarse antes de entrar en costosos procesos de observabilidad y qué implica en la práctica su enfoque de «cero reglas de alerta». También explica cómo introducir el conocimiento de los incidentes en un grafo de conocimiento podría cambiar el papel de los ingenieros: pasar de buscar en los paneles qué salió mal a evaluar las evidencias y decidir qué debería ocurrir a continuación.
La observabilidad tradicional se basa en varias premisas que antes eran seguras. Alguien sabe qué fallos debe vigilar. Una persona establece los umbrales, los paneles y los procedimientos documentados para esos fallos. Se recopila todo y se consulta posteriormente. Y la persona que escribió el código recuerda lo que implementó. Todo esto funcionaba cuando los humanos escribían código al ritmo de los humanos.
Ahora los equipos lanzan mucho más código y mucho más rápido, y ese código lo escriben conjuntamente agentes e ingenieros. El volumen y la velocidad aumentan al mismo tiempo y se multiplican entre sí. El problema no es que la IA escriba código incorrecto. El problema es que llega a producción más código del que cualquier equipo puede supervisar manualmente.
Tres cosas dejan de funcionar. En primer lugar, deja de funcionar el modelo basado en fallos conocidos. Los problemas en tiempo de ejecución se manifiestan en el comportamiento, no en la sintaxis: grupos de conexiones que se agotan bajo una carga real, bucles de reintento que se vuelven problemáticos cuando tres servicios los ejecutan simultáneamente, consultas que funcionan bien con datos de prueba y se convierten en recorridos completos de tablas con volúmenes reales. Nadie ha establecido un umbral para esos casos.
En segundo lugar, se rompe la economía de los datos, porque más código significa más telemetría, y almacenar todo resulta caro rápidamente.
En tercer lugar, se rompe el feedback. El contexto de un agente termina cuando se hace el merge, por lo que lo que ocurre en tiempo de ejecución nunca llega al autor.
La observabilidad te dice lo que ya ha ocurrido. Se diseñó para el área de operaciones: paneles posteriores a la implementación que alguien supervisa después de que el código haya llegado a producción. Lo que falta es el camino de vuelta hacia los ingenieros y agentes que están escribiendo el código en ese momento.
Por eso llamamos a Dstl8 el bucle de feedback en tiempo de ejecución para el desarrollo a velocidad de IA. Supervisa continuamente la telemetría, sin reglas de alerta, detecta el incidente, encuentra la causa allí donde se haya producido —en la infraestructura, la configuración o el código— y proporciona una solución sugerida junto con las evidencias que la respaldan.
La mayoría de las herramientas de SRE basadas en IA se detienen en el resumen del incidente. Dstl8 lleva la respuesta hasta el lugar donde se realiza el trabajo y la recuerda, de modo que el mismo incidente no tenga que resolverse dos veces.
Hacer llegar el diagnóstico es importante porque ahí es donde se produce la corrección. Un agente de programación ya tiene el repositorio y el contexto del cambio. Cuando las evidencias obtenidas en tiempo de ejecución llegan directamente a Claude Code, Cursor o Codex, el agente o el ingeniero puede actuar sobre ellas en la misma sesión en lugar de empezar desde cero la semana siguiente.
Las correcciones de infraestructura funcionan de la misma manera: se sugiere un cambio, un humano lo aprueba y el agente del equipo lo aplica con los permisos que tiene asignados. Los equipos también pueden empezar en staging, para que los agentes vean qué efecto ha tenido un cambio antes de que lo hagan los clientes.
Nuestro principio es sencillo: extraer la señal, eliminar el ruido y no almacenarlo todo. El modelo convencional recopila toda la telemetría en un lago de datos y, aunque añadas IA encima, tus agentes siguen teniendo que atravesar un mar de ruido, consumir tokens y pagar por mover y almacenar todos esos datos.
Introducir directamente registros sin procesar en un modelo de lenguaje de gran tamaño tampoco lo soluciona. El volumen de registros sin procesar desborda las ventanas de contexto y los costes aumentan rápidamente. Con 10 GB de registros al día, enviarlos a un modelo de vanguardia puede costar entre unos 75.000 y 750.000 dólares al mes, dependiendo del modelo.
La depuración de la telemetría se realiza allí donde ya están los datos. Lee el contenido real de cada línea de registro, no solo su código de estado, y extrae cuatro tipos de señales: sentimiento, patrones, anomalías y gravedad. Solo lo que importa sigue adelante.
Esto permite que el agente se centre en el contexto adecuado, reduce los datos por los que tienes que pagar y, por tanto, hace que el resultado sea más útil, porque el modelo propio de ControlTheory, ajustado específicamente para esta tarea, razona sobre las señales en lugar de buscar entre el ruido.
Los registros son lenguaje. Los sistemas dicen muchas cosas sobre sí mismos en texto plano y la mayoría de las herramientas reducen ese texto a un número o a un código de estado.
Piensa en mensajes como «volviendo a la configuración predeterminada», «reintentando» o «null inesperado, continuando». Cada uno de ellos puede aparecer tranquilamente junto a un mensaje de registro HTTP 200 OK. No se supera ningún umbral y nada parece anómalo en un gráfico. Pero el sistema te está diciendo discretamente, con palabras, que hay un problema oculto que el análisis del sentimiento puede detectar.
Dstl8 interpreta el tono y el nivel de confianza del texto de los registros y errores de la misma manera que lo haría una persona. Esto permite detectar fallos que habían pasado desapercibidos: excepciones absorbidas, errores que han perdido el contexto de su solicitud y degradaciones que se acumulan lentamente después de una implementación.
También detecta una categoría cada vez más habitual en los productos nativos de IA, en los que la respuesta de un LLM tiene éxito técnicamente, pero falla desde el punto de vista del cliente. La supervisión tradicional podría contabilizarlo como un éxito, pero el sentimiento indica que, en realidad, no lo fue.
Las reglas de alerta codifican lo que alguien esperaba que pudiera salir mal. Son una instantánea del conocimiento del pasado. Cuando el código cambia a diario y el mismo prompt puede generar una implementación diferente, con una forma distinta de fallar, cada vez que se ejecuta, no hay nada estable sobre lo que escribir una regla.
Con un cliente de ControlTheory del sector fintech empresarial, Dstl8 se ejecutó en 13 clústeres de Kubernetes durante un periodo de dos meses y detectó y resolvió automáticamente 328 incidentes sin que el equipo escribiera una sola regla de alerta.
En la práctica, «cero reglas de alerta» significa que nadie configuró umbrales, monitores o procedimientos documentados para llegar a ese resultado. Dstl8 depura lo que está ocurriendo, relaciona lo que ha cambiado con el evento de implementación y presenta el incidente junto con las evidencias.
No significa que no intervengan personas: los ingenieros siguen haciendo el triaje y tomando decisiones. Pero dedican su tiempo a solucionar problemas en lugar de mantener alertas. Y todos esos resultados procedían únicamente de datos de registros y eventos. El bucle está a punto de ampliarse mucho más.
El ingeniero pasa de buscar a evaluar. En lugar de saltar de un panel a otro para reconstruir lo ocurrido, empieza con un diagnóstico y las evidencias que lo respaldan, y después decide qué hacer.
La confianza es la cuestión fundamental en los sistemas agénticos, por lo que, para aplicar una corrección, Dstl8 trabaja a través de los agentes en los que ya confías. Dstl8 encuentra qué ha fallado y por qué, cita las evidencias y señala el cambio concreto, ya sea una línea de código o la configuración de un clúster, y después se lo entrega al agente al que has dado acceso para realizarlo. Dstl8 se encarga del diagnóstico. Tu agente se encarga del cambio.
El grafo de conocimiento podría ser el cambio más importante. Cada investigación y cada corrección se incorporan a él, de modo que los incidentes y las soluciones anteriores aparecen automáticamente la próxima vez.
El conocimiento que antes estaba en la cabeza de un ingeniero sénior se convierte en algo sobre lo que puede apoyarse todo el equipo y cada sesión de un agente. Así es como el desarrollo de software con IA mejora con el tiempo: no solo se vuelve más rápido.
