Implementa Spec-First y TDD para asegurar código con Claude Code

Spec-First + TDD: el combo que hace que Claude Code no rompa nada

Tiempo estimado de lectura: 4 min

• Spec-First transforma requisitos en contratos ejecutables que eliminan ambigüedades.
• TDD convierte esos contratos en tests que fallan primero (Red) y obligan a implementar hasta pasar (Green).
• El flujo reduce suposiciones del agente, evita happy-paths y deuda técnica silenciosa.
• Requiere versionar specs y tests junto a la implementación para trazabilidad y control.

Spec-First + TDD: el combo que hace que Claude Code no rompa nada. Díselo a cualquier equipo que delega implementaciones críticas a un agente y observarás tres problemas: suposiciones, happy-paths y deuda técnica que aparece en silencio. Este patrón invierte el orden habitual: especificación primero, tests que fallan después, implementación solo para pasar tests. Resultado: la IA implementa contra contratos ejecutables, no contra intuiciones.

Resumen rápido (lectores con prisa)

Spec-First convierte requisitos en contratos ejecutables. TDD transforma esos contratos en tests rojos que deben pasar. El agente implementa únicamente para lograr que pnpm test devuelva exit code 0. Menos ambigüedad, más trazabilidad, menos regresiones.

Spec-First + TDD: qué es y por qué lo necesitas con Claude Code

Claude Code y otros agentes son excelentes generadores de código, pero su entrenamiento los empuja a soluciones “plausibles”, no necesariamente correctas para tu dominio. La solución no es prompts más largos; es cambiar el flujo de trabajo.

Spec-First + TDD combina:

• Spec-First: transformar requisitos en un contrato preciso y ejecutable (feature-spec.md).
• TDD: traducir ese contrato a tests que inicialmente fallan (Red).
• Implementación: conceder al agente la tarea de alcanzar el verde (Green) ejecutando y corrigiendo hasta que pnpm test devuelva exit code 0.

Links útiles: Claude Code docs y Vitest para ejemplos de runners.

Flujo operativo paso a paso

1) Escribir la especificación (Spec)

La especificación no es un texto largo: es un contrato. Define funciones, inputs, outputs, errores y reglas inmutables.

Ejemplo (feature-spec.md):

Feature: applyDiscount(order, coupon)

Función: applyDiscount(order, coupon)
Inputs:
- order: { id, subtotal, userId, items[] }
- coupon: { code, type: 'percentage'|'fixed', value, minOrder, expiresAt }

Reglas:
- Si coupon.expiresAt < now -> DiscountExpiredError
- Si order.subtotal < coupon.minOrder -> OrderBelowMinimumError
- total = max(0, subtotal - discount)

Si necesitas respuesta HTTP o formatos JSON exactos, escríbelos. Nada queda implícito.

2) Generar esqueletos de tests que fallen (Red)

Pide a Claude que genere solo los tests: archivos Vitest/Jest que describan las aserciones exactas. Estos tests deben fallar inicialmente porque la implementación aún no existe.

Ejemplo breve (applyDiscount.test.ts):

import { applyDiscount } from './applyDiscount'
import { DiscountExpiredError } from './errors'

it('lanza DiscountExpiredError si el cupón expiró', () => {
  expect(() => applyDiscount(orderExpired, couponExpired)).toThrow(DiscountExpiredError)
})

Ejecuta pnpm test localmente o desde el agente. Verás rojo: eso es correcto. Tienes un contrato ejecutable.

3) Implementación: el agente repara hasta verde

Autoriza a Claude a escribir el código con una instrucción clara:

“Implementa applyDiscount() conforme a feature-spec.md. Ejecuta pnpm test y corrige hasta que todos los tests pasen. No modifiques los tests.”

El agente iterará: escribir, ejecutar, leer errores, corregir. Termina cuando el runner devuelve 0. Esa condición objetiva sustituye la “autovalidación” del modelo.

Beneficios reales y medibles

• Trazabilidad: cada cambio está ligado a un test derivado de una especificación humana.
• Determinismo: el criterio de finalización es el estado del test runner, no el juicio subjetivo del agente.
• Menos regresiones: CI bloqueará commits que rompan contratos; el agente ya trabaja para pasar esa barrera.
• Refactor seguro: optimizar sin romper es posible porque la suite revisa invariantes.

Métricas a monitorear: porcentaje de PRs que pasan en la primera ejecución de CI, número de reverts por errores de negocio, tiempo medio para retomar trabajo en sesiones de agente.

Cuándo aplicar este combo (y cuándo no)

Aplica Spec-First + TDD cuando:

• La lógica tiene invariantes críticas: facturación, pagos, permisos.
• La feature afecta múltiples consumidores del API.
• Vas a delegar implementación a sesiones autónomas del agente.

No lo uses para:

• Prototipos visuales donde la iteración UX prima.
• Scripts puntuales o migraciones one-off.
• Cambios triviales donde crear tests cuesta más que la implementación.

Buenas prácticas y guardrails

• Versiona feature-spec.md junto con la PR que implementa la feature.
• No permitas que el agente modifique tests sin revisión humana.
• Mantén artefactos pequeños: especificaciones por feature, no documentos gigantes.
• Incluye en CLAUDE.md la referencia a specs y al contrato de proyecto para que Claude cargue el contexto inicial: esto reduce fricción y errores de interpretación (ver docs).

Spec-First + TDD no es un ritual: es control. Si quieres que Claude Code deje de ser creativo y empiece a ser fiable, escribe contratos ejecutables primero, exige tests rojos y permite que la IA solo implemente para pasar tests. El resultado no es menos velocidad: es menos correcciones, menos deuda y más confianza en el código que llega a producción.

Dominicode Labs

Para equipos que automatizan con agentes y workflows, un laboratorio de pruebas y plantillas de specs acelera la adopción. Consulta Dominicode Labs como continuación lógica para crear artefactos y plantillas reutilizables.

FAQ

• ¿Qué diferencia hay entre Spec-First y documentación normal?
• ¿Por qué obligar a que los tests fallen primero?
• ¿Qué herramientas usar para ejecutar este flujo?
• ¿Cómo controlo que el agente no modifique tests?
• ¿Este enfoque añade mucha sobrecarga?
• ¿Qué métricas son más útiles para medir éxito?