SDD: Implicaciones Estratégicas y Evolución del Rol del Desarrollador

Lectura fundacional: Desarrollo Impulsado por Especificaciones con IA Agéntica · Serie Socratic Agent (Parte 2): SDD y Sycophancy · Análisis Profundo de Frameworks SDD · “Grill Me” vs Método Socrático vs Spec-Driven Dev

Artículo hermano (EN): Spec-Driven Development: The Developer Role Redefined

El blog ya tiene cobertura profunda de qué es el Spec-Driven Development y qué frameworks lo implementan — Spec Kit, OpenSpec, BMAD, Kiro, Superpowers, todos ellos. Las dos partes de Socratic-Agent diseccionan cómo SDD lucha contra la sycophancy de la IA, y la comparativa Grill-Me enfrenta SDD contra el prompting adversarial. Lo que este post cubre en cambio es el tercer eje: qué te pasa a ti — al humano frente al teclado — una vez que SDD deja de ser una metodología que evalúas y se convierte en el modelo operativo en el que vives. El ángulo que falta conspicuamente en los posts existentes: cómo cambia tu rol, dónde se esconde el 40–60% del desperdicio técnico, y qué exige “Spec-as-Source” del indie dev que no tiene a nadie a quien delegar.

La resaca que nadie admite

Vuelvo una y otra vez a un pasaje que William Collins publicó en marzo de 2026, porque captura el momento que atraviesa la industria con honestidad quirúrgica:

“Avancemos unos meses. Intentas añadir una funcionalidad a lo que construiste. O un compañero te pide que se la expliques. O, peor aún, algo se rompe en producción a las 2AM y te encuentras mirando 3.000 líneas de código generado por IA que nunca has leído — esa es la resaca.”

— William Collins, Vibe Coding Got Us Here. Can Spec-Driven Development Save Us? (wcollins.io, marzo 2026)

Andrej Karpathy acuñó “vibe coding” en febrero de 2025. Cuatro millones y medio de visitas. Dieciocho meses después, la resaca es real. Los números no son amables:

Qué medimos	Qué encontramos	Quién lo midió
Código IA con vulnerabilidades de seguridad	45%	Veracode 2025
Tasa de fallo de código IA en Java	+70%	Veracode 2025
Tasa de XSS vs. código escrito por humanos	2,74× mayor	CodeRabbit Dic 2025
Fallos en protección XSS en código IA	86%	Veracode 2025
Devs experimentados más lentos con IA	19% más lentos	METR RCT Jul 2025
Lo más rápidos que creían ser	24% más rápidos	METR RCT Jul 2025
Aumento de duplicación de código (2020-2024)	~4×	GitClear
Deuda técnica pendiente (estimaciones)	1,5 billones USD	Analyst estimates

La línea de METR merece una segunda lectura. Un ensayo controlado aleatorizado — no una encuesta, no vibes, un RCT real con desarrolladores experimentados de open source — encontró que esos desarrolladores eran un 19% más lentos con herramientas de IA mientras simultáneamente creían ser un 24% más rápidos. Eso es una brecha de 43 puntos entre percepción y realidad. No estamos solo escribiendo más código; estamos escribiendo más código que pensamos que es bueno pero que, empíricamente, no lo es.

Spec-Driven Development no es la única respuesta a esta brecha. Pero es la que ataca la causa raíz: la ausencia de una fuente de verdad persistente y legible por máquina que sobreviva entre sesiones, entre herramientas, entre las decenas de pequeñas iteraciones que componen una funcionalidad asistida por IA.

Qué significa realmente “el rol del desarrollador cambió”

Liu Shangqi, Technology Director APAC en Thoughtworks, condensó el cambio en una frase en diciembre de 2025:

“La postura Spec-as-Source requiere una redefinición fundamental del rol, no un cambio de herramientas.”

— Liu Shangqi (Thoughtworks), citado vía Augment Code, “8 Best AI Tools for Spec-Driven Development”

Esa frase carga con peso estructural. Cambio de herramientas es lo que cubren la mayoría de artículos sobre SDD: instala Spec Kit, ejecuta specify init, deja que el agente scaffoldee un archivo de constitución. Redefinición de rol es de lo que trata este artículo, porque las herramientas sin cambio de rol producen la brecha de 43 puntos de METR enfundada en una chaqueta ligeramente más estructurada.

En concreto, el rol se desplaza en cuatro ejes. No son pasos secuenciales; son dimensiones que se mueven en paralelo:

Los cuatro roles del desarrollador Spec-Driven: Arquitecto, Validador, Orquestador y Curador, orbitando alrededor de la spec como única fuente de verdad.

1. De mecanógrafo a arquitecto de la intención

Dejas de escribir funciones y empiezas a escribir contratos. El artefacto que importa ya no es la class ni el use case — es el documento OpenAPI, el JSON Schema, el AsyncAPI, el IDL de Protobuf. Sea cual sea el formalismo, la spec captura: entradas, salidas, invariantes, casos límite, restricciones no funcionales y criterios de aceptación. Escribes esto antes de que exista la implementación. La implementación es lo que se genera.

Esto no es nuevo. Los ingenieros de redes llevan cuarenta años escribiendo RFCs antes de que ningún paquete atraviese el cable. Los modelos YANG definen configuraciones de dispositivos antes de que se ejecute un solo comando CLI. Los equipos de gRPC entregan archivos .proto antes de que se implemente cualquier servicio. La infraestructura siempre ha sido spec-first. Lo que cambia con SDD es que el consumidor de la spec ya no es un humano con un backlog — es un agente de IA sin memoria persistente entre sesiones. Eso hace que la precisión de la spec sea estructuralmente crítica de un modo que nunca fue cuando los humanos eran los únicos lectores.

2. De autor a validador del código generado

En el mundo del Vibe Coding lees diffs. En SDD lees informes de cumplimiento. La pregunta no es “¿este código me parece bien?” sino “¿este código generado satisface las restricciones que mi spec definió?”. Es una tarea cognitiva distinta: pattern-matching contra un contrato en lugar de contra un instinto. También es por eso que el rol no es “revisor” — no estás aprobando el PR de otro, estás verificando que un proceso determinista produjo una salida determinista. Veracode reporta que el 86% del código IA falla en protección XSS. El motivo no es que la IA sea tonta — es que el prompt no llevaba la restricción. SDD mueve la restricción del prompt a la spec, donde no puede olvidarse.

3. De colaborador en solitario a orquestador de flujos agénticos

Una sola sesión de chat con un modelo de IA ya no es la unidad de trabajo. Los proyectos anclados en SDD típicamente componen:

Un modelo de planificación que interpreta la spec y la divide en tareas.
Un modelo de implementación que escribe código contra una sola tarea.
Un modelo de verificación que ejecuta tests, linters y contract checks.
Un modelo de revisión (a menudo adversarial — ver la serie Socratic Agent) que desafía el diseño.
Un modelo de documentación que mantiene la spec y la wiki sincronizadas.

Dejas de ser el cuello de botella que teclea el código y te conviertes en el integrador que decide qué modelo recibe qué trabajo. El resultado del 19%-más-lento de METR desaparece en esta composición, porque cada agente opera sobre una tarea de alcance cerrado en lugar de un prompt ilimitado tipo “construye una app”.

4. De propietario a curador de la deriva de la spec

Este es el rol del que nadie habla, y es el que determina si SDD sobrevive más allá de la tercera semana. Una spec que no se actualiza se convierte en mentira. Una mentira que el agente lee con confianza produce código confiadamente incorrecto. Así que el desarrollador en un modelo operativo SDD dedica una fracción no trivial de su tiempo a mantenimiento de la spec: cuando la implementación revela un caso límite que la spec no anticipó, la spec se actualiza primero, y luego el código se regenera. Este es el inverso del flujo tradicional, y es la fuente de la queja más común sobre SDD en la práctica.

Un desarrollador senior de Java con cinco años de experiencia, publicando en r/ExperiencedDevs en febrero de 2026, resumió el anti-patrón que ocurre cuando se salta este rol:

“Al principio parecía genial (lo hice por pasos), pero rápidamente se torció. Al final tenía un montón de código, y cuando aparecían errores, después de indicar cómo arreglarlos, seguía fallando y fallando mientras destruía otras funcionalidades… Por la monstruosidad de código que generó para una funcionalidad no tan grande, decidí escribirla a mano y básicamente usar IA para tareas muy pequeñas.”

— FooBarBuzzBoom, r/ExperiencedDevs, “Spec Driven Development and other shitty stuff” (febrero 2026)

Ese es el anti-patrón. El arreglo no es “usa un modelo mejor” — es actualizar la spec primero y regenerar, en lugar de parchear el código generado a mano. Una vez que empiezas a parchear la salida, estás en modo Spec-first como mucho; no puedes estar en Spec-as-Source. El rol de curador es lo que marca la diferencia.

Los tres niveles de madurez (framework de Böckeler)

Birgitta Böckeler, Distinguished Engineer en Thoughtworks, definió los niveles de madurez que se han convertido en el vocabulario de facto para hablar de adopción de SDD. Los reproduzco aquí porque cualquier otro framework que he visto o bien se reduce a ellos o bien los refina:

Tres niveles de madurez: Spec-first (bajo compromiso), Spec-anchored (documento vivo), Spec-as-Source (redefinición total del rol).

Nivel 1 — Spec-first

Escribes la spec, luego implementas a partir de ella. La spec es una referencia. Tanto la spec como el código pueden cambiar de forma independiente; actualizas lo que sea más rápido o claro. La mayoría de historias de “probé SDD y no funcionó” terminan aquí. Funciona, pero ofrece el menor apalancamiento porque el coste de mantener la spec y el código alineados recae enteramente sobre ti. Si solo haces este nivel, no has cambiado tu rol mucho — sigues siendo un mecanógrafo que casualmente escribe un documento primero.

Nivel 2 — Spec-anchored

Tratas la spec como un documento vivo. Cuando cambian los requisitos, actualizas la spec y luego regeneras o refactorizas el código. La spec se convierte en la fuente de verdad para la intención, mientras el código permanece como la fuente de verdad para lo que el sistema hace actualmente. Aquí es donde deberían aterrizar la mayoría de equipos en producción. Acepta una pequeña cantidad de mantenimiento dual a cambio de mantenerse cerca de la realidad brownfield — no tienes que hacer que cada campo de la spec sea ejecutable por máquina; solo tienes que hacer que sea lo bastante preciso para dirigir la regeneración.

OpenSpec está explícitamente diseñado para este nivel. Thoughtworks añadió OpenSpec a su Technology Radar en abril de 2026 precisamente porque se enfoca en deltas de spec en lugar de especificaciones upfront completas, lo cual se adapta a codebases brownfield donde una spec completa es poco práctica.

Nivel 3 — Spec-as-Source

La spec es el único artefacto que un humano edita. El código se genera a partir de ella, siempre. No existe el concepto de “parchear la salida generada” — si el código está mal, la spec está mal. Este es el nivel que entrega la reducción de desperdicio del 40-60% y que demanda la redefinición completa del rol. También es el nivel que rompe a la mayoría de equipos, porque la spec debe ser 100% ejecutable — sin escapes, sin líneas tipo “TODO: el agente rellena esto después”.

Puedes ver el gradiente de madurez como una medida de distancia humana al código:

Spec-first: humanos editan spec + código de forma intercambiable. Bajo compromiso formal.
Spec-anchored: humanos editan la spec libremente; los agentes regeneran código a partir de ella. Documento vivo.
Spec-as-Source: humanos editan solo la spec; los agentes lo regeneran todo. Redefinición total del rol.

El nivel de madurez que puedes sostener en la práctica depende menos de las herramientas y más de la disciplina del rol de curador. La mayoría de proyectos que veo colapsan de vuelta al Nivel 1 en un trimestre porque nadie mantiene la spec una vez que la implementación “funciona”.

El mapa del 40-60% de desperdicio técnico

¿Dónde, exactamente, se va el 40-60% de desperdicio? El título del post prometía un número y el cuerpo tiene que entregarlo. Tras cruzar los reportes de seguridad 2025 de Veracode, el RCT de METR, el seguimiento de duplicación de código de GitClear y las quejas operativas que afloran en r/AI_Agents y r/ExperiencedDevs, cuatro cubos cubren casi todo el desperdicio:

Mapa de desperdicio: cuatro categorías donde ocurre la reducción del 40-60% — re-derivación, deriva, retrabajo, impuesto de revisión.

Cubo 1 — Coste de re-derivación

Cada sesión nueva del agente empieza desde cero. Si tu intención vive en el historial del chat, muere con la sesión. El coste de re-explicar la arquitectura, las restricciones, las convenciones de naming, la estrategia de testing y los casos límite a cada nueva sesión es enorme e invisible. Los equipos que adoptan SDD típicamente eliminan el 40-60% de este coste de re-derivación porque la spec lleva la intención y el agente la lee al iniciar la sesión. El ahorro se manifiesta no en throughput sino en consistencia: cada sesión del agente parte de la misma verdad fundamental.

Cubo 2 — Deriva

Liu Shangqi lo señaló directamente: “La deriva de la spec y la alucinación son inherentemente difíciles de evitar. Todavía necesitamos prácticas de CI/CD altamente deterministas para asegurar la calidad del software y salvaguardar nuestras arquitecturas.” El punto no es que la deriva se vaya a cero con SDD — no se va. El punto es que con SDD la deriva tiene una dirección: cuando el código y la spec divergen, la solución es actualizar la spec, no parchear el código. Sin SDD, la deriva no tiene dirección; parcheas el archivo que sea más fácil, y la spec se convierte en ficción en cuestión de semanas.

Cubo 3 — Cascada de retrabajo

El desarrollador de r/ExperiencedDevs citado arriba dio exactamente con esto: “seguía fallando y fallando mientras destruía otras funcionalidades”. Esa es la cascada. La IA genera un fix, el fix rompe la función de al lado, el desarrollador (u otra pasada de IA) arregla esa, lo que rompe una tercera función. Con SDD, la spec constriñe el objetivo de la regeneración, así que la cascada típicamente termina en la frontera del contrato en lugar de propagarse por toda la codebase.

Cubo 4 — Impuesto de revisión

Leer 3.000 líneas de código generado por IA que no escribiste es cognitivamente más caro que escribir 300 líneas tú mismo. Este es un coste nada obvio que el hype de la “productividad 10×” nunca menciona. Con SDD, el objetivo de revisión es el informe de cumplimiento con la spec y el diff contra el contrato — una superficie mucho menor. El resultado del 19%-más-lento de METR, yo diría, viene en gran medida de equipos que no adoptaron SDD y por tanto pagan el impuesto completo de revisión en cada cambio generado por IA.

Voy a ser cauto con el número titular. La reducción del 40-60% no es una constante universal; es lo que se observa en equipos que pasan de vibe-coding sin estructura a un workflow SDD disciplinado y mantienen el rol de curador. Equipos que adoptan herramientas SDD sin cambio de rol ven ganancias mucho menores — y con frecuencia reportan resultados peores, porque la sobrecarga de mantenimiento de la spec sin la disciplina de regeneración es impuesto puro.

El ángulo crítico: qué aciertan los críticos

SDD no es comida gratis. Leer las fuentes escépticas con honestidad es parte del trabajo del estratega, así que aquí va lo que los críticos aciertan.

El problema “las specs se quedan obsoletas”

Un hilo de Reddit titulado “What spec-driven development gets wrong” plantea el modo de fallo sin rodeos:

“Spec-driven development (SDD) suffers from the same fatal flaw as every documentation-first approach: specs are documents, and documents go stale because nobody rewards the invisible maintenance work of keeping them current.”

— r/vibecoding, mayo 2026

Este es otra vez el problema del rol de curador, pero formulado desde fuera de la comunidad SDD. La respuesta no es “tenemos herramientas que evitan la obsolescencia”; las herramientas solas no lo resuelven. La respuesta es “el rol del desarrollador debe incluir explícitamente el mantenimiento de la spec como una actividad facturable y recompensada, no como sobrecarga invisible”. Esa es una respuesta de gestión, no de herramientas, y la mayoría de artículos sobre SDD se la saltan.

El problema “las specs codifican la confusión”

Otro hilo, de r/programming en febrero de 2026:

“The irony of the current AI-driven push toward ‘spec-driven development’ is that people think the spec replaces the need to understand the domain. It doesn’t — it just encodes your understanding.”

— r/programming, febrero 2026

Esta es una crítica seria. SDD no reemplaza la experiencia de dominio; la cristaliza en un documento. Si tu comprensión del problema es errónea, la spec será errónea, y el código generado será erróneo con mucha mayor confianza que la versión vibe-coded. SDD recompensa la profundidad de pensamiento, no la velocidad al teclear. Equipos que adoptan SDD esperando que compense por análisis superficial se llevarán una decepción profunda.

El problema “las specs se convierten en slop informativo a escala”

Un comentario en r/AI_Agents en julio de 2026 capturó el modo de fallo al escalar:

“Sure you can keep asking the AI to resolve those constantly, but 1) that’s costly, maybe not a problem now, will it be a problem later? 2) AI’s resolution isn’t consistent, sometimes you need 2-3 passes before the disparities are all addressed — it’s like fitting a conditional random field, the bigger the field, the more passes you need to go through to ‘settle’ the model.”

— u/treble-maker123, r/AI_Agents, julio 2026

Esa es la crítica de la “codebase diffusion” — a escala suficiente, la spec misma se convierte en un artefacto complejo que necesita reconciliación entre versiones, y el coste de mantenerla consistente supera los ahorros. La mitigación es mantener las specs lo más pequeñas y componibles posible — el diseño de “spec deltas” de OpenSpec es una respuesta, la separación entre constitución y specs de feature de GitHub Spec Kit es otra. Pero la crítica se sostiene: hay una escala en la que SDD deja de compensar, y esa escala es menor de lo que sugiere el hype.

El debate interno en Thoughtworks

El post de Liu Shangqi en diciembre de 2025 incluyó un debate interno notable en Thoughtworks:

“At the more radical end of the spectrum, there’s an argument that we can now discard code and treat specs as the sole source of truth that needs maintenance. In this view, code is a kind of byproduct, an intermediate product between requirements and compiled binaries. In contrast, more old-school technologists — like me — believe specs are merely elements that drive code generation, as it does in test-driven development. Executable code remains the source of truth you need to maintain.”

Esta es la comunidad SDD discutiendo consigo misma sobre si Spec-as-Source es real o aspiracional. La respuesta honesta es: funciona para dominios acotados (APIs, esquemas, infraestructura) y se desmorona para dominios no acotados (algoritmos novedosos, UI exploratoria, cualquier cosa donde la spec misma se está descubriendo a través de la implementación). Elegir el nivel de compromiso adecuado por proyecto es un juicio estratégico, no un valor por defecto.

Cómo se traduce esto para un indie dev

La línea editorial del blog es “indie dev / solopreneur”, así que traduzco la estrategia a términos concretos para alguien que trabaja solo en un side project. El marco corporativo de “necesitarás un equipo de specs” no aplica.

El camino realista de adopción

Empieza en Spec-first. Elige una funcionalidad. Escribe una spec de una página: cuáles son las entradas, cuáles son las salidas, cómo son los modos de fallo. Haz que el agente la implemente. Lee el diff contra la spec. Eso por sí solo cazará más bugs que cualquier cantidad de “prompts cuidadosamente redactados”.
Gradúa a Spec-anchored para cualquier cosa que mantendrás más de un mes. Añade un directorio specs/ al repo. Trata el archivo de spec como documento vivo. Cada vez que cambies requisitos, actualiza la spec primero, luego regenera.
Alcanza Spec-as-Source solo donde sea barato. APIs con definiciones OpenAPI. Esquemas con JSON Schema. Configuraciones con Terraform/Pulumi. Infraestructura con Ansible. Esos son dominios donde el formalismo de spec ya existe, está maduro, y está diseñado para ser la fuente de verdad. Intentar que Spec-as-Source funcione para un flujo de UI único es una pérdida de tu tiempo.

El coste-beneficio honesto

Las ganancias de reducción de desperdicio de SDD son reales para los cuatro cubos de arriba, pero vienen con un impuesto inicial: la disciplina de escribir specs antes que código. Para un indie dev que entrega un prototipo de fin de semana, ese impuesto es demasiado alto. Para un indie dev que entrega un SaaS por el que pagan clientes, el impuesto es una ganga comparada con la alternativa de debuggear 3.000 líneas de código IA a las 2AM.

La decisión no es “¿debería usar SDD?”. La decisión es “para esta funcionalidad específica, ¿la spec cuesta menos que el impuesto de re-derivación + deriva + retrabajo + revisión que pagaría si no?”. Es una llamada de juicio feature por feature, no un interruptor metodológico que se gira globalmente.

La redefinición de rol, aplicada a una sola persona

Cuando estás solo, los cuatro roles (arquitecto, validador, orquestador, curador) se colapsan en un único horario semanal:

Lunes por la mañana: arquitecto. Planifica las funcionalidades de la semana. Actualiza las specs.
A media semana: orquestador. Compón sesiones de agente alrededor de las specs.
Final del día: validador. Ejecuta los contract tests. Diffea el código generado contra la spec.
Viernes por la tarde: curador. Revisa qué specs derivaron, arréglalas, archiva las muertas.

Esa es la versión indie realista de la redefinición de rol. No es glamurosa. Es, sin embargo, lo que detiene la resaca.

El horizonte estratégico

La industria se mueve rápido. Algunas señales que vale la pena seguir:

Thoughtworks Technology Radar (noviembre 2025): SDD añadido como técnica reconocida. Tres interpretaciones explícitamente catalogadas.
Augment Code Cosmos (2026): orquestación enterprise multi-repo construida alrededor de specs. Señala que las grandes organizaciones creen que la capa de spec es infraestructura duradera, no una tendencia pasajera.
Linux Foundation albergando la gobernanza del Agent Skills Standard (según William Collins, marzo de 2026): la capa compañera de las specs — archivos de instrucción que constriñen cómo la IA escribe código, mientras las specs constriñen qué debe hacer el código. Las dos capas están convergiendo.
Pronóstico Gartner (vía Augment Code, 2026): el 90% de los ingenieros de software enterprise usarán asistentes de código IA para 2028. La pregunta de gobernanza — quién mantiene las specs, quién revisa el cumplimiento — se convierte en asunto de C-level, no de equipo de ingeniería.

La implicación estratégica para un indie dev no es “adopta SDD o te quedas atrás”. Es posicionarte en el lado correcto de la redefinición de rol. Los desarrolladores que prosperen en los próximos cinco años serán los que traten las specs como su artefacto primario, el código como artefacto secundario, y los agentes de IA como el equipo que orquestan. Los que se aferren a “yo soy el que escribe el código” se encontrarán compitiendo contra equipos de agentes que producen más, más rápido, con menos vulnerabilidades de seguridad.

Checklist práctico antes de adoptar

Cinco preguntas que responder antes de mover un proyecto a SDD:

¿Es este dominio spec-friendly? APIs, esquemas, infraestructura, feature specs estilo BDD → sí. Algoritmos novedosos, UI exploratoria, scripts puntuales → probablemente no.
¿Puedes nombrar el formalismo de spec? OpenAPI, JSON Schema, AsyncAPI, Protobuf, Terraform HCL, Cucumber/Gherkin. Si no puedes señalar uno, no tienes una spec, tienes un deseo.
¿Quién mantiene la spec cuando la implementación revela nuevos casos límite? Si la respuesta es “nadie”, no adoptes SDD. Producirás artefactos Spec-first y los dejarás pudrir.
¿Cuál es la ruta de regeneración? OpenAPI Generator, JSON Schema codegen, terraform plan, el ejecutor de tareas de Kiro. Si no hay ruta de regeneración determinista, la spec es documentación, no fuente.
¿Cuál es el test que prueba que el código generado cumple el contrato? Sin esto, has movido el impuesto de revisión de “leer el diff” a “confiar en la IA”. Ninguno de los dos es suficiente.

Si puedes responder las cinco, la redefinición de rol vale el coste inicial. Si no, empieza con Spec-first en una funcionalidad y observa si la disciplina de curador encaja en realidad con tu estilo de trabajo antes de escalarla.

Lo que me llevo de esto (y lo que me genera escepticismo)

Estoy convencido de que la redefinición de rol es real y duradera. El desplazamiento de mecanógrafo a arquitecto de la intención no es hype — es lo que los datos (METR, Veracode, las quejas de operadores en Reddit) respaldan. La descomposición en cuatro roles (arquitecto, validador, orquestador, curador) es el modelo mental más limpio que he encontrado para navegar el desplazamiento.

Sigo escéptico de dos afirmaciones que circulan en la comunidad SDD:

Que SDD es “simplemente” TDD para la era de la IA. La reducción de desperdicio de TDD está validada empíricamente en ~40% en estudios industriales. La de SDD es plausible pero todavía no está validada al mismo nivel — el 40-60% que cité es una extrapolación de estudios por componentes, no un metaanálisis. Trátalo como hipótesis de trabajo.
Que Spec-as-Source escala a todos los dominios. La crítica de “codebase diffusion” de r/AI_Agents es real. Spec-as-Source funciona para dominios acotados y declarativos (APIs, esquemas, infra). Para dominios donde la spec misma se está descubriendo a través de la implementación (algoritmos novedosos, UX exploratoria, código de investigación), Spec-anchored o Spec-first es el techo honesto.

El blog seguirá volviendo a esta pregunta — ¿cómo sabes qué nivel de compromiso SDD es el adecuado para la funcionalidad que tienes delante? — porque esa es la llamada estratégica que ningún framework responde por ti. Spec Kit, OpenSpec, BMAD, Kiro, Superpowers — todos asumen que ya tomaste la decisión. El rol del arquitecto es tomarla.

Bibliografía / Referencias

Fuentes primarias

Liu Shangqi. “Spec-driven development: Unpacking one of 2025’s key new AI-assisted engineering practices.” Thoughtworks Technology Insights, 4 de diciembre de 2025. https://www.thoughtworks.com/en-us/insights/blog/agile-engineering-practices/spec-driven-development-unpacking-2025-new-engineering-practices
Molisha Shah. “8 Best AI Tools for Spec-Driven Development.” Augment Code Tools, 2026. https://www.augmentcode.com/tools/best-ai-tools-for-spec-driven-development
William Collins. “Vibe Coding Got Us Here. Can Spec-Driven Development Save Us?” wcollins.io, 23 de marzo de 2026. https://wcollins.io/posts/2026/from-vibes-to-specs/
Leigh Griffin & Ray Carroll. “Spec Driven Development: When Architecture Becomes Executable.” InfoQ Architecture & Design, 12 de enero de 2026. https://www.infoq.com/articles/spec-driven-development/
“Spec-driven development.” Wikipedia. https://en.wikipedia.org/wiki/Spec-driven_development
“Spec-driven development.” Thoughtworks Technology Radar, 5 de noviembre de 2025. https://www.thoughtworks.com/radar/techniques/spec-driven-development

Voces críticas / de la comunidad

u/FooBarBuzzBoom. “Spec Driven Development and other shitty stuff.” r/ExperiencedDevs, febrero de 2026. https://www.reddit.com/r/ExperiencedDevs/comments/1reiro1/spec_driven_development_and_other_shitty_stuff/
u/almeynman. “Why do spec-driven development?” r/AI_Agents, junio de 2026. https://www.reddit.com/r/AI_Agents/comments/1ug186i/why_do_specdriven_development/
r/vibecoding. “What spec-driven development gets wrong.” Mayo de 2026. https://www.reddit.com/r/vibecoding/comments/1t78bm5/what_specdriven_development_gets_wrong/
r/programming. “Spec-driven development doesn’t work if you’re too confused to write the spec.” Febrero de 2026. https://www.reddit.com/r/programming/comments/1r0s9za/specdriven_development_doesnt_work_if_youre_too/
u/treble-maker123. Comentario en r/AI_Agents, “Why do spec-driven development?”, julio de 2026.

Estudios empíricos citados

Veracode. 2025 GenAI Code Security Report. 45% código IA con vulnerabilidades; +70% tasa de fallo en Java; 86% fallos en protección XSS.
METR. Randomized Controlled Trial: Impact of AI on Developer Productivity. Julio de 2025. 19% más lentos con IA; 24% percibidos más rápidos.
CodeRabbit. State of AI Code Quality Report, diciembre de 2025. Tasa de XSS 2,74× mayor vs. código humano.
GitClear. Code Quality Research: 2020–2024. ~4× aumento de duplicación de código.

Prior art en este blog

Desarrollo Impulsado por Especificaciones con IA Agéntica — la definición fundacional y taxonomía.
Serie Socratic Agent (Parte 2): SDD y Sycophancy — cómo SDD lucha contra la complacencia de la IA en pipelines CI.
“Grill Me” vs Método Socrático vs Spec-Driven Dev — la tensión filosófica entre honrar la spec y cuestionarla.
Análisis Profundo de Frameworks SDD: GitHub Spec Kit, OpenSpec y BMAD — la comparación a nivel de herramientas.
Intent-Driven Development con FORGE y AISpec — metodología complementaria intent-first.
Spec Kitty: SDD para Agentes de Código IA — workflow CLI que convierte intención de producto en loop de agente repetible.
OpenSpec para Desarrollo Móvil — aplicando SDD a proyectos Android y Kotlin brownfield.

El ecosistema SDD se mueve rápido. Si encuentras una fuente que debería estar en esta bibliografía — un estudio que pasé por alto, un contraargumento que no abordé, un framework que olvidé — dímelo en comentarios o por el canal que prefieras. La redefinición de rol es real, pero la conversación sobre ella está lejos de estar cerrada.