TDD, systematic-debugging, verification-before-completion: Tres Guardarraíles de Calidad para Agentes de IA

Los artículos anteriores cubrieron cómo secuenciar requisitos, diseño y planificación. Una vez que realmente entras en la fase de "escribir código," el agente puede escribir a una velocidad vertiginosa — rápido no significa correcto. Superpowers tiene otro conjunto de skills de proceso específicamente para mantener la calidad durante la implementación: test-driven-development, systematic-debugging y verification-before-completion. Este artículo explica en lenguaje sencillo qué puerta guarda cada uno, cuándo llamarlos, y los errores de mentalidad más comunes que cometen los principiantes.

Por Qué los AI Agents Necesitan Guardarraíles de Calidad

Los modelos son excelentes en "parecer terminados": los archivos están modificados, las descripciones son seguras — pero el comportamiento puede estar mal, los casos extremos sin probar, el entorno nunca realmente ejecutado. Sin guardarraíles de calidad, lo que obtienes es una sensación narrativa de finalización, no finalización verificable.

Tres guardarraíles de calidad en una oración: usa pruebas para definir "correcto," usa systematic-debugging para trazar hasta la raíz, usa verificación previa a la finalización para prohibir las firmas con las manos vacías. No garantizan que nada se rompa nunca, pero reducen la probabilidad de "pensé que estaba bien pero no lo estaba." Para principiantes, agregar flujo de trabajo y guardarraíles de verificación frecuentemente reduce el retrabajo sin cambiar de modelo — aunque el modelo en sí todavía afecta la comprensión y la calidad de la salida. Los guardarraíles mejoran la forma en que trabajas; no afirman anular las limitaciones del modelo.

Qué Protege TDD

TDD (como en el skill test-driven-development en este flujo de trabajo) protege esto: primero declares claramente "qué cuenta como correcto," luego dejas que la implementación lo satisfaga — no al revés, donde te convences de que la implementación probablemente está bien.

Las mentalidades que intenta prevenir:

"Primero escríbelo, agrega pruebas después": Las pruebas terminan acomodando el código, en lugar de que el código satisfaga los requisitos.
"Este cambio es pequeño, no necesita pruebas": Los cambios pequeños son donde pisas más minas, porque tus suposiciones mentales no han sido desafiadas por nada.
Usar console.log como verificación: Funcionar una vez no significa funcionar para todas las entradas.

Cuándo usarlo: al agregar comportamiento, corregir un bug o refactorizar pero preocupado por romper cosas — siempre que tengas "entradas/salidas esperadas" que puedan escribirse como pruebas, TDD vale la pena ejecutarlo. No es solo para puristas de pruebas unitarias — se trata de estar obligado a dejar evidencia reejectable.

Qué Previene systematic-debugging

systematic-debugging previene: ver un error y cambiar cosas aleatoriamente, cambiar hasta que accidentalmente lo resuelves, o tratar los síntomas como la causa raíz. Los agentes (y los humanos) también fácilmente entran en el modo "probar esta línea, probar esa línea" — resultando en un diff gigante donde nadie puede decir qué corte realmente arregló la causa raíz.

El ritmo que empuja roughly: reproducir primero, reducir el alcance, validar la hipótesis — en lugar de refactorizar inmediatamente la arquitectura o agregar montones de código defensivo. Errores de mentalidad comunes:

"Mensaje de error largo — solo pégaselo al modelo y pídele que lo reescriba": Puede que no explote por ahora, pero la causa raíz no fue encontrada. La próxima vez que obtengas entrada diferente, explota de nuevo.
Confundir suerte con habilidad: Pasa una vez así que asumed que está bien, sin pasos de reproducción mínima, sin verificaciones de regresión.

Cuándo usarlo: pruebas que fallan, anomalías en producción, bugs no deterministas — siempre que te encuentres "probando muchas cosas pero no puedes explicar por qué ninguna de ellas funciona," cambia al track de systematic-debugging.

Qué Bloquea verification-before-completion

verification-before-completion es la puerta final: antes de afirmar "terminado," "corregido" o "pasando," primero debes tener evidencia de que realmente se ejecutó.

Las mentalidades que intenta prevenir:

"Creo que debería estar bien": El sentimiento no puede ser CI.
"Los usuarios lo probarán ellos mismos": Esa es una discusión de asignación de QA, no una definición de terminado.
Solo capturar pantalla del camino de éxito, no ejecutar el comando completo: Se vio el camino feliz; el camino de fallo y los casos extremos no tienen dueño.

Cuándo usarlo: antes de terminar cualquier subtarea, antes de hacer merge, antes de reportar a compañeros de equipo o clientes. Su espíritu es simple: no escribas "terminado" sin salida verificada. Al dar instrucciones a un agente, puedes decir explícitamente "por favor ejecuta X y pega los resultados" — esto externaliza el guardarrail.

Cómo Funcionan los Tres Juntos

Enhebrándolos a través de una línea de implementación:

TDD: Primero hacer que "correcto/incorrecto" sea algo que pueda verificarse automáticamente (luz roja → luz verde).
Si la luz permanece roja o hay un fallo en tiempo de ejecución: systematic-debugging interviene, traza hasta la causa raíz antes de cambiar cualquier cosa — evita parchar síntomas por todas partes.
Antes de decir "esta ronda está terminada": verification-before-completion te requiere a ti (y al agente) confirmar una vez más usando un comando, prueba o lista de verificación — solo entonces puedes cerrar el ticket.

No son tres elecciones mutuamente excluyentes — son diferentes puntos de verificación en la misma cadena de calidad: TDD gestiona "definición y regresión," debugging gestiona "no parchar a ciegas," verification gestiona "no firmar promesas vacías." Leídos junto con el artículo anterior sobre plan: planificar cómo hacerlo → durante la implementación, usar pruebas y debugging para proteger el comportamiento → antes de cerrar, usar verificación para proteger la honestidad.

Próximos Pasos

Para volver y completar los niveles de requisitos / diseño / plan / implementation y writing-plans: ¿Cuál Es la Diferencia Entre spec, plan e implementation? El Flujo de Trabajo Correcto para Superpowers.
Para trazar todo el camino de principio a fin: Curso para Principiantes de Superpowers.

Volver al Índice de la Serie

Este artículo cubre los roles y el momento oportuno para los tres guardarraíles de calidad. Para volver al mapa de lectura de la serie y el orden recomendado, abre el Curso para Principiantes de Superpowers.