Ver lo que hace el agente

El «no estoy seguro» que sale caro

Le pides a un agente una función nueva. Trabaja veinte minutos, toca muchos archivos y dice: «Terminado, pero fallan dos tests». Preguntas por qué. Responde: «No estoy seguro, quizá es un problema de tiempos». Preguntas qué partes críticas ha cambiado. Responde: «Déjame mirar el código…».

El agente no es torpe. Lo que pasa es que su harness no le deja ver nada. Es como conducir de noche con los faros apagados: puedes seguir adelante, pero cada decisión es una apuesta.

Las dos capas

El curso separa la observabilidad en dos capas que se refuerzan:

Las señales de ejecución explican el comportamiento. Los artefactos de proceso explican la intención. Necesitas las dos: un log sin criterios dice qué pasó pero no si estaba bien, y un criterio sin logs no te dice si se cumplió de verdad.

Cuatro problemas cuando no hay observabilidad

1. «Correcto» y «parece correcto» se confunden. El código se ve perfecto en revisión, pero con cierta entrada rara se desvía. Solo la traza de ejecución lo muestra.
2. La evaluación se vuelve mística. Sin criterios escritos, la misma salida recibe notas muy distintas según quién la mire.
3. Los reintentos son al azar. Si el agente no sabe por qué falló, arregla lo que le parece. Cada intento ciego gasta tiempo y tokens.
4. El traspaso se rompe. La siguiente sesión tiene que redescubrir el estado desde cero.

Por qué no basta con «que el agente imprima sus logs»

Es tentador pedirle al agente que se vigile solo. No funciona bien por tres razones: no registrará lo que no sabe que necesita, cada sesión usará un formato distinto (imposible analizarlas en conjunto), y los contratos y rúbricas son documentos estructurados que necesitan apoyo del harness. La recogida de señales la hace el harness, no el agente.

Un ejemplo mínimo: log estructurado

Compara un console.log("fallo") con una línea que se puede buscar y comparar:

{"timestamp":"2026-01-10T10:02:11Z","level":"error","component":"ChunkIndexer","action":"embed_and_store","durationMs":230,"correlationId":"req-a1b2c3","error":"timeout al guardar el fragmento 12"}

Tiene componente, acción, duración y un identificador (correlationId) que une todas las líneas de una misma petición. Filtrando por ese identificador ves el camino completo y localizas dónde se rompió, sin adivinar.

Señales que conviene que el harness recoja solo: arranque y parada de la aplicación, rutas críticas (entrada, puntos intermedios, salida), datos que pasan entre componentes, uso anómalo de recursos y errores con contexto completo.

Con y sin observabilidad

El material del curso compara una misma tarea («añadir modo oscuro»). Sin observabilidad: un plan vago, un evaluador que rechaza «porque no se siente bien» y tres o cuatro rondas de reintentos ciegos. Con ella: un contrato claro, señales de ejecución y una rúbrica por dimensiones, y una sola ronda basta. La diferencia es que el contrato y la evidencia existen fuera de la cabeza del agente. Las dos piezas de proceso son las siguientes lecciones: el contrato de sprint y la rúbrica del evaluador.