Hace unos meses, el Spec-Driven Development (SDD) parecía la respuesta definitiva al «vibe coding». Hoy, cada vez más desarrolladores que lo probaron en proyectos reales lo cuestionan. Este artículo resume qué es, dónde falla según quienes lo usaron y qué alternativa están adoptando: el pair programming con IA.
Si querés conocer el enfoque completo del SDD, tenemos una guía sobre Spec-Driven Development. Acá miramos el otro lado: qué pasa cuando se lo lleva a la práctica.
Qué es el Spec-Driven Development
El SDD propone pensar todo antes de escribir una línea de código. Se redacta una especificación muy detallada con requerimientos, diseño técnico y una lista de tareas, y recién entonces se le entrega todo a un agente de IA para que lo implemente. Herramientas como SpecKit, Kiro, BMAD y OpenSpec siguen ese recorrido: propuesta, especificación, diseño, tareas y código.
La lógica es razonable: si la IA tiene todo el contexto, debería poder construirlo. En la práctica, muchos desarrolladores cuentan una experiencia distinta.
Dónde falla, según quienes lo usaron
Los problemas que más se repiten funcionan como una cadena, donde cada uno lleva al siguiente.
- Todo se planifica por adelantado. Es, en esencia, la metodología en cascada: definir arquitectura, datos y diseño cuando menos se entiende el problema. Y como nadie le pide a la IA que sea simple, completa los huecos con sobreingeniería: capas de abstracción, interfaces y campos de base de datos que nadie necesita.
- El trabajo sale por capas. Primero la base de datos, después la API, después el front. Esto se debe más a cómo se entrenaron los modelos que al método en sí.
- Nada funciona hasta el final. Una base sin API no se puede probar, y una API sin interfaz no se puede usar. Incluso con tests, siempre queda una verificación manual pendiente.
- Solo queda revisar leyendo. Un cambio de 3.000 líneas es difícil de revisar a conciencia, y la tentación de aceptarlo sin mirar es enorme. Pero código que no se revisa deja de ser tuyo.
- El software evoluciona. Lo que parecía necesario en el paso uno puede no serlo en el paso cinco.
También aparece un argumento histórico: este tipo de planificación habría surgido cuando los modelos eran menos capaces, y hoy tiene menos sentido. Y una crítica de proporción: para una funcionalidad chica, armar todo ese proceso es demasiado.
Conviene aclarar que casi nadie dice que planificar sea malo. El cuestionamiento es a planificarlo todo de una vez y a delegarle todo a la IA.
La alternativa: pasos chicos y el humano al volante
La propuesta que reúne más consenso se apoya en prácticas conocidas de las metodologías ágiles y de Extreme Programming, y se sostiene en tres ideas.
1. Vertical slices en lugar de capas
Cada vertical slice es una funcionalidad pequeña y completa que atraviesa base de datos, backend y frontend, y que ya se puede usar. Las ventajas:
- Al terminar un slice, tenés algo que funciona y lo verificás usándolo, no leyéndolo.
- Cada uno es lo bastante chico para revisarlo bien.
- La arquitectura emerge: se agregan abstracciones solo cuando hacen falta.
- Si algo sale mal, te enterás a los pocos minutos, no días después.
2. Un backlog de historias de usuario
Cada slice se describe en una línea: «como [usuario], quiero [acción] para [beneficio]». Escribirlo o descartarlo no cuesta nada, y por eso esto no es cascada. El detalle técnico se posterga hasta el momento de tomar la historia.
3. Pair programming con la IA
La IA es quien escribe (driver) y el desarrollador es quien dirige (navigator). Se trabaja en ciclos cortos guiados por tests: un test que falla, el mínimo código para pasarlo, una revisión y recién entonces el siguiente paso. Algunos referentes de la programación extrema llaman a esto augmented coding: la IA ahorra escribir, pero no pensar.
Cómo se ve en la práctica
El flujo típico se parece a esto:
- Se arma un backlog corto, con historias de una línea y revisando que ninguna haga más de una cosa.
- Se toma una historia y se le agregan unos pocos criterios de aceptación y un «fuera de alcance».
- La IA trabaja de a un test por vez. Cada paso tarda segundos, se revisa y se hace commit.
- Los refactors los decide el humano y se hacen cuando hacen falta, no «por si acaso».
El commit frecuente tiene un motivo concreto: los agentes a veces modifican o eliminan tests para que el código pase. Con commits chicos, ese cambio se ve de inmediato.
También se observa algo interesante: a medida que el proyecto define su estructura, el agente se vuelve más predecible y avanza más rápido. La inversión de tiempo está al comienzo.
Tres alarmas para vigilar
Quien trabaja así suele estar atento a que la IA:
- no entre en loops,
- no agregue cosas que no se pidieron,
- no toque los tests para que pasen.
Explorar antes de implementar
Otra práctica que gana terreno es separar las etapas del agente: primero explorar el proyecto (leer, buscar, entender) y recién después implementar. Delegar esa exploración en un subagente evita llenar el contexto principal, y hay quienes aseguran que reduce el consumo de tokens. Es una idea con sentido, aunque las cifras que circulan, como «hasta tres veces menos», son impresiones personales y no mediciones verificadas. Lo mejor es probarlo en tu propio proyecto.
Entonces, ¿cuál conviene?
| Spec-Driven Development | Pair programming con IA | |
|---|---|---|
| Unidad de trabajo | Especificación completa | Un test, un paso |
| Momento de revisión | Al final, sobre mucho código | En cada paso |
| Control del desarrollador | Al inicio (spec) y al cierre | Permanente |
| Riesgo principal | Exceso de documentación y revisión masiva | Ritmo más lento por paso |
| Detecta errores | Tarde | Enseguida |
Nuestra lectura es que el SDD no está «muerto», pero conviene usarlo con criterio. Una spec breve para una funcionalidad concreta puede ser útil. Lo que genera problemas es el proceso pesado, de arriba abajo, para cualquier tarea. Para programar en serio, el patrón se repite: pasos cortos, feedback rápido y una persona decidiendo en cada etapa.
Estas herramientas están pensadas para desarrolladores, no para quienes buscan que la IA haga todo sola. La IA puede escribir mucho código muy rápido, pero la responsabilidad de entenderlo sigue siendo de quien lo firma.
Preguntas frecuentes
¿Qué es el Spec-Driven Development?
Es una forma de trabajar con IA en la que primero se escribe una especificación detallada (requerimientos, diseño y tareas) y después se le pide a un agente que la implemente.
¿Qué es el pair programming con IA?
Es programar en pareja con un agente de IA: la IA escribe el código en pasos cortos y la persona dirige, revisa y decide en cada paso, normalmente guiada por tests.
¿Cuál conviene para un proyecto real?
Depende del tamaño de la tarea. Para funcionalidades acotadas, los pasos chicos con revisión constante suelen dar más control. Una especificación breve puede servir como punto de partida, siempre que no se convierta en un proceso pesado.
