Cómo el sensor de tiempo de ejecución de Hud redujo el tiempo de detección de 3 horas a 10 minutos Mas Cipolleti
Los equipos de ingeniería están generando más código que nunca con agentes de IA. Pero se topan con un obstáculo cuando el código llega a producción.
El problema no es necesariamente el código generado por la IA en sí. Resulta que las herramientas de monitoreo tradicionales a menudo tienen dificultades para proporcionar los datos granulares a nivel de función que los agentes de IA necesitan para comprender cómo se comporta realmente el código en entornos de producción complejos. Sin este contexto, los agentes no pueden detectar problemas ni generar correcciones que tengan en cuenta la realidad de la producción.
Es un desafío que la startup hud busca ayudar a resolver el problema con el lanzamiento de su sensor de código de tiempo de ejecución el miércoles. El sensor homónimo de la compañía funciona junto con el código de producción, rastreando automáticamente cómo se comporta cada función, brindando a los desarrolladores una alerta sobre lo que realmente está sucediendo en la implementación.
“Cada equipo de software que construye a escala enfrenta el mismo desafío fundamental: crear productos de alta calidad que funcionen bien en el mundo real”, dijo a VentureBeat Roee Adler, director ejecutivo y fundador de Hud, en una entrevista exclusiva. “En la nueva era del desarrollo acelerado por la IA, no saber cómo se comporta el código en producción se convierte en una parte aún mayor de ese desafío”.
A qué se enfrentan los desarrolladores de software
Los puntos débiles que enfrentan los desarrolladores son bastante consistentes en todas las organizaciones de ingeniería. Moshik Eilon, líder de tecnología del grupo Monday.com, supervisa a 130 ingenieros y describe una frustración familiar con las herramientas de monitoreo tradicionales.
“Cuando recibe una alerta, a menudo termina verificando un punto final que tiene una tasa de error o una latencia alta y desea profundizar para ver las dependencias posteriores”, dijo Eilon a VentureBeat. “Muchas veces es la aplicación real y luego es una caja negra. Sólo se obtiene un 80% de latencia en la aplicación”.
El siguiente paso suele implicar un trabajo de detección manual a través de varias herramientas. Consulta los registros. Correlacionar marcas de tiempo. Intente reconstruir lo que estaba haciendo la aplicación. Para problemas nuevos y profundos en una base de código grande, los equipos a menudo no tienen los datos exactos que necesitan.
Daniel Marashlian, CTO y cofundador de Drata, ha visto a sus ingenieros dedicar horas a lo que él llama “impuesto a la investigación”. “Estaban asignando una alerta genérica a un propietario de código específico y luego investigando los registros para reconstruir el estado de la aplicación”, dijo Marashlian a VentureBeat. “Queríamos eliminar esto para que nuestro equipo pudiera centrarse completamente en la remediación en lugar del descubrimiento”.
La arquitectura de Drata complica el desafío. La empresa se integra con múltiples servicios externos para brindar cumplimiento automatizado, lo que crea investigaciones sofisticadas cuando surgen problemas. Los ingenieros rastrean el comportamiento en una base de código muy grande, que abarca módulos de riesgo, cumplimiento, integraciones y generación de informes.
Marashlian identificó tres problemas específicos que llevaron a Drata a invertir en sensores de tiempo de ejecución. El primer problema fue el costo del cambio de contexto.
“Nuestros datos estaban dispersos, por lo que nuestros ingenieros tuvieron que actuar como puentes humanos entre herramientas desconectadas”, dijo.
El segundo problema, señaló, es la fatiga de alerta. “Cuando se tiene un sistema distribuido complejo, los canales de alerta generales se convierten en un flujo constante de ruido de fondo, lo que nuestro equipo describe como un efecto de ‘ding, ding, ding’ que eventualmente se ignora”, dijo Marashlian.
El tercer factor principal fue la necesidad de integración con la estrategia de IA de la empresa.
“Un agente de IA puede escribir código, pero no puede corregir un error de producción si no puede ver las variables de tiempo de ejecución o la causa raíz”, dijo Marashlian.
Por qué los APM tradicionales no pueden resolver fácilmente el problema
Las empresas han dependido durante mucho tiempo de una clase de herramientas y servicios conocidos como Monitoreo del rendimiento de aplicaciones (APM).
Con el ritmo actual de desarrollo de la IA de las agencias y los flujos de trabajo de desarrollo modernos, tanto Monday.com como Drata simplemente no han podido obtener la visibilidad que necesitan de las herramientas APM existentes.
“Si quisiera obtener esta información de Datadog o CoreLogix, simplemente tendría que ingerir toneladas de registros o toneladas de tramos y pagaría mucho dinero”, dijo Eilon.
Eilon señaló que Monday.com utilizó tasas de muestreo muy bajas debido a limitaciones de costos. Esto significaba que a menudo omitían los datos exactos necesarios para depurar problemas.
Las herramientas tradicionales de monitoreo del rendimiento de las aplicaciones también requieren predicción, lo cual es un problema porque a veces un desarrollador simplemente no sabe lo que no sabe.
“La observabilidad tradicional requiere que uno anticipe lo que necesitará para depurar”, dijo Marashlian. “Pero cuando surge un nuevo problema, especialmente en una base de código grande y compleja, a menudo se pierden los datos exactos que se necesitan”.
Drata evaluó varias soluciones en las categorías de ingeniería de confiabilidad de sitios web de IA y respuesta automatizada a incidentes y no encontró lo que se necesitaba.
“La mayoría de las herramientas que evaluamos fueron excelentes para gestionar el proceso de incidentes, enrutar tickets, resumir subprocesos de Slack o correlacionar gráficos”, dijo. “Pero a menudo se detenían antes del código en sí. Podían decirnos ‘El servicio A está inactivo’, pero no podían decirnos por qué específicamente”.
Otra característica común de algunas herramientas, incluidos los monitores de errores como Sentry, es la capacidad de detectar excepciones. El desafío, según Adler, es que ser consciente de las excepciones es bueno, pero no las conecta con el impacto empresarial ni proporciona el contexto de ejecución que los agentes de IA necesitan para proponer soluciones.
Cómo funcionan de manera diferente los sensores de tiempo de ejecución
Los sensores de tiempo de ejecución llevan la inteligencia al límite donde se ejecuta el código. El sensor Hud funciona como un SDK que se integra con una sola línea de código. Ve todas las ejecuciones de funciones, pero solo envía datos agregados ligeros a menos que algo salga mal.
Cuando se producen errores o ralentizaciones, el sensor recopila automáticamente datos forenses profundos, incluidos parámetros HTTP, consultas y respuestas de bases de datos y contexto de ejecución completo. El sistema establece líneas de base de rendimiento en un día y puede alertarle sobre desaceleraciones drásticas y valores atípicos que el monitoreo basado en percentiles no detecta.
“Ahora obtenemos toda esta información para todas las funciones, independientemente del nivel en el que se encuentren, incluso para los paquetes subyacentes”, dijo Eilon. “A veces puedes tener un problema muy profundo y aun así lo vemos muy rápidamente”.
La plataforma proporciona datos a través de cuatro canales:
aplicación web para monitoreo y análisis centralizados
Extensiones IDE para VS Code, JetBrains y Cursor que muestran métricas de producción directamente donde se escribe el código
Servidor MCP que alimenta datos estructurados a agentes de codificación de IA
Sistema de alerta que identifica problemas sin configuración manual
La integración del servidor MCP es fundamental para el desarrollo asistido por IA. Los ingenieros de Monday.com ahora consultan el comportamiento de producción directamente en Cursor.
“¿Puedo hacerle una pregunta a Cursor: Oye, ¿por qué este punto final es lento?” Dijo Eilon. “Cuando utiliza Hud MCP, obtengo todas las métricas granulares y esta función es un 30% más lenta desde su implementación. Así que también puedo encontrar la causa raíz”.
Esto cambia el flujo de trabajo de respuesta a incidentes. En lugar de comenzar en Datadog y profundizar en las capas, los ingenieros comienzan pidiendo a un agente de inteligencia artificial que diagnostique el problema. El agente tiene acceso inmediato a los datos de producción a nivel de rol.
De incidentes vudú a soluciones minuciosas
El cambio de la capacidad teórica al impacto práctico queda claro en la forma en que los equipos de ingeniería utilizan realmente los sensores de tiempo de ejecución. Lo que antes requería horas o días de trabajo detectivesco ahora se puede resolver en minutos.
“Estoy acostumbrado a tener estos incidentes vudú en los que hay un pico de CPU y no sabes de dónde vino”, dijo Eilon. “Hace unos años tuve un incidente como este y tuve que construir mi propia herramienta que toma el perfil de la CPU y el volcado de memoria. Ahora solo tengo todos los datos de la función y he visto a los ingenieros resolverlo muy rápidamente”.
En Drata, el impacto cuantificado es dramático. La empresa creó un comando de clasificación interno que los ingenieros de soporte ejecutan en sus asistentes de inteligencia artificial para identificar instantáneamente las causas fundamentales. El trabajo de clasificación manual se ha reducido de aproximadamente 3 horas por día a menos de 10 minutos. El tiempo promedio de resolución mejoró en aproximadamente un 70%.
El equipo también genera un informe diario de “Atención” sobre errores rápidos. Dado que ya se ha detectado la causa raíz, los desarrolladores pueden solucionar estos problemas en minutos. Los ingenieros de soporte ahora realizan diagnósticos forenses que antes requerían un desarrollador senior. El rendimiento de tickets aumentó sin ampliar el equipo de L2.
Dónde encaja esta tecnología
Los sensores de tiempo de ejecución ocupan un espacio distinto de los APM tradicionales, que destacan en el monitoreo del nivel de servicio pero tienen dificultades con datos granulares y rentables a nivel de función. Se diferencian de los monitores de errores que detectan excepciones sin contexto empresarial.
Los requisitos técnicos para soportar agentes codificadores de IA difieren de la observabilidad humana. Los agentes necesitan datos estructurados a nivel de rol sobre los que puedan razonar. No pueden analizar ni correlacionar registros sin procesar como lo hacen los humanos. La observabilidad tradicional también supone que puede predecir lo que necesitará para depurar e instrumentar adecuadamente. Este enfoque falla con el código generado por IA, donde es posible que los ingenieros no comprendan profundamente todas las funciones.
“Creo que estamos entrando en una nueva era de código generado por IA y este rompecabezas, este rompecabezas de una nueva pila emergente”, dijo Adler. “Simplemente no creo que la pila de observabilidad de la computación en la nube sea perfecta para cómo será el futuro”.
¿Qué significa esto para las empresas?
Para las organizaciones que ya utilizan asistentes de codificación de IA como GitHub Copilot o Cursor, la inteligencia en tiempo de ejecución proporciona una capa de seguridad para las implementaciones de producción. La tecnología permite lo que Monday.com llama “investigación de agentes” en lugar de saltar manualmente entre herramientas.
La implicación más amplia está relacionada con la confianza. “Con el código generado por IA, estamos obteniendo mucho más código generado por IA y los ingenieros están empezando a no conocer todo el código”, dijo Eilon.
Los sensores de tiempo de ejecución llenan este vacío de conocimiento al proporcionar un contexto de producción directamente en el IDE donde se escribe el código.
Para las empresas que buscan ampliar la generación de códigos de IA más allá de los pilotos, la inteligencia en tiempo de ejecución aborda un problema fundamental. Los agentes de IA generan código basado en suposiciones sobre el comportamiento del sistema. Los entornos de producción son complejos y sorprendentes. Los datos de comportamiento a nivel de función capturados automáticamente desde la producción brindan a los agentes el contexto que necesitan para generar código confiable a escala.
Las organizaciones deben evaluar si su pila de observabilidad existente puede proporcionar de manera rentable la granularidad que requieren los agentes de IA. Si lograr visibilidad a nivel de función requiere un aumento dramático en los costos de ingesta o instrumentación manual, los sensores de tiempo de ejecución podrían ofrecer una arquitectura más sustentable para los flujos de trabajo de desarrollo acelerados por IA que ya están surgiendo en toda la industria.
