Un experimento exploratorio de Thoughtworks pone a prueba si obligar a un agente de IA a seguir un flujo de TDD (desarrollo dirigido por pruebas) dentro de su propio bucle aporta valor frente a dejarle escribir pruebas y código sin esa disciplina. La conclusión principal es negativa: usando Sonnet 4.6 para generar soluciones y Opus 4.8 como juez ciego de calidad, no se apreció una diferencia clara a favor del TDD. En los lotes de tareas pequeñas y medianas, Opus clasificó sistemáticamente las soluciones sin TDD en los puestos primero y segundo, y las soluciones con TDD en tercero y cuarto. Solo al reforzar el prompt con un paso explícito de revisión de diseño y refactor una solución TDD logró el primer puesto, aunque la otra solución con el mismo prompt quedó última. En la tarea mayor, las soluciones TDD quedaron en posiciones intermedias. Los mutation scores fueron similares en ambos grupos.
La hipótesis que surge es que los agentes de IA fueron entrenados mayoritariamente con funciones completas y descripciones, no con sesiones paso a paso de TDD. Esto hace que tiendan a diseñar toda la arquitectura, los tipos de datos y los casos límite antes de escribir código, y que ese diseño completo produzca modelos de datos y coberturas de borde ligeramente mejores. Las instrucciones TDD, en cambio, empujan hacia decisiones locales mínimas que cristalizan el diseño impuesto por el primer test y dejan sin implementar los comportamientos para los que no se escribió test. Además, escribir el test primero no garantiza evitar tautologías: en varias sesiones TDD el test simplemente recalculaba la salida esperada ejecutando la misma lógica de la implementación. El artículo forma parte de la serie Exploring Gen AI de Thoughtworks y deja abierta la reflexión sobre qué objetivos del TDD tradicional siguen teniendo sentido cuando el código lo escribe una IA.