El CEO de Hud, Roee Adler, dice que la inteligencia de ejecución definirá la próxima era de las operaciones de software.

      La inteligencia artificial ha acelerado drásticamente el desarrollo de software, con agentes de codificación ahora capaces de producir grandes volúmenes de código listo para producción en minutos. Sin embargo, aunque escribir software se ha vuelto más rápido, garantizar que el software se comporte correctamente en producción sigue siendo uno de los mayores desafíos de la ingeniería. Durante décadas, las plataformas de observabilidad han ayudado a los equipos a monitorear la infraestructura a través de registros, métricas y trazas. Pero según Roee Adler, CEO de Hud, el rápido aumento del desarrollo asistido por IA está exponiendo las limitaciones de los sistemas diseñados originalmente para operadores humanos en lugar de agentes de codificación autónomos.

      El software se está escribiendo para una era diferente

      Adler cree que el cambio no se trata simplemente de adoptar herramientas de IA. En cambio, se trata de reconocer que el desarrollo de software en sí mismo está experimentando una transformación fundamental. Como explica, “El cambio fundamental es que el software ya no se escribe principalmente por humanos utilizando los procesos de ingeniería que hemos refinado durante décadas; lo están escribiendo agentes de codificación que son una especie completamente diferente.” Esos agentes, dice, son “rápidos, impacientes, agresivos”, pero también carecen del contexto de producción necesario para tomar decisiones seguras de manera consistente en entornos complejos. En lugar de ralentizar la adopción de IA, Adler cree que la industria debería construir la infraestructura que permita a los agentes de codificación convertirse en colaboradores de confianza. En su opinión, el objetivo no es reemplazar a los ingenieros, sino equipar a la IA con suficiente comprensión del mundo real para operar con confianza en producción.

      El desarrollo más rápido ha creado un nuevo cuello de botella

      Aunque la IA está aumentando drásticamente la cantidad de código que los desarrolladores pueden producir, Adler argumenta que las organizaciones no están viendo la misma aceleración en la entrega general de software. El problema, dice, no es que los equipos de ingeniería enfrenten de repente nuevos puntos ciegos operativos. En cambio, los procesos de revisión y validación existentes no fueron diseñados para el ritmo del desarrollo generado por IA. A medida que más código llega a producción, mantener la confianza se vuelve más difícil. Adler señala que, aunque los ingenieros individuales están siendo más productivos, “el cuello de botella se trasladó a la puerta, que intentaba evitar que los cambios malos rompieran el sistema.” Cree que las organizaciones de ingeniería ahora enfrentan dos preguntas urgentes: cómo revisar un volumen cada vez mayor de código generado por IA mientras se asegura que la intención comercial se preserve, y cómo preservar el conocimiento institucional a medida que menos ingenieros entienden cada rincón de las bases de código cada vez más generadas por IA.

      Por qué la observabilidad no es suficiente para la IA

      Los equipos de ingeniería ya invierten mucho en registros, métricas, trazas y plataformas de monitoreo del rendimiento de aplicaciones. Esos sistemas siguen siendo valiosos para identificar cuándo los servicios se vuelven poco saludables, pero Adler argumenta que no fueron diseñados para proporcionar el tipo de evidencia que requieren los sistemas de IA. Como él lo expresa, “Están construidos para mostrar que algo está mal, no por qué.” Si bien los registros, métricas y trazas pueden ayudar a los ingenieros a investigar incidentes, “Los agentes iterando sobre registros es lo que tenemos hoy, y es insuficiente.” En cambio, Adler cree que la IA requiere “contexto estructurado a nivel de función que describa lo que realmente se ejecuta,” dando a los modelos visibilidad directa sobre cómo se comporta el código en condiciones de producción reales en lugar de pedirles que infieran el comportamiento a partir de telemetría fragmentada. Esa filosofía forma la base de lo que Hud llama inteligencia en tiempo de ejecución.

      Por qué el contexto importa más que más datos

      La observabilidad tradicional a menudo produce enormes volúmenes de telemetría, dejando a los ingenieros reconstruir fallos después del hecho. Adler argumenta que simplemente recopilar más información no resuelve el problema si los detalles críticos permanecen enterrados. Como explica, “Más telemetría es un mayor pajar, y la aguja es la única cosa que viniste a buscar.” Cuando ocurren incidentes en producción, los ingenieros no necesitan terabytes de registros. En cambio, necesitan el flujo de ejecución exacto, los parámetros afectados, las rutas de código, el comportamiento de las dependencias y el contexto forense circundante que explique por qué ocurrió un fallo. El enfoque de Hud se centra en capturar automáticamente ese contexto forense a medida que ocurren los incidentes, en lugar de requerir que los ingenieros predigan qué registros, paneles o instrumentación necesitarán de antemano. Adler argumenta que este cambio es cada vez más importante porque la configuración manual inevitablemente deja brechas de cobertura. “Cualquier cosa que dependa de la configuración se aplica de manera desigual,” dice, añadiendo que las organizaciones a menudo pasan por alto los mismos fallos que nunca anticiparon.

      Inteligencia en tiempo de ejecución como una nueva capa arquitectónica

      Aunque muchos proveedores de observabilidad están agregando asistentes de IA a productos existentes, Adler no ve la inteligencia en tiempo de ejecución como una característica incremental. En cambio, argumenta que “Es una capa diferente, no una característica que agregas.” Simplemente colocar IA sobre telemetría muestreada significa que el modelo hereda cada limitación de los datos subyacentes. La inteligencia en tiempo de ejecución, en contraste, cambia qué información se captura desde el principio, produciendo un contexto consciente de producción estructurado específicamente para el razonamiento de IA en lugar de la investigación humana. Esa distinción también explica el énfasis de Hud en capturar el contexto de ejecución sin muestreo. Según Adler, el muestreo funciona bien para paneles y tendencias a largo plazo, pero se vuelve problemático durante la respuesta a incidentes porque el raro evento que desencadenó la interrupción puede ser exactamente lo que se descarta. Dado que la IA razona solo a partir de la información que se le proporciona, la falta de datos de producción no solo ralentiza las investigaciones; puede llevar a los modelos hacia conclusiones incorrectas.

      El futuro es revisar la IA, no depurarla

      Mirando hacia adelante, Adler espera que los ingenieros pasen mucho menos tiempo investigando manualmente incidentes en producción y significativamente más tiempo validando correcciones generadas por IA. Señala a organizaciones que ya están viendo reducciones dramáticas en el tiempo de investigación una vez que la información sobre la causa raíz se captura automáticamente en lugar de reconstruirse manualmente. Pero enfatiza que el mantenimiento autónomo del software depende de dar a la IA acceso directo a la verdad de producción en lugar de suposiciones. Esa misma filosofía se extiende a los despliegues autónomos. Adler cree que las organizaciones eventualmente confiarán en que los agentes de codificación realicen cambios en producción de manera independiente, pero solo después de que esos sistemas demuestren consistentemente un razonamiento transparente y operen dentro de límites de seguridad claros. Como dice, “La confianza se construye sobre evidencia y reversibilidad, no fe.” La IA debería razonar a partir del comportamiento real de producción, explicar sus conclusiones y permitir que los humanos verifiquen o inviertan rápidamente sus decisiones. En última instancia, Adler cree que el desafío definitorio de la era del software de IA no es escribir código más rápido, sino entender cómo se comporta ese código una vez que se despliega. Como concluye, “A medida que la IA escribe más de nuestro software, el recurso escaso ya no es escribir código; es saber cómo se comporta ese código en el mundo real. Quien posea esa comprensión y pueda ponerla frente a personas y agentes es quien envía con confianza y realmente aprovecha el poder de la revolución del código generado por IA.”