Verificar en tres capas

Las tres revisiones de un coche

Antes de comprar un coche usado haces tres cosas, de más barata a más reveladora. Primero miras la carrocería y los papeles (rápido, descarta lo evidente). Luego arrancas el motor y compruebas que funciona. Por último das una vuelta real por carretera. Un coche puede estar perfecto en el garaje y fallar al salir a la calle.

Con el trabajo de un agente conviene hacer lo mismo: una verificación escalonada, cada capa más cara y más informativa que la anterior.

Capa 1: sintaxis y análisis estático

Es lo más barato y lo que menos información da, pero es obligatorio. Incluye el lint (revisión automática de estilo y errores simples) y la comprobación de tipos. Es como escribir bien las palabras antes de pensar si la frase tiene sentido.

• Qué detecta: errores de escritura, tipos incoherentes, reglas de estilo.
• Qué no detecta: que el programa haga lo que debe.

Capa 2: comportamiento en ejecución

Aquí se ejecuta de verdad: las pruebas, el arranque de la aplicación, las rutas críticas. Es la evidencia central de que algo funciona. No basta con que esté escrito: tiene que ejecutarse.

• Qué detecta: errores de lógica, configuración que falta, pruebas que fallan.
• Qué no detecta: problemas que solo aparecen cuando las piezas trabajan juntas.

Capa 3: confirmación a nivel de sistema

Es la última línea de defensa contra el «hecho» prematuro: pruebas de extremo a extremo, validación de integración y simulación de lo que haría un usuario. No basta con que ejecute: tiene que ejecutarse correctamente de principio a fin.

• Qué detecta: fallos entre componentes, estados que no se propagan, dependencias del entorno.

La regla de oro: en orden y sin saltar

## Verificación de terminación
1. Capa 1: lint y tipos. Si falla, parar y arreglar.
2. Capa 2: pruebas y arranque. Si falla, parar y arreglar.
3. Capa 3: flujo completo de usuario.
Solo si pasan las tres, la tarea está hecha.

Hay dos ventajas. Ahorras tiempo (no tiene sentido lanzar un flujo completo si ni siquiera compila) y obtienes diagnósticos más claros, porque sabes en qué capa falla.

Verificación y validación: dos preguntas

La lección distingue dos puertas. La verificación pregunta: ¿el código implementa bien el comportamiento especificado? La validación pregunta: ¿el sistema entero cumple lo que el usuario necesita de principio a fin? Pasar la primera sin la segunda es típico del «las pruebas están verdes, pero no funciona».

Un ejemplo con la función de contraseña

Siguiendo el caso de la lección anterior, la intervención del harness fue exigir: arrancar la aplicación completa y comprobar que el endpoint de restablecimiento responde, ejecutar el flujo entero de restablecimiento y verificar que la base de datos queda coherente. Los tres fallos que el agente no vio aparecieron dentro de la misma sesión, cuando arreglarlos aún es barato.

La regla de «cuándo está hecho» se completa con la definición de hecho.