Una duda frecuente al empezar a trabajar con agentes de IA es si TDD (escribir primero el test) choca con SDD (desarrollo guiado por especificaciones). La respuesta corta: no. Son capas distintas y se complementan, y se nota especialmente al refactorizar código heredado.
Qué es cada cosa
SDD pone la especificación en el centro: describes qué debe hacer el sistema y el agente trabaja contra esa descripción. Para que funcione hace falta un arnés (harness): un conjunto de archivos, comandos y comprobaciones que fijan cómo se trabaja en el proyecto.
TDD es una práctica concreta dentro de ese trabajo: primero un test que falla (rojo), después el mínimo código que lo pasa (verde) y por último la limpieza (refactor). No compite con la especificación; es una forma de comprobar que se cumple.
El caso del código heredado
En un sistema que ya existe, el orden cambia un poco. Antes de mover una sola línea hay que fijar lo que el sistema hace hoy, incluidos sus errores. Eso se hace con tests de caracterización: afirman el comportamiento actual, campo a campo, para que cualquier cambio posterior que lo altere se note.
Puede resultar chocante ver un test que da por buena una fuga de datos o una respuesta incoherente. No es un error. Un refactor, por definición, no cambia el comportamiento. Si arreglas un fallo de paso, no sabrás nunca si lo que se rompió después fue por el arreglo o por el movimiento. Arreglar un error es otra tarea, con su propio test y su propia decisión.
Dónde encaja un framework de especificaciones
Otra pregunta habitual es por qué no se aplica un framework de especificaciones completo a cada refactor. Es una decisión de equipo, no una obligación técnica. Estos frameworks aportan trazabilidad y un histórico de decisiones, y suelen merecer la pena cuando hay mucha variabilidad de negocio, pero tienen un coste en tiempo y en consumo de tokens. Para una tarea acotada, un comando propio con pasos claros puede ser suficiente.
La regla útil es que los pasos del ritual (explorar, ramificar, caracterizar en rojo, poner en verde, refactorizar, separar los errores, hacer commit) vivan escritos en un archivo del proyecto y no en tu cabeza o en cada prompt. Así, la tarea número cuarenta se parece a la primera.
Un límite honesto
Un comando de refactor genérico rara vez baja a todo el detalle de un equipo: estrategia de merge, cómo se definen nuevos endpoints, qué contrato de API se usa, qué librerías. Conviene revisarlo y completarlo con las decisiones de tu equipo antes de delegarlo.
Resumen rápido
TDD y SDD no se excluyen. Con código heredado, empieza caracterizando el comportamiento actual, refactoriza sin cambiarlo y deja los errores para tareas separadas. Elige el framework de especificaciones según la variabilidad de tu negocio y su coste.