Abre un pull request de un equipo que trabaja con "desarrollo totalmente impulsado por IA". No de un equipo que usa la IA con disciplina. De un equipo que cedió el volante al modelo y esperó a que llegara el código.
Reconoces el código al instante. Una función que llama a un endpoint que no existe. Un campo llamado user_id en un fichero y userId en el siguiente. Un flujo de autenticación que contradice al que se escribió dos ficheros antes, porque el modelo olvidó lo que decidió en un contexto anterior. Compila. La CI pasa. Nadie lo posee.
El problema no es el modelo. El modelo está haciendo exactamente lo que le pediste. El problema es que nunca le diste un arnés.
Andrej Karpathy acuñó el término vibe coding para este modo: describes una sensación y aceptas lo que vuelve. Válido para una demo de fin de semana. Peligroso para software que corre en producción y despierta a alguien a las 3 de la madrugada.
Qué intenta resolver el SDD
El historial del chat no es una spec. Los prompts no son requisitos. Los agentes se desvían cuando la intención solo vive en la cabeza de alguien.
En el AI Engineer World's Fair, Sean Grove de OpenAI lo formuló con precisión: la nueva habilidad escasa en el desarrollo aumentado por IA no es la programación — es escribir especificaciones que capturen completamente tu intención y tus valores. El modelo puede generar código a una velocidad extraordinaria. Lo que no puede hacer es inventar tus restricciones, tus invariantes o tus criterios de aceptación.
Thoughtworks señaló el spec-driven development como una de las prácticas de ingeniería definitorias de 2025. El motivo es estructural: los pipelines multiagente, los agentes de codificación autónoma y las tareas largas de IA comparten el mismo modo de fallo. Optimizan el objetivo declarado y se alejan de todo lo no declarado. Sin un documento que el agente pueda leer — y releer — cada nueva ventana de contexto empieza desde cero.
Qué es realmente el SDD en la era de la IA
La definición práctica es más sencilla que el acrónimo. Una spec, en el sentido aumentado por IA, es un documento markdown vivo que recoge objetivos, restricciones, ejemplos y criterios de aceptación — escrito para que tanto humanos como agentes puedan leerlo, usarlo y actualizarlo.
No es un documento de requisitos de 200 páginas congelado en el kickoff. No es una página de Confluence que nadie actualiza. Es un fichero que vive junto al código, versionado en git, modificado mediante pull request y tratado como un artefacto de primera clase.
Existe una variante industrial más pesada: Kiro, spec-kit y Tessl — plataformas que formalizan el SDD con sus propios sistemas de registro, tooling y capas de proceso. El artículo de Martin Fowler merece la pena. Para una organización de ingeniería grande con presupuesto dedicado a herramientas, estas plataformas son interesantes. Para un equipo de tres a diez ingenieros, son una exageración.
La crítica honesta — por qué los escépticos no se equivocan
Los argumentos más sólidos contra el SDD merecen una respuesta directa, no una dismissión.
"Esto es solo waterfall." La reacción de HN al SDD fue rápida y reconocible: Spec-Driven Development: The Waterfall Strikes Back. La preocupación es real. Las specs congeladas reproducen los fallos de las specs congeladas: el mundo cambia, la spec no, y construyes lo incorrecto con gran precisión. Marc Brooker, Senior Principal Engineer en AWS, lo abordó directamente en su post Spec Driven Development isn't Waterfall: la diferencia está en si la spec se trata como un artefacto vivo revisado continuamente o como un contrato firmado una vez y archivado. El problema no son las specs. Son las specs congeladas.
La deriva de la spec es trabajo invisible. Drew Breunig lo expresó bien en su artículo sobre el triángulo del spec-driven development: mantener la spec, el código y el comportamiento del agente sincronizados es trabajo que pierde cada reunión de planificación frente a features e incidencias. La deriva no es un riesgo teórico. Es el resultado por defecto.
Las ventanas de contexto más grandes no lo resuelven. El blog de ingeniería de Augment Code expone el caso contra el SDD naíf con claridad: incluso un modelo que puede leer cien mil tokens no sintetiza automáticamente la intención a partir de un documento largo. Recuperar no es comprender.
Las specs ejecutables están sobrevaloradas. El artículo Emperor's New Code de Robert Encarnacao da el golpe más duro: los vendors que venden plataformas spec-driven suelen prometer que la spec es el software. Eso es marketing. Las specs guían el software. No sustituyen el juicio necesario para construirlo.
La posición honesta: el SDD no es waterfall si la spec es un documento vivo y el equipo es lo suficientemente pequeño para mantenerlo honesto.
OpenSpec — el arnés ligero para equipos pequeños
OpenSpec, mantenido por Fission-AI, adopta un enfoque deliberadamente mínimo: propuestas, registros de cambios y deltas de spec — todo en markdown, todo en git, todo revisado mediante pull request.
Sin nuevo sistema de registro. Sin licencia de plataforma. Sin ceremonia de onboarding. La introducción del GitHub Blog al spec-driven development con IA explica bien el toolkit: agentes y humanos leen los mismos ficheros, el diff es la traza de auditoría, y la spec evoluciona al ritmo del código porque vive en él.
"El punto medio es una spec lo suficientemente ligera como para que un desarrollador la actualice y lo suficientemente precisa como para que un agente la use."
Para un equipo de tres a diez personas, eso es aproximadamente donde vive openspec.dev. Kiro y spec-kit asumen una organización más grande con presupuesto de herramientas dedicado e ingenieros de plataforma para mantener el andamiaje. OpenSpec asume un equipo con un repositorio git y la disciplina de escribir una página antes de empezar.
El manual IBERANT — cinco reglas que funcionan
Estas son las prácticas que hemos encontrado que vale la pena mantener.
Empieza cada feature no trivial con una spec de una página, no con un prompt. Objetivos, restricciones, criterios de aceptación. Una página. Si no puedes escribirla en una página, la feature no está suficientemente entendida para construirla.
Guarda las specs en /specs junto al código. Versionadas. Revisadas en PRs. Una spec que vive en Confluence es una spec que nadie lee.
Escribe los criterios de aceptación como bullets comprobables. Sirven de doble guardarraíl para el agente durante el desarrollo y como plan de tests en la revisión. Si no puedes escribir un test para ello, no puedes verificarlo.
Trata las specs obsoletas como bugs. Si una spec diverge del código, corrige una de las dos en el siguiente PR. No dejes que la brecha se amplíe. La deriva se acumula.
No hagas spec de lo trivial. Un endpoint CRUD no necesita un documento de cuatro páginas. Un flujo de pagos, sí. Un job en segundo plano que toca datos de clientes, también. Un correo de "contraseña olvidada", no.
El arnés es la cuestión
El SDD no es magia y no es waterfall. Es el arnés que te permite apuntar la IA a trabajo no trivial sin producir slop.
El modo de fallo del vibe coding no es que el modelo sea malo. El modo de fallo es que el modelo es bueno generando código que suena convincente para el problema que entendió, que nunca es exactamente el problema que tenías. La spec es la capa de traducción. Es como se transfiere la intención de una cabeza humana a una forma con la que un agente puede actuar sin alucinar el resto.
El punto medio para la mayoría de equipos pequeños está en algún lugar entre los requisitos congelados de 200 páginas y las vibes en una ventana de chat. Para la mayoría de nosotros, ese punto está aproximadamente donde vive OpenSpec: lo suficientemente ligero para mantener, lo suficientemente preciso para ser útil, y lo suficientemente aburrido como para que realmente se haga.
Si quieres construir software que se envía con disciplina y velocidad, hablemos.