“Otros modelos seguían señalando lo mismo una y otra vez, incluso después de que lo hubiéramos solucionado. Cuando le dimos una oportunidad a Enter Pro, descubrió cuál era la causa real”.

WhyVenv construyó Kronos, un agente autónomo de respuesta a incidentes para Quackathon, para ayudar a los ingenieros a pasar de los errores de producción a la causa raíz más rápido.

El buscapersonas es solo el comienzo

Cuando la producción falla, la alerta rara vez es la parte difícil.

Grafana puede decirte que algo no funciona. Los registros pueden decirte que algo falló. Un panel de control puede parpadear en rojo con la fuerza suficiente para despertar a alguien a las 2 de la madrugada.

Pero después de eso, comienza el trabajo real.

Un ingeniero todavía tiene que abrir los registros, comprender el error, buscar en el código base, adivinar qué función importa, decidir si el problema es urgente y determinar si el siguiente paso correcto es un problema de GitHub, un parche o una escalada completa.

Esa brecha entre saber que algo falló y comprender qué falló es donde la respuesta a incidentes se vuelve dolorosa.

También es donde Dawood Khan encontró la idea para Kronos.

Dawood estudió IA, pero después de la universidad se acercó más a la ingeniería de sistemas. Su interés no era abstracto. Había visto cómo fallan los sistemas de producción, cómo responden los equipos y cuánta investigación manual todavía se interpone entre una alerta y una solución.

At un evento de Grafana en Hyderabad, el problema se volvió aún más claro. Los ingenieros describían el mismo patrón: el sistema se cae, alguien recibe la llamada y luego el equipo comienza el trabajo familiar de rastrear la falla a mano.

Quackathon se convirtió en el momento de construir algo diferente. Construido por WhyVenv, Kronos pasó a ganar el Segundo Lugar en Quackathon, destacándose en el desafío Track 01: Software - The Sentient Workspace por convertir la respuesta a incidentes de producción en un flujo de trabajo agéntico.

Qué construyó WhyVenv

El proyecto de WhyVenv fue Kronos, un agente autónomo de respuesta a incidentes construido para la categoría Sentient Workspace de Quackathon.

La idea era sencilla, pero ambiciosa:

Kronos recibe errores de producción, lee los registros, recupera el código relevante, le pide a un modelo de IA que diagnostique la causa raíz probable y luego decide qué debe suceder a continuación.

A veces eso significa abrir un problema en GitHub.

A veces, dependiendo de la gravedad del problema, significa intentar una solución.

El objetivo no es solo notificar al ingeniero que la producción falló. El objetivo es darle al ingeniero una ventaja en el trabajo que normalmente sigue a la alerta.

En palabras de Dawood durante la entrevista, las alertas de Grafana facilitaban saber cuándo algo no funcionaba. El problema era todo lo que venía después: encontrar qué causó el problema, dónde vivía el error y qué acción debía tomar el equipo.

Kronos fue construido para automatizar esa capa intermedia.

La visión de ingeniería detrás de Kronos

“La parte de la que estaba más orgulloso fue la etapa de recuperación. En lugar de usar solo AST o incrustaciones, trabajamos a partir de los registros de seguimiento, porque así es como los ingenieros suelen encontrar el problema”.

La parte de la que Dawood estaba más orgulloso no era el panel de control, la integración con GitHub o incluso el diagnóstico de IA.

Era la etapa de recuperación.

Muchos sistemas de codificación de IA intentan comprender un código base a través de incrustaciones, análisis AST o carga de contexto amplio. Kronos tomó una ruta más nativa para los ingenieros: comenzar desde los registros de seguimiento y usarlos para reducir la búsqueda.

Esa elección importa.

Cuando los ingenieros depuran fallas de producción, rara vez comienzan pidiéndole a un modelo de IA que lea todo el repositorio. Miran el error. Siguen el seguimiento de la pila. Buscan en el código. Pasan del síntoma a la fuente.

Kronos fue diseñado en torno a ese mismo instinto.

El sistema utiliza los registros como punto de entrada, recupera el código que parece más relevante y solo entonces introduce el modelo de IA en el flujo de trabajo. Eso hace que el modelo sea menos un oráculo que todo lo ve y más un revisor que trabaja a partir de un paquete enfocado de evidencia.

Dawood fue claro en que el enfoque aún necesita refinamiento antes de que se pueda confiar en él a gran escala. Pero para la demostración, funcionó. Más importante aún, reflejó un instinto de producto serio: los mejores sistemas de IA no reemplazan el flujo de trabajo de ingeniería a ciegas. Aprenden de cómo los ingenieros ya resuelven los problemas.

Construyendo la pila de observabilidad con Enter Pro

Kronos tuvo que trabajar con herramientas que el equipo no había utilizado profundamente antes.

Grafana. Prometheus. Loki. Paneles de control. Registros. Métricas. Alertas.

Para un equipo de hackathon, esa es mucha infraestructura que comprender antes de que el producto real pueda comenzar a funcionar.

Aquí es donde Enter Pro resultó útil para WhyVenv.

El equipo utilizó Enter Pro durante todo el proyecto para investigación, refinamiento de ideas y depuración. Dawood y sus compañeros de equipo lo usaron para comprender la pila de observabilidad, descubrir cómo encajaban los componentes y superar los problemas de integración cuando el sistema no se comportaba como se esperaba.

Un momento se destacó.

El equipo estaba atascado en por qué sus alertas de datos no llegaban correctamente. Habían probado otros modelos de IA, pero Dawood sintió que algunos de ellos seguían dando vueltas sobre el mismo punto incluso después de que el equipo ya lo hubiera solucionado.

Cuando le dieron una oportunidad a Enter Pro, les ayudó a identificar la causa real de manera más directa.

Ese es el tipo de momento que importa en un sprint de construcción. No una respuesta de demostración pulida. No una sugerencia genérica. Un impulso concreto a través de un bloqueador real.

Para WhyVenv, Enter Pro no era solo un lugar para generar código. Era una forma de razonar a través de sistemas desconocidos lo suficientemente rápido como para seguir construyendo.

Dos días de enfoque

Dawood había planificado el proyecto antes de que el equipo comenzara el desarrollo serio.

Sabía lo que querían construir. Había pensado en la arquitectura básica. Tenía una idea aproximada de cómo debía dividirse el trabajo.

Luego, el ritmo real del hackathon se impuso.

El primer día no fue todo código. El equipo pasó tiempo junto, habló, bromeó y encontró su camino. La construcción real vino después de eso: un sprint concentrado donde dividieron el trabajo, investigaron partes desconocidas, implementaron el flujo central y refinaron el producto hasta que pudo sostenerse.

La arquitectura comenzó simple:

informe de fallas -> código relevante -> diagnóstico de LLM -> problema o solución.

Luego, cada parte se volvió más nítida a medida que el equipo construía.

Esa simplicidad es parte de por qué Kronos es convincente. No comienza con una teoría complicada de software agéntico. Comienza con un flujo de trabajo que todo ingeniero de guardia comprende: algo falló, encuentra la causa, decide qué hacer a continuación.

Lo que Kronos sugiere sobre los agentes de IA

Kronos no es un chatbot sentado al lado de un código base.

Está más cerca de un agente de flujo de trabajo: un sistema que recibe una señal del mundo real, reúne la evidencia correcta, pide razonamiento solo donde el razonamiento es útil y luego dirige el resultado hacia las herramientas que los ingenieros ya usan.

Esa distinción importa.

Dawood es sensible a los problemas de costo y control en torno a los sistemas de IA. En la entrevista, habló sobre el uso de tokens, las costosas llamadas a modelos y la importancia de no dejar que un agente se encargue de todo cuando la lógica determinista del backend puede hacer parte del trabajo de manera más eficiente.

Ese es un instinto maduro para alguien que construye con IA en 2026.

El futuro de los agentes de IA no se tratará solo de usar modelos más fuertes. También se tratará de saber cuándo no usarlos. ¿Qué partes deberían ser código? ¿Qué partes deberían ser recuperación? ¿Qué partes deberían ser razonamiento del modelo? ¿Qué partes deberían permanecer bajo revisión humana?

Kronos, incluso como proyecto de hackathon, apunta hacia esa pregunta.

Qué viene después

El proyecto aún tiene preguntas que responder antes de estar listo para producción:

¿Qué tan bien escala el enfoque de recuperación en códigos base más grandes?
¿Cómo se deben calibrar la gravedad y la autonomía?
¿Cuándo debería un agente abrir un problema en lugar de intentar una solución?
¿Cuánto contexto es suficiente para que un modelo diagnostique un incidente real?
¿Qué deben aprobar los humanos antes de que algo llegue a producción?

Esas no son preguntas pequeñas. Son exactamente las preguntas que hacen que valga la pena prestar atención a Kronos.

Porque los incidentes de producción no van a desaparecer. La única pregunta es si cada respuesta tiene que comenzar con pánico manual.

Kronos imagina un primer paso diferente: uno donde el sistema que ve la falla también puede comenzar a comprenderla.

Eso es lo que Enter existe para apoyar.

No solo código más rápido. Un movimiento más rápido desde un punto de dolor real hacia un producto que funciona.

Y para WhyVenv, ese movimiento fue suficiente para convertir un patrón de ingeniería doloroso en uno de los proyectos ganadores de Quackathon.

Explora Kronos.

Esta historia es parte de nuestra Serie de Creadores de Quackathon, donde analizamos un proyecto a la vez para comprender qué hicieron los creadores con Enter Pro, por qué lo construyeron y qué nos dice su trabajo sobre el futuro de la creación de software impulsada por IA. Mantente atento.