Hay dos tipos de Spec-Driven Development y casi nadie los distingue
Todo lo que necesitas entender sobre Spec-Driven Development antes de decidir cómo y cuándo aplicarlo en tus proyectos con IA.
Hola, soy Pol Marzà. Cada semana escribo una nueva edición de Con Criterio, la newsletter sobre construir productos digitales con IA, con planificación, método y sin atajos. Si te han reenviado este email, puedes suscribirte aquí:
Esta tarde doy un webinar sobre SDD para TecnoFor. Mientras estructuraba la charla, me di cuenta de que había una distinción que nadie estaba haciendo explícita. La escribo aquí antes de que se pierda 😅
¿Qué veremos hoy?
Por qué SDD no es un concepto único, qué diferencia hay entre la versión orientada a agentes y la versión orientada al desarrollador humano, y por qué esa distinción importa antes de que nadie empiece a construir nada. Quédate hasta el final, porque al cierre comparto una skill descargable para aplicar todo esto desde hoy.
Dos lecturas del mismo término
Spec-Driven Development aparece cada vez más en conversaciones sobre desarrollo con IA. El problema es que hay dos versiones del concepto circulando a la vez, y casi nadie las distingue.
La primera es SDD orientado a agentes. Es lo que ves en OpenSpec, en Cursor Rules, en los workflows de Claude Code. Los documentos de especificación son instrucciones operativas para que múltiples agentes trabajen en paralelo sin perder contexto entre ellos. El foco es la coordinación técnica: cómo hacer que varios sistemas autónomos construyan hacia el mismo objetivo sin colisionar.
La segunda es SDD orientado al desarrollador humano. Es lo que llevo practicando desde que empecé a construir productos con IA. Los documentos de spec no son instrucciones para agentes, son artefactos de clarificación que externalizan el pensamiento antes de escribir una sola línea de código. El 80% del trabajo ocurre antes del primer prompt de ejecución. El LLM no actúa como agente autónomo, sino como colaborador informado.
Son enfoques distintos en su premisa, no versiones del mismo proceso en distinto nivel de sofisticación.
Por qué la distinción importa
El SDD agéntico asume que el desarrollador ya sabe qué construir y necesita coordinar la ejecución entre sistemas. El problema de coordinación ya está resuelto en la cabeza del humano, y los documentos de spec son el mecanismo para trasladarlo a los agentes.
Mi versión asume que la calidad del output del LLM es proporcional a la calidad del contexto que le das, y que ese contexto se construye iterativamente con el propio LLM antes de ejecutar. El problema que resuelve es anterior: no la coordinación, sino la claridad. Qué construir exactamente, por qué así, qué significa cada requisito cuando lo traduces a comportamiento real.
No son enfoques que compiten. Son prerequisito y consecuencia. Un sistema multiagente que parte de specs mal definidas produce código perfectamente coordinado hacia el objetivo equivocado.
OpenSpec no incluye una fase de clarificación porque no la necesita: asume que llegas al proceso ya sabiendo qué construir. Cubre la coordinación técnica, no el pensamiento previo.
Ese hueco es exactamente lo que he intentado sistematizar.
La skill SDD-clarifier
Hace unas semanas publiqué en concriterio.dev una skill llamada SDD-clarifier. Es un protocolo de clarificación conversacional que puedes usar con cualquier LLM antes de empezar a construir.
El proceso tiene tres fases:
Exploración (conversación para extraer todas las decisiones necesarias).
Formalización (generación de artefactos: PRD, arquitectura, diseño, modelo de datos).
Entrega (los archivos listos para que un agente de codificación los use como contexto).
Lo que la diferencia de otras herramientas del ecosistema es que no empieza por el código ni por la estructura técnica. Empieza por las preguntas que un buen product manager haría antes de que nadie escribiera nada: qué problema resuelve esto, para quién, qué significa que funcione, qué queda fuera del alcance.
La skill está disponible en concriterio.dev. Es un archivo Markdown que puedes descargar y usar directamente en Claude, en Cursor o en cualquier entorno que soporte instrucciones de sistema.
La semana que viene publicaré el post sobre orquestación humana vs. agéntica, que es el otro lado de esta misma conversación. Si entiendes cuándo tú eres el orquestador y cuándo tiene sentido delegar la coordinación a agentes automáticos, SDD como prerequisito cobra todo el sentido.
Son dos posts que se leen mejor juntos. Este explica qué construir y cómo definirlo. El siguiente explica quién lo ejecuta y bajo qué criterio.
Y recuerda, si te ha gustado este artículo, ¡no olvides compartirlo!
Hasta la semana que viene :)
— Pol