Observabilidad de LLM: 6 lecciones del CTO de Datadog

Lección 1: la IA rompió la forma clásica de revisar código

Empecemos por la presión que desencadena todo lo demás: hay más código del que cualquiera puede leer.

Lê-Quôc es tajante: el modelo antiguo, una persona leyendo un pull request línea a línea, no sobrevive al desarrollo asistido por IA. La inquietud que escucha por toda la industria es que las revisiones se vuelven inviables porque ocurre demasiado como para seguirlo leyendo PRs.

Su respuesta no es pedir a la gente que lea más rápido, sino mover la revisión a otro sitio.

Ese último matiz es fácil pasarlo por alto. Cuando orquestas un agente que planifica, otro que escribe y otro que prueba, también debes evitar que quien escribe "juegue" con las pruebas automatizadas en vez de solucionar el problema.

Va más allá de las pruebas. En Datadog ahora añaden demostraciones semiformales y formales de que una especificación hace lo que debe, algo demasiado exigente como para intentarlo de forma generalizada antes de que los agentes se hicieran cargo del trabajo pesado. Funciona mejor en sistemas de backend y de coordinación, donde el comportamiento es lo bastante matemático como para razonar con precisión.

Lección 2: producción es la única prueba que cuenta

Pasar todas las pruebas en CI es necesario y ni de lejos suficiente. Los fallos que importan llegan después.

Cada versión se apoya en supuestos que no puedes comprobar del todo de antemano, sobre la forma de los datos y el comportamiento de los usuarios. Si expones esos supuestos a suficiente tráfico real, los casos raros dejan de serlo; se convierten en las ralentizaciones y errores del día a día por deriva de datos y de modelos.

Los LLM complican esto: con código normal, al menos puedes razonar por cada rama, pero nadie puede explicar mecánicamente por qué un modelo devuelve lo que devuelve, así que la misma entrada nunca garantiza la misma salida. Los resultados extraños ocasionales no desaparecen con ingeniería.

Así que dejas de intentar demostrar que un sistema es correcto antes de enviarlo. En su lugar,

• Escribes evaluaciones del comportamiento que quieres
• Lo monitorizas en producción
• Mantienes un control de parada para un despliegue que se tuerza.

La pregunta ya no es si ha pasado, sino si un problema es puntual o el inicio de una tendencia.

Esa señal en vivo no es solo un panel para humanos. Conectada al sistema de despliegue, permite a un agente extender un cambio como lo haría una ingeniera prudente: al uno por ciento de usuarios, luego al cinco, juzgando con datos reales si el cambio logra lo previsto.

Lección 3: deja la carga a los agentes

El argumento de Lê-Quôc a favor de los agentes no es que reemplacen a las personas ingenieras, sino que asuman las partes del trabajo que desgastan.

Resolver un incidente significa lanzar hipótesis contra un síntoma y, en incidentes largos, a menudo la que se confirma es la más rebuscada. El agente Bits AI de Datadog las comprueba todas en paralelo, por delante de la ingeniera, mientras la persona lo guía hacia esa intuición que un panel nunca sacaría a la luz.

El punto de fondo es la fatiga. Un despliegue en guardia es un pico de alerta seguido de horas de nada, repetido hasta que se resiente tu criterio.

A un agente no le importa, y no empeora tras cuatro horas mirando números. El estrés y la fatiga degradan el rendimiento humano, por eso los equipos rotan a las personas de guardia.

Entrega la vigilancia incansable a una máquina y la gente vuelve descansada para las decisiones que sí los necesitan. Lo mismo aplica al triaje de seguridad, donde los analistas se queman distinguiendo falsos positivos de amenazas reales.

Lección 4: divide el trabajo en dos bucles

Lê-Quôc organiza el trabajo con agentes en Datadog alrededor de dos bucles.

El bucle de desarrollo

A la mayoría de ingenieros les resultará familiar:

1. Escribir código
2. Desplegarlo
3. Ver si funciona
4. Corregirlo
5. Repetir

El enfoque de Datadog es que un problema que nace en el código suele tener su arreglo en el código, así que la plataforma intenta darte esa corrección, informada por lo que sabe de la aplicación: su propiedad, sus cambios recientes y los errores lanzados.

Pone como ejemplo la optimización de consultas de base de datos. Cualquier modelo puede reescribir una consulta lenta; lo difícil es demostrar que la nueva versión es más rápida y segura antes de llegar a producción. Por eso Datadog la prueba primero contra una copia realista de los datos de producción y entrega un pull request con las evidencias adjuntas.

El bucle de operaciones y seguridad

El otro bucle corre en paralelo, ya sea con las mismas personas o con un equipo distinto:

1. Detectar
2. Investigar
3. Corregir
4. Repetir

Aquí es donde AI Guard de Datadog prioriza eventos de seguridad y bloquea ataques más rápido que un analista trabajando a mano. Los agentes también pueden encargarse de tareas operativas rutinarias que los ingenieros hacen a diario sin demasiado entusiasmo, como redimensionar ese pod de Kubernetes.

En ambos bucles, Lê-Quôc es firme con el orden de operaciones. Datadog no parte de "aquí hay IA, ¿qué problema puede resolver?". Parte de un problema que los clientes ya lamentan, normalmente alguna versión de "no quiero hacer esta tarea repetitiva", y a partir de ahí decide si se puede confiar en un agente.

Lección 5: controla el gasto en IA

El coste es la restricción que se sienta junto a la seguridad, y mantener a raya el precio de la puesta en producción de grandes modelos de lenguaje está convirtiéndose en una disciplina propia. La respuesta de Lê-Quôc en DASH es el Agent Console de Datadog.

Si preguntas a una desarrolladora qué modelo necesita, a menudo dirá el más potente (y caro). A veces es la elección correcta, pero mucho trabajo es rutinario y un modelo más barato y rápido lo resuelve igual de bien. Distinguir entre ambos exige leer las trayectorias de los agentes de la organización: qué herramientas llaman y con qué frecuencia tienen éxito, hasta que aparecen patrones.

Esos patrones se convierten en heurísticos más que en reglas: un modelo puntero como el último Claude Opus o los modelos GPT para planificar; algo económico como Claude Haiku para generar pruebas.

El principio de fondo trata sobre quién toma la decisión. Si agregas el coste a un único número, obtienes lo que Lê-Quôc llama "muy poca accionabilidad": o todo el mundo deja de gastar, lo que mata trabajo útil, o todo el mundo sigue gastando, lo que el negocio no sostiene. Prefiere poner los datos delante de desarrolladores y SRE que eligen los modelos.

Lección 6: aprende a aprender

Cuando le preguntan qué deberían estudiar quienes empiezan en ingeniería, Lê-Quôc da una respuesta que suena clásica pero no lo es.

Los modelos son los tutores más pacientes jamás inventados, capaces de explicarte cualquier cosa al ritmo que necesites, un nivel de acceso que antes estaba reservado a la realeza con profesores particulares. Pero un tutor solo es útil si lo interrogas. La habilidad es saber qué preguntar y cómo comprobar la respuesta.

Recomienda entender los ordenadores capa a capa en vez de tratarlos como magia. Toma un planificador, un balanceador de carga, un sandbox, y pídele a un modelo que te explique cómo funciona, luego sigue profundizando:

• ¿Qué significa este término?
• ¿Cómo se mide?
• ¿Cuál es la matemática detrás?
• ¿Cómo sabes que funciona bien?

Estudiar los clásicos así es lento a propósito. Lo compara con aprender un instrumento: puedes escuchar música todo el día, pero para tocar el piano tienes que poner las manos en las teclas.

Con el código escrito por IA pasa lo mismo. El vibe coding está bien, dice, siempre que luego vuelvas y preguntes por qué funcionó: por qué se construyó así, si hay enfoques mejores, en qué se inspiró. El objetivo no es escribir menos código con IA, sino entender el código del que ahora produces mucho más.

Reflexión final

El mensaje central de Lê-Quôc es que el bucle no ha cambiado, pero el ritmo sí. Lo diferente es que ninguna persona puede vigilar lo bastante de cerca a la velocidad a la que ahora se mueve la IA, así que la vigilancia, y una parte creciente de la construcción, pasa a agentes que no se cansan ni se inquietan.

Defiende tratar la observabilidad como un plano de control, no como un conjunto de gráficos. Si los agentes van a escribir, probar, desplegar y operar software, necesitan el mismo anclaje en datos reales de producción en el que confían las buenas ingenieras, además de una persona para las decisiones de juicio y el botón de parada. Datadog está posicionando la observabilidad como la capa que hace segura esa apuesta.

La habilidad que esta visión exige a las personas ingenieras es clara: leer los sistemas por cómo se comportan en producción, no solo por su código fuente. Si quieres construir ese hábito, nuestro itinerario de habilidades Machine Learning in Production es un buen lugar para empezar.