Cuando la IA escribe el código, los tests dejan de ser una red de seguridad y se convierten en la especificación. El problema con AI-TDA no es que el código sea lento: es que es rápido, plausible y difícil de detectar cuando está mal. Sin tests previos, el Delivery Master revisa código generado sin un criterio objetivo de corrección.
TDD adaptado a construcción dirigida por IA
El Delivery Master escribe los tests antes de abrir Claude Code o Cursor. Esos tests son el contrato: describen qué debe hacer el feature, qué inputs acepta, qué outputs produce y qué condiciones de error maneja. El modelo recibe esa especificación ejecutable y su tarea es hacer que los tests pasen. Este cambio obliga a que el PO y el DM estén de acuerdo en los criterios antes de generar una sola línea de código.
Por qué los tests son más importantes con IA, no menos
Los modelos producen código que luce correcto, compila limpiamente y sigue los patrones del codebase — y que puede tener un bug de lógica de negocio que solo emerge en producción. La diferencia entre un bug humano y uno generado por IA es que el generado es más difícil de atribuir y más fácil de pasar por alto en review porque el código parece coherente.
«El test es la memoria del equipo. Cuando la IA olvida una restricción de negocio, el test la recuerda.» — QA Lead, SFD
El rol del QA en el modelo FAST Delivery
En SFD, el QA no es una fase al final del sprint: colabora desde que la feature entra al backlog. Junto con el PO, define los escenarios de prueba antes de que el DM empiece la sesión de construcción. Durante la construcción, revisa los tests unitarios generados para verificar que realmente prueben lo que dicen — porque los modelos a veces generan tests que pasan siempre, independientemente del comportamiento de la función. La velocidad real en agentic development se mide en features funcionando en producción sin deuda técnica acumulada.
La IA no construye software: construye lo que le dices que construya. Esa diferencia —entre un equipo que delega con intención y uno que simplemente empieza a promptear— es lo que separa un feature entregado el viernes de un Slack lleno de actualizaciones sin nada en producción.
Qué es el Delivery Master y por qué importa
En SFD, el Delivery Master es un senior engineer cuya función no es escribir código: es dirigir la construcción. Piensa en él como el director de fotografía en una película. No mueve la cámara en cada toma, pero decide el encuadre, la luz y el ritmo. El DM establece la arquitectura, define los límites del contexto y revisa cada bloque de código generado con criterio real, no solo comprobando que compile.
Cómo luce una sesión real del Delivery Master
Una sesión DM con Claude Code empieza antes de abrir el editor: contexto estructurado con el dominio del feature, restricciones de arquitectura, contratos de API y criterios de aceptación. Un prompt de DM no dice «construye el módulo de pagos». Dice: «Dado el contrato OpenAPI adjunto, implementa el servicio de checkout usando el patrón Repository en /src/domain, sin modificar la capa de autenticación. Los tests de integración deben pasar antes de continuar.»
«La IA amplifica la dirección que le das. Si la dirección es vaga, el resultado es ruido rápido. Si es precisa, el resultado es velocidad real.» — Equipo SFD
Las decisiones que el DM nunca delega al modelo
Tres categorías son intocables: la arquitectura de datos (el DM evalúa impacto en migraciones futuras), las integraciones con sistemas externos (cada API de tercero tiene consecuencias de seguridad y costo) y los trade-offs de deuda técnica (cuando el modelo propone un atajo, el DM decide si tiene precio aceptable).
Construcción dirigida vs. todos prompting independientemente
El DM centraliza las decisiones de contexto sin convertirse en cuello de botella: define los guardarraíles, habilita la autonomía dentro de ellos y revisa el output con criterios compartidos. Un equipo con Delivery Master no entrega más features porque tiene mejores herramientas. Las entrega porque alguien sabe exactamente hacia dónde apuntar cada una.
Elegir la herramienta equivocada no te hace más lento: te hace más lento con más confianza. El ecosistema de AI IDEs creció tan rápido que muchos equipos terminaron usando Cursor para todo. En SFD tomamos decisiones explícitas sobre qué herramienta usar por tipo de tarea, y la diferencia en velocidad de entrega es notable.
Cursor: para refactors y navegación de codebase
Cursor brilla cuando el trabajo requiere entender y transformar código que ya existe. Su integración con el índice del repositorio permite hacer preguntas del tipo «¿dónde se maneja el error de autenticación en toda la app?» con contexto real de tu código. Para refactors que tocan múltiples archivos —renombrar un contrato, migrar una abstracción, actualizar un patrón en 30 módulos— Cursor reduce el tiempo de exploración dramáticamente.
Claude Code: para tareas agénticas y trabajo en terminal
Claude Code es la opción cuando el task no cabe en un archivo ni en un prompt de una línea. Su fortaleza es la orquestación: puede leer el codebase, ejecutar tests, revisar logs del error, proponer un fix, aplicarlo y correr los tests de nuevo — todo en un solo flujo. También es ideal para infraestructura ligera: scripts de migración, pipelines de CI, actualización de dependencias con validación automática.
«No buscamos la herramienta más poderosa. Buscamos la herramienta correcta para el paso correcto del feature.» — Delivery Master, SFD
Windsurf: para coding en estado de flujo
Windsurf apuesta por no interrumpir el pensamiento del developer. Su modelo de sugerencias es más predictivo: no pregunta qué quieres hacer, infiere el siguiente paso. Para developers con mucha experiencia en un dominio estable, Windsurf es difícil de superar en confort de escritura. Su punto débil: si tus decisiones son incorrectas, también te hace muy rápido en la dirección equivocada.
Cómo SFD decide qué herramienta usar
La heurística: ¿el task requiere explorar código existente en múltiples archivos? Cursor. ¿Requiere ejecutar, verificar e iterar en varios pasos? Claude Code. ¿Es implementación directa dentro de un diseño ya definido? Windsurf. La disciplina en la elección de herramientas es la diferencia entre velocidad real y la ilusión de velocidad.
