Lección 09 — Evitá que el agente declare victoria antes de tiempo

Le pedís a un agente que implemente “restablecimiento de contraseña”. Modifica el esquema de la base de datos, escribe el endpoint, agrega la plantilla de correo, corre las pruebas unitarias (todas pasan) y te dice con confianza “ya está”. Cuando realmente intentás ejecutarlo: el enlace de restablecimiento no se puede enviar (falta la configuración del servicio de correo), la migración falla a mitad de camino (inconsistencia en el esquema) y el flujo end-to-end no se ejecutó ni una sola vez.

La sensación no debería resultarte desconocida: es como llenar todo el examen, ser el primero en entregarlo con confianza y después desaprobar cuando salen las notas. Que el examen esté lleno no significa que las respuestas sean correctas.

No es un incidente aislado. El artículo clásico de Guo et al. (ICML 2017) demostró que las redes neuronales modernas son sistemáticamente sobreconfiadas: la confianza reportada por los modelos es significativamente mayor que su precisión real. Lo mismo se aplica a los agentes de programación: “sienten” que terminaron, pero están lejos. Tu harness debe reemplazar los sentimientos del agente con verificación externalizada basada en ejecución.

La pendiente resbaladiza

flowchart LR
    A["El código parece<br/>correcto"] --> B["El harness no impone<br/>verificación de ejecución"]
    B --> C["Se ejecutan tests<br/>parciales o ninguno"]
    C --> D["«El código se ve bien»<br/>se toma como evidencia"]
    D --> E["Declaración prematura<br/>de finalización"]
    E --> F["Defectos descubiertos<br/>5-10x más caros"]

Se pierde información en cada paso. Desde las especificaciones de la tarea hasta la implementación del código y el comportamiento en runtime, cada transformación puede introducir sesgos, y cada verificación omitida agrava la asimetría de información.

Conceptos clave

• Declaración prematura de finalización: el agente afirma que la tarea está completa pero todavía hay especificaciones de corrección sin cumplir. El problema central: el agente juzga con confianza local a nivel de código, mientras que la corrección a nivel de sistema requiere verificación global.
• Sesgo de calibración de confianza: la brecha sistemática entre la confianza autorreportada y la calidad real. Para tareas complejas de múltiples archivos, este sesgo es significativamente positivo.
• Criterios de terminación: conjunto claro y ejecutable de condiciones definidas en el harness. “Hecho” pasa de juicio subjetivo a determinación objetiva.
• Doble puerta verificación-validación: la verificación comprueba “si el código implementó correctamente el comportamiento especificado”; la validación comprueba “si el comportamiento a nivel de sistema cumple los requisitos end-to-end”. Ambas deben pasar.
• Señales de retroalimentación en runtime: logs, estados de procesos y health checks. Es la base objetiva para que el harness juzgue.
• Restricción de prioridad de finalización: primero corrección funcional, después rendimiento, al final estilo. Se prohíbe la refactorización hasta que la funcionalidad central esté verificada.

Pasar las pruebas unitarias ≠ tarea completada

Esta es la trampa más común y la más peligrosa. La filosofía de diseño de las pruebas unitarias —aislar la unidad bajo prueba y mockear las dependencias— es precisamente lo que las hace incapaces de detectar problemas entre componentes:

Incompatibilidad de interfaces: la ruta de archivo que el proceso de render pasa al preload script es relativa, pero el preload espera una ruta absoluta. Sus respectivas pruebas unitarias usaron mocks y pasaron.

Errores de propagación de estado: una migración cambia el esquema de la tabla, pero la capa de caché del ORM todavía mantiene entradas del esquema anterior. Las pruebas unitarias dan un entorno mock fresco cada vez, así que no exponen esa inconsistencia.

Dependencia del entorno: el código se comporta correctamente donde todo está mockeado, pero falla en el entorno real por diferencias de configuración, latencia de red o indisponibilidad del servicio.

”Refactorizar de paso” envenena el juicio de finalización

Los agentes tienen un patrón de comportamiento común: empiezan a refactorizar, optimizar rendimiento y mejorar estilo antes de que la funcionalidad central haya pasado la verificación. La cita de Knuth —“la optimización prematura es la raíz de todos los males”— adquiere un significado nuevo acá: la refactorización altera la frontera entre el código verificado y el no verificado, potencialmente rompiendo rutas que antes eran implícitamente correctas.

Sesgo sistemático en la autoevaluación

Anthropic descubrió un patrón de fallo más profundo en su investigación de 2026: cuando se le pide a un agente que evalúe su propio trabajo, produce sistemáticamente evaluaciones excesivamente positivas, incluso cuando un observador humano consideraría que la calidad es claramente insuficiente.

El problema es especialmente grave en tareas subjetivas. La solución no es hacer que el agente sea “más objetivo”: el mismo modelo que genera y evalúa inherentemente favorece ser generoso consigo mismo. La solución es separar al trabajador del verificador.

Un agente evaluador independiente, ajustado específicamente para ser exigente, es mucho más efectivo que la autoevaluación:

Arquitectura	Duración	Coste	¿Funcionaban las funciones centrales?
Un solo agente (ejecución desnuda)	20 min	9 USD	No — las entidades del juego no respondían al input
Tres agentes (planner + generator + evaluator)	6 h	200 USD	Sí — el juego era completamente jugable

Mismo modelo (Opus 4.5), mismo prompt. La única diferencia es el harness: de “ejecución sin arnés” a “el planner expande los requisitos → el generator implementa función por función → el evaluator hace pruebas reales de clics con Playwright”.

Fuente: Anthropic — Harness design for long-running application development

Cómo evitar las entregas prematuras

1. Externalizá el juicio de terminación

El juicio de finalización no debería hacerlo el agente. El harness debe ejecutar independientemente la validación, usando señales de runtime como entrada:

## Definition of Done
- Función completa = verificación end-to-end pasada, no "el código está escrito"
- Niveles de verificación requeridos:
  1. Pruebas unitarias pasan
  2. Pruebas de integración pasan
  3. Verificación del flujo end-to-end pasa
- No avanzar al nivel 2 si falla el 1
- No avanzar al nivel 3 si falla el 2

2. Construí una validación de terminación en tres capas

flowchart TD
    C1["Capa 1 — Sintaxis y análisis estático<br/>Menor costo, menor información<br/>«escribí bien las palabras»"]
    C2["Capa 2 — Comportamiento en runtime<br/>Tests, arranque de la app, rutas críticas<br/>«se ejecuta»"]
    C3["Capa 3 — Confirmación a nivel de sistema<br/>E2E, integración, escenarios de usuario<br/>«se ejecuta correctamente»"]
    C1 -->|pasa| C2
    C2 -->|pasa| C3
    C3 -->|pasa| DONE["Terminado"]
    C1 -->|falla| STOP["No avanzar"]
    C2 -->|falla| STOP
    C3 -->|falla| STOP

3. Diseñá buenas “correcciones con lapicera roja”

OpenAI introdujo un patrón particularmente efectivo en su práctica con Codex: los mensajes de error para agentes deben incluir instrucciones de corrección. No dibujes una X roja gigante como un corrector perezoso; escribí en el margen cómo se arregla.

❌ "Test failed"

✅ "Test failed: POST /api/reset-password devolvió 500.
   Verificá que la config del servicio de correo exista en las variables de entorno.
   El archivo de plantilla debería estar en templates/reset-email.html."

Esta retroalimentación específica y accionable permite al agente autocorregirse sin intervención humana.

4. Capturá señales de runtime

Las señales efectivas incluyen:

• ¿La aplicación arrancó y alcanzó un estado listo?
• ¿Las rutas de funcionalidad crítica se ejecutaron con éxito?
• ¿Las escrituras en base de datos, operaciones de archivos y otros efectos secundarios fueron correctos?
• ¿Se limpiaron los recursos temporales?

Caso del mundo real

Tarea: implementar restablecimiento de contraseña. Involucra operaciones de base de datos, envío de correo y modificaciones de endpoints.

Ruta de entrega prematura: el agente modifica el esquema, escribe el endpoint, agrega la plantilla, corre las pruebas unitarias (pasan) y declara finalización.

Defectos reales:

1. Flujo end-to-end sin probar: el envío y verificación real del enlace nunca se confirmó.
2. La migración falló después de una ejecución parcial, causando inconsistencia en el esquema.
3. Faltaba la configuración del servicio de correo en el entorno destino.

Intervención del harness: validación de terminación impuesta —arrancar la aplicación completa para verificar accesibilidad del endpoint, ejecutar el flujo completo de restablecimiento y verificar la consistencia del estado de la base de datos—. Todos los defectos se encontraron dentro de la sesión, ahorrando entre 5 y 10 veces el costo de correcciones posteriores.

Ideas clave

• Los agentes son sistemáticamente sobreconfiados: el sesgo de calibración es una realidad objetiva.
• El juicio de finalización debe externalizarse: el harness verifica independientemente; no confíes en los sentimientos del agente.
• Las tres capas de validación son esenciales: sintaxis, comportamiento y sistema, progresando capa por capa.
• Los mensajes de error deben incluir la corrección para que el agente pueda autocorregirse.
• Sin refactorización hasta que la funcionalidad central esté verificada.

Ejercicios

1. Diseño de validación de terminación: diseñá una validación completa para una tarea que involucre una migración de base de datos y una modificación de API. Enumerá las señales de runtime requeridas y los criterios de aprobación de cada una.
2. Medición del sesgo de calibración: elegí 10 tipos de tareas y registrá la confianza autorreportada del agente contra la calidad real. Calculá el sesgo y analizá su relación con la complejidad.
3. Experimento de defensa en capas: corré tres configuraciones en el mismo conjunto de tareas: (a) solo análisis estático, (b) agregar pruebas unitarias, (c) validación completa en tres capas. Compará la proporción de declaraciones prematuras y los defectos no detectados.

Lecturas adicionales

• On Calibration of Modern Neural Networks — Guo et al.
• Anthropic: Building Effective Agents
• Anthropic: Harness design for long-running application development
• The Art of Software Testing — Myers

---

Anterior: Lección 08 — Listas de funciones como primitivas del harness · Siguiente: Lección 10 — Solo las pruebas end-to-end son verificación real