Primero la prueba, y cuidado con el agente que la retoque: TDD impuesto a las máquinas

TDFlow alcanza un 88,8 % en SWE-Bench Lite cuando las pruebas se proporcionan antes del código. En Maestro, las pruebas se escriben ANTES de cada historia desde julio, con una regla sencilla: se señala al agente que modifica una prueba, aunque ya existiera.

Un artículo de investigación reciente muestra que TDFlow alcanza un 88,8 % de éxito en SWE-Bench Lite cuando las pruebas humanas se proporcionan antes de escribir el código (arxiv.org/pdf/2510.23761). En Maestro, los contratos de verificación de cada historia quedan fijados antes del desarrollo desde julio, con una regla estricta: se señala al agente que modifica una prueba, aunque ya existiera.

La IA que hace trampas en el examen

El problema documentado por los desarrolladores que trabajan con agentes es concreto. En Hacker News: «es imposible que un agente de programación se contenga y no entregue PRIMERO una implementación completa, de un golpe. Y DESPUÉS genera la prueba» (burnerToBetOut, news.ycombinator.com/item?id=46580108). Y otro, sobre el orden que importa: «si no haces esto, producirá pruebas que pasan pero que en realidad no detectan cuándo se rompen las cosas» (0xbadcafebee, news.ycombinator.com/item?id=48416641). Una prueba escrita después del código se adapta a él; una prueba escrita antes le impone una restricción que el código debe cumplir.

Por qué importa el orden, y no solo que haya pruebas

Un agente que primero escribe una implementación y después genera pruebas para cubrirla califica su propio examen. El contrato invertido (la prueba antes del código, fijada desde el desglose en tareas) evita esta deriva: el código debe cumplir un requisito establecido de antemano, independiente de lo que termine haciendo la implementación. Es el mismo principio que responde a la tercera crítica del hilo «el waterfall contraataca» sobre el LLM como compilador no determinista: el modelo sigue siendo probabilístico, lo que debe cumplir deja de serlo.

Lo que revela una prueba alterada

La parte más delicada no es escribir la prueba antes, sino evitar que una reparación posterior la reescriba discretamente para superarla. Una prueba modificada durante una corrección, aunque existiera antes de que el agente la tocara, activa una alerta explícita. Es un detalle de implementación, pero es lo que hace real la garantía: sin esa alerta, nada impide que un agente bloqueado suavice simplemente el requisito en lugar de corregir el código.

Cuánto nos costó

Implantar esta regla sacó a la luz 13 defectos reales durante la contraverificación posterior, defectos que de otro modo habrían permanecido invisibles hasta que los descubriera un usuario real en producción. El precio también se paga en concisión: el modo exprés, el más rápido, consume un presupuesto metodológico multiplicado por 1,000 (la referencia) y el modo estándar solo por 1,075, un sobrecoste medido y deliberadamente contenido, en lugar de dejarlo crecer. Toda la profundidad adicional que exige el TDD se reserva para los modos estándar y completo, nunca para el exprés, que sigue pensado para un prototipo que se descarta sin remordimientos.

Lo que ves tú: indicadores verdes, no código

Nunca tienes que leer una línea de prueba ni saber qué es una prueba. Lo que te pide la validación humana es juzgar si la historia hace lo que querías, no comprobar el mecanismo técnico que lo demuestra por detrás. El TDD impuesto a los agentes es una póliza de seguro: no lees el contrato línea por línea, compruebas que esté firmado antes del siniestro, no después.