Victoria prematura

El primero en entregar el examen

Le pides a un agente la función «restablecer contraseña». Cambia la base de datos, escribe el endpoint, añade la plantilla del correo, ejecuta las pruebas unitarias (todas verdes) y anuncia: «Listo». Tú lo ejecutas de verdad y: el enlace no se envía (falta configurar el correo), la migración falla a mitad y el flujo completo no se ha probado ni una vez.

Es el compañero que rellena todo el examen y es el primero en entregarlo, muy seguro. Que el examen esté lleno no significa que las respuestas estén bien.

Por qué ocurre

La lección cita un resultado clásico: los modelos de redes neuronales modernos suelen estar más seguros de lo que realmente aciertan. El agente «siente» que ha acabado. La cadena habitual es esta:

1. El código se ve correcto: sintaxis bien, lógica razonable.
2. El harness no obliga a ejecutarlo de punta a punta.
3. El agente corre algunas pruebas (las unitarias) y se salta las demás.
4. «Parece bien» se convierte en «está terminado».

Cada paso pierde información entre lo pedido, el código escrito y el comportamiento real.

El problema de la autoevaluación

Anthropic observó algo más profundo: cuando le pides a un agente que evalúe su propio trabajo, tiende a ser sistemáticamente generoso, incluso cuando una persona vería claramente que la calidad no llega. Es el alumno que se corrige su propio examen.

Pedirle «sé más objetivo» no soluciona el problema, porque quien genera y quien evalúa es el mismo. La salida es separar al trabajador del verificador: un evaluador independiente, ajustado para ser exigente. En un experimento descrito en la lección, el mismo modelo y el mismo prompt (un editor de juegos 2D) dieron resultados muy distintos según el harness: un solo agente, unos 20 minutos y 9 dólares, y el juego no respondía; con planificador, generador y evaluador, unas 6 horas y 200 dólares, y el núcleo funcionaba. No es una receta universal ni barata, pero muestra que el entorno cambia el resultado.

Hecho lo decide el harness

Tres decisiones prácticas:

1. Externaliza el juicio de terminación. No es el agente quien dice «hecho». Escríbelo en CLAUDE.md:

## Definition of Done
- Función completa = verificación de extremo a extremo pasada, no «el código está escrito»
- Niveles: 1) pruebas unitarias, 2) pruebas de integración, 3) flujo completo
- No pases al nivel 2 si falla el 1; ni al 3 si falla el 2

2. Prioriza: primero que funcione. Nada de refactorizar «de paso» antes de verificar lo central. Refactorizar mueve la frontera entre código comprobado y no comprobado, y puede romper lo que antes iba bien.

3. Escribe errores que enseñen. En vez de Test failed, algo como: «POST /api/reset-password devolvió 500. Comprueba que existe la configuración del servicio de correo en las variables de entorno y que la plantilla está en templates/reset-email.html». Un buen profesor no tacha: indica cómo corregir. El agente puede entonces arreglarlo solo.

Señales de ejecución, no de lectura

Lo que prueba que algo funciona: ¿la aplicación arrancó y llegó a estar lista? ¿La ruta crítica se ejecutó? ¿Los efectos secundarios (escrituras en base de datos, archivos) fueron correctos? ¿Se limpiaron los recursos temporales?

Cómo organizar esas comprobaciones por capas lo vemos en verificar en tres capas.