Specs que la IA convierte en código sin retrabajo: guía de Spec-Driven Development
Tiempo de lectura: 8 minutos
Generar código con IA es más rápido que nunca. El problema aparece después: funciona en la demo, pero no es lo que se había pedido, asume cosas que nadie acordó y, cuando llega el segundo cambio, el equipo descubre que reescribir cuesta más que haberlo hecho bien a la primera. Ese sobrecoste tiene nombre — retrabajo — y casi siempre nace del mismo sitio: la IA recibió una instrucción ambigua y la rellenó con suposiciones.
El Spec-Driven Development (SDD) ataca el problema de raíz. En lugar de pedirle a un agente que "haga una pantalla de login", el equipo escribe una especificación ejecutable: qué hace, con qué datos, bajo qué criterios se considera correcto y qué queda explícitamente fuera. La IA genera dentro de esos límites. El resultado no es magia: es código que hace lo que se pidió, porque por fin estaba escrito lo que se pedía.
01 · ¿Por qué la IA genera rápido pero con retrabajo?
Un modelo de lenguaje no adivina tu intención: completa la más probable. Si la instrucción es vaga, el espacio de respuestas válidas es enorme y el agente elige una — coherente consigo misma, pero no necesariamente la tuya. Cuando tres personas piden a sus agentes "lo mismo" con palabras distintas, obtienes tres diseños distintos que ni siquiera encajan entre sí.
Esto es justo lo que distingue al vibe coding del trabajo estructurado. Lo desarrollamos en detalle en Vibe coding vs Spec-Driven Development: por qué las specs ganan al escalar, pero la idea corta es esta: cuando el código cuesta casi nada de generar, el cuello de botella se mueve a la decisión y la definición. Lo contamos también en Generar código con IA es fácil; crear impacto, no tanto.
02 · ¿Qué es Spec-Driven Development?
SDD invierte el orden habitual. Primero se escribe la especificación — un artefacto explícito, versionado y compartido — y solo después se genera el código. La spec deja de vivir en la cabeza del equipo y en conversaciones del sprint, y pasa a ser algo que tanto las personas como los agentes pueden leer y respetar.
El flujo, en su forma más simple, es este:
Lo importante del diagrama es la flecha roja: cuando algo sale mal, se corrige la especificación, no el código generado. Si parcheas solo el código, la próxima generación volverá a equivocarse igual. La spec es la fuente de la verdad.
03 · ¿Cuáles son las cinco secciones de una spec ejecutable?
Una buena spec no es un documento de 40 páginas. Son cinco bloques que cualquiera del equipo puede leer en cinco minutos y que un agente puede convertir en código sin rellenar huecos por su cuenta.
| Sección | Qué responde | Por qué evita retrabajo |
|---|---|---|
| Contexto y objetivo | ¿Por qué construimos esto y para quién? | La IA prioriza bien cuando conoce la intención |
| Requisitos funcionales | ¿Qué debe hacer, paso a paso? | Elimina funcionalidades inventadas o ausentes |
| Criterios de aceptación | ¿Cuándo está "bien"? (Given/When/Then, EARS) | Hace la corrección verificable, no opinable |
| Wireframes / interfaz | ¿Qué ve y toca el usuario? | Evita que el agente improvise la navegación |
| Fuera de alcance | ¿Qué NO hacemos ahora? | Frena el scope creep del modelo |
La sección que más retrabajo ahorra es la tercera. Un criterio escrito como "el login debe ser seguro" no es verificable; uno escrito como "Dado un usuario con 5 intentos fallidos, cuando introduce una contraseña incorrecta, entonces la cuenta se bloquea 15 minutos" sí lo es. Cómo escribir criterios que tanto humanos como agentes entienden igual lo vemos en Given/When/Then y EARS: el idioma común de humanos y agentes de IA.
Una especificación no ralentiza al equipo. Sustituye tres rondas de retrabajo por treinta minutos de claridad.
04 · La spec no sustituye al criterio: lo concentra
Un miedo habitual: "si todo está especificado, ¿no estamos volviendo a waterfall?". No. La diferencia es que la spec en SDD es viva y barata de cambiar — es un artefacto de trabajo, no un contrato de 200 páginas que se firma una vez. Se itera cada sprint, igual que el código.
Lo que cambia es dónde invierte su criterio el equipo. En lugar de gastarlo tecleando, lo gasta decidiendo: qué construir, con qué prioridad y bajo qué reglas. Es el mismo desplazamiento que comentamos en Generar código con IA es fácil; crear impacto, no tanto: la IA mueve el cuello de botella del delivery a la decisión.
05 · El pipeline: de la spec al código revisado
SDD brilla cuando se conecta a un pipeline donde la propia IA revisa el código contra la spec antes de que lo haga una persona. La spec aporta los criterios; la IA comprueba mecánicamente que se cumplen; el humano decide sobre lo que de verdad requiere criterio. Ese montaje — y cómo evitar que se convierta en un cuello de botella — lo detallamos en Code review con IA: un pipeline que revisa specs y código sin frenar la entrega.
06 · ¿Cuándo merece la pena el Spec-Driven Development (y cuándo no)?
SDD no es gratis: escribir specs cuesta. Merece la pena cuando:
- Construyes algo nuevo y la arquitectura aún está tomando forma.
- Varias personas (o agentes) tocan el mismo sistema y la coherencia importa.
- El coste de equivocarse es alto: datos sensibles, pagos, normativa.
Es excesivo para un script de un solo uso o un prototipo desechable, donde el vibe coding es perfectamente razonable. La clave es elegir conscientemente, no por inercia. Esa decisión — estructurar o no — es la misma que abordamos en Vibe coding vs Spec-Driven Development.
Por dónde empezar
Si quieres probarlo esta semana, coge una historia pequeña y escribe sus cinco secciones antes de tocar el agente. Para no partir de cero, hemos publicado una plantilla de spec, un glosario y checklists que puedes usar tal cual: están en los recursos de Spec-Driven Development.
Si quieres aprenderlo a fondo —con un caso real de principio a fin, wireframes, criterios y el pipeline de revisión con IA— ese es exactamente el contenido del curso Specification-Driven Development. Y si tu siguiente paso es entender los agentes que ejecutan esas specs, empieza por Introducción a los agentes de IA.
Cada semana compartimos casos prácticos como este sobre cómo entregar antes, mejor y con IA en la newsletter de ITNOVE: puedes suscribirte gratis en itnove.com/newsletter.
La IA escribe el código. Tu trabajo —y tu ventaja— es escribir lo que el código tiene que hacer.