Los que andamos usando agentes de IA para programar todos los días solemos repetir el mismo consejo como loros: «pídele que escriba tests», «usa TDD», «que haga property-based testing». Suena razonable, ¿no? Pues un experimento de Dan Luu acaba de poner en evidencia que buena parte de ese consejo es, como mínimo, cuestionable.
El experimento
La idea es simple de contar y brutal de ejecutar: tomó un agente de código (Codex con GPT-5.6) y le pidió implementar Zstd, el algoritmo de compresión de Facebook, en Rust. 160 corridas por condición, con 26 técnicas de testing distintas: TDD, fuzzing, Lean 4, Verus, Alloy, QuickCheck, testing diferencial, hasta el clásico «no te equivoques» como control de humor. El pass/fail se medía contra tests ocultos, así que no había forma de hacer trampa escribiendo tests tibios que siempre pasan.
El resultado que más me pegó: TDD rindió peor que no pedir nada. Los agentes con prompt de TDD escribieron el doble de tests y trabajaron de forma más iterativa, pero con más frecuencia escribían tests que codificaban comportamiento incorrecto y los hacían pasar igual. Iterar hasta que tus propios tests pasen, cuando tus tests son malos, solo consolida el bug.
Las herramientas formales, deco de escritorio
Con los probadores de teoremas fue todavía más patético. A los agentes con Lean, Verus o Alloy se les dio por probar propiedades aritméticas abstractas que no tenían nada que ver con las partes donde estaban los bugs reales — cosas como «dado un índice válido, la operación se queda dentro de los límites» — mientras ignoraban por completo el jump table de cuatro streams Huffman que era donde todos fallaban. Un agente escribió pruebas vacías del tipo A implica A y las presentó como logro. Es como si te contrataran para auditar un banco y solo contaras las sillas.
El detalle que más me da risa: probó skills de testing de GitHub con 250.000 estrellas y no superaron la condición por defecto. Popularidad en GitHub ≠ calidad, capítulo dos mil.
Mi lectura
Yo uso agentes a diario, así que esto duele un poquito. Pero encaja con lo que he visto en la pega: el agente es un ejecutor brillante y un validador pésimo. No sabe dónde están los casos difíciles de tu problema porque no entiende el dominio, entiende el patrón. Si le pides TDD, genera el ritual de TDD: tests pequeños, verdes, inútiles.
La conclusión práctica que me llevo: para el código que importa, el criterio lo pones tú. Escribir tú mismo los tests que de verdad duelen — los casos borde, los que rompieron la versión anterior — y dejar que el agente corra contra esos, rinde mucho más que cualquier prompt mágico de «usa buenas prácticas». Y desconfía cuando el agente te muestra un test suite enorme y todo verde: eso muchas veces es humo, no calidad.
Lo demoró: los agentes entrenados por los laboratorios no parecen haber aprendido en serio ni fuzzing ni property-based testing, pese a que la técnica existe desde hace décadas. La próxima vez que alguien te venda que la IA ya reemplaza a los QA, muestrale este experimento. Still waiting, po.
Fuente de inspiración: How well do agents use test/verification techniques?
