OpenSpec vs. Spec Kit vs. Superpowers: herramientas de SDD comparadas

Cada vez que publico algo sobre mi setup de spec-driven development, vuelven las mismas preguntas. ¿Cómo se compara con OpenSpec? ¿Con Spec Kit? ¿Con Superpowers? ¿No es solo AGENTS.md con más pasos? Preguntas justas, y merecen una respuesta directa en lugar de un pitch.

Voy a responderlas desde producción, no desde una matriz de features. Entregué una fintech cripto de 13 apps en 70 días, yo solo, con agentes de IA moviendo dinero real. Lo que decidió en qué herramienta podía confiar nunca fue la lista de features. Fue una sola pregunta: cuando el agente me entrega un borrador que parece terminado, ¿tiene permiso para ejecutarse? Porque el borrador que parece terminado fue el que más caro me salió.

Así que aquí va el mapa honesto. Cinco formas de darle a un agente de IA la intención que no tiene por sí solo, ordenadas más o menos por cuánto proceso te impone cada una. Una de ellas es mía (pi-sdd-kit). Va al final, para que la juzgues contra las demás, y te voy a decir sin rodeos dónde es la opción equivocada.

Si el método en sí es nuevo para ti, empieza por ¿Qué es spec-driven development?. Este texto da por hecho que ya te convenció el porqué y que estás eligiendo la herramienta.

Todas resuelven el mismo problema

Un agente de IA vive en un eterno presente. Cada sesión empieza de cero. No recuerda la restricción que agregaste a las 10 de la noche, el edge case que decidiste dejar fuera del alcance, la razón por la que elegiste Postgres en lugar de SQLite. Así que reinventa esas decisiones, de otra forma, en cada ejecución. Y si lo dejas, corre directo al código antes de que se pongan de acuerdo sobre qué debería hacer ese código.

Lo notas como el borrador seguro de sí mismo. Describes la feature, el agente escribe sesenta líneas, la demo corre, la terminal queda en verde. Parece terminado. Después producción encuentra lo que el borrador dejó fuera: el timeout que nunca nombraste, el retry que le cobra dos veces al cliente, el registro escrito a medias. El agente escribió el camino feliz. Todo lo que solo aparece cuando el código se topa con algo real se lo saltó, en silencio, y sin inmutarse.

Ese es todo el problema. Un defecto en código generado por IA no es un bug en el código. Es un hueco en la intención que nunca escribiste. Expliqué el mecanismo en Spec-driven development vs. vibe coding. Cada herramienta de abajo es una respuesta a la misma pregunta: ¿dónde vive la intención, y cuánto te obligan a escribirla antes de que corra el agente?

El hueco ya no es anecdótico

+98%

más pull requests con IAinforme DORA 2025

+243%

más incidentes por pull requestel throughput no salió gratis

31%

más PRs mergeados sin ningún review humanosalida segura de sí, nadie la vuelve a mirar

Las herramientas difieren en un eje más que en cualquier otro: cuánto proceso imponen. De nada a mucho. Ese es el espectro.

1. Memoria simple: AGENTS.md y nada más

La opción sin instalación. Mantienes de dos a cuatro archivos markdown pequeños en el repo (AGENTS.md, o CLAUDE.md, un conventions.md, un decisions.md) con las reglas duraderas, el stack y las decisiones que no pueden ir cambiando. En cada sesión, el agente los lee. Tú los actualizas a mano.

Esto rinde más de lo que la mayoría cree. Alguien lo describió tal cual en un comentario a uno de mis posts: 2 o 3 docs cortos por proyecto, un límite estricto de 5kb para no reventar nunca el context window, recortados a mano después de cada tarea grande. En un codebase de menos de 5000 líneas donde refactorizas sin piedad, eso de verdad alcanza. No le agregues ninguna herramienta.

Dónde se rompe: no hay enforcement. Los docs son memoria, no un workflow. Nada impide que el agente lea un archivo que parece razonable y programe lo que no era. No hay spec por feature, ni gate, ni estructura para “esto es lo que debe hacer este cambio específico”. Es un gran piso. No es un método.

2. OpenSpec: una capa ligera de spec, fluida a propósito

OpenSpec (@fission-ai/openspec, MIT) se presenta como el framework de spec más querido, y se gana el eslogan. Agrega una capa delgada de spec encima del agente que ya usas, y hoy soporta más de 30. Lo instalas con npm o Homebrew, corres openspec init y luego le hablas a tu asistente con slash commands: /opsx:explore para pensar una idea, /opsx:propose para convertirla en un cambio, /opsx:apply para implementarlo, /opsx:archive para integrar el resultado de vuelta en las specs. Un perfil ampliado suma pasos como /opsx:verify y /opsx:continue cuando quieres más estructura.

El modelo mental son dos carpetas. openspec/specs/ es la fuente de verdad actual. openspec/changes/<name>/ es un cambio propuesto, cada uno en su propia carpeta con un proposal.md, specs/, design.md y tasks.md. Se ponen de acuerdo sobre el cambio, el agente lo implementa, luego se archiva y las specs absorben lo que llegó a producción. Las versiones más nuevas suman los Stores (en beta): las mismas specs y cambios, guardados en un repo de planificación propio, para que una feature que cae en tres repos siga teniendo un solo plan.

La decisión que lo define está en su propia documentación: “update any artifact anytime, no rigid phase gates.” OpenSpec es fluido a propósito. Está hecho para brownfield y no te obliga a detenerte y aprobar formalmente cada etapa. Eso es una feature. También es justo lo que lo separa de lo que yo construí.

Dónde encaja: quieres la spec como fuente de verdad y propuestas de cambio limpias, con el agente que sea, sin ceremonia. Dónde quizá no: si “sin gates rígidos entre fases” es precisamente la disciplina que esperabas que la herramienta impusiera, OpenSpec deliberadamente no la impone.

3. Spec Kit: el pipeline estructurado de GitHub

Spec Kit (GitHub, MIT, unas 140k estrellas) es el extremo estructurado del spec-first, y llegó a la 1.0 en agosto. Instalas la CLI specify con uv (necesita Python 3.11 o más nuevo), corres specify init con la integración de tu agente y luego llevas al agente por una secuencia fija. /speckit-constitution corre una vez por proyecto y escribe los principios que toda feature tiene que respetar. Después, por feature: /speckit-specify, /speckit-plan, /speckit-tasks, /speckit-implement. Los pasos opcionales entran cuando quieres controles extra: /speckit-clarify antes del plan, /speckit-analyze para la consistencia entre artefactos, /speckit-checklist para lo que en la práctica son tests unitarios para el texto de la spec.

El paso que llegó en junio es el interesante. /speckit-converge compara lo que se construyó con la spec, el plan y las tasks, y agrega lo que falta como tasks nuevas. Repites implement y converge hasta que reporta que convergió. Es Spec Kit admitiendo lo que todos aprendimos a la mala: el agente dice que terminó antes de terminar.

Dos cosas cambiaron desde la primera ola de críticas. La branch por spec ahora es opcional: la feature activa vive en .specify/feature.json, y las branches numeradas por feature vienen de una extensión de git que agregas si quieres. Y Spec Kit dejó de ser solo SDD. La corrección de bugs (assess, fix, test) y la evaluación de ideas (una decisión de seguir o matar antes de construir nada) vienen como extensiones.

Dónde encaja: quieres un pipeline documentado que corra igual en cada feature, con una constitution que toda feature respeta. A los equipos les gusta, porque cada cambio produce los mismos artefactos en los mismos lugares. Dónde quizá no: la verbosidad es real. La queja más común no cambió: un cambio de tres archivos enterrado bajo cientos de líneas de prosa generada que alguien tiene que revisar. Puedes recortarlo con el preset lean, que viene incluido (specify preset add lean) y deja cada fase en un solo archivo enfocado, pero tienes que elegirlo. Y el orden es rígido, pero la aprobación no. La herramienta comprueba que el plan existe. No comprueba que una persona lo leyó.

Escribí una guía completa de Spec Kit si quieres cada comando en detalle.

4. Superpowers: una metodología completa, no una herramienta de spec

Superpowers (Jesse Vincent y Prime Radiant, MIT, cerca de 300k estrellas) es otra cosa. No es un framework de spec. Es una metodología completa de desarrollo de software, construida como una biblioteca de skills componibles que se disparan solas, más las instrucciones para que el agente de verdad las use.

Su workflow recorre el ciclo completo: brainstorming (diseño socrático, presentado en partes legibles para aprobarlo), using-git-worktrees, writing-plans (tareas de dos a cinco minutos cada una, con rutas de archivo exactas y pasos de verificación), subagent-driven-development (un subagent nuevo por tarea, con review de apego a la spec y luego de calidad de código) o el más barato executing-plans (en la misma sesión, con un solo review de toda la branch al final), test-driven-development (RED-GREEN-REFACTOR de verdad: borra el código escrito antes de un test), requesting-code-review y finishing-a-development-branch. Corre en Claude Code, donde está en el marketplace oficial de plugins de Anthropic, y en Codex, Cursor, Gemini CLI, Copilot CLI, OpenCode y Pi, entre otros. Las skills son workflows obligatorios, no sugerencias, y el agente puede trabajar solo un par de horas sin salirse del plan.

Así que sí, Superpowers tiene un paso con forma de spec (el brainstorming produce un diseño que tú apruebas). Pero es un solo paso dentro de un proceso opinado mucho más grande, cuyo centro de gravedad es TDD y la ejecución con subagents, no el artefacto de spec. El diseño y el plan sirven a la feature en curso. Nada los integra en una spec de largo plazo del sistema cuando el trabajo llega a producción.

Dónde encaja: quieres un SDLC agéntico completo y opinado, con disciplina test-first y subagents en paralelo ya incluidos. Dónde puede ser demasiado: si lo único que querías era fijar los requisitos antes de que el agente programe, Superpowers te trae una metodología entera de regalo.

5. pi-sdd-kit: acotado, opinado, con gate

Ahora el mío, y lo voy a medir con la misma honestidad. pi-sdd-kit (pi install npm:@felipefontoura/pi-sdd-kit) hace una sola cosa: spec-driven development en Pi, como cinco skills que invocas en orden. sdd-prd, sdd-spec, sdd-tasks, sdd-exec, sdd-review. Sin biblioteca de brainstorming, sin motor de TDD, sin gestor de worktrees. Solo el loop de SDD.

Dos cosas cargan el peso. Primero, steering docs como memoria duradera: product.md, tech-stack.md, conventions.md y principles.md viven aparte de cualquier feature y se cargan en cada sesión. Lo que rinde es la línea del porqué. “Usamos Postgres porque los registros de pago necesitan ACID” evita que el agente vaya por SQLite tres sesiones después. Segundo, el archivo .status es el único gate. Un token por fase: requirements:approved, luego design:approved, luego tasks:approved. Un design.md con pinta de terminado en disco no es aprobación. Solo el token lo es. Eso es lo que frena a un agente ansioso que quiere llevar un borrador directo al código. Los requisitos se escriben en EARS (WHEN / IF / WHILE / SHALL), así que casi no queda nada por interpretar.

Dónde encaja: quieres específicamente spec, aprobación y recién ahí build, con un gate humano estricto entre fases, y usas Pi. Dónde no: no usas Pi, o los gates explícitos te molestan más de lo que te tranquilizan. Es acotado a propósito: disciplina de spec y un gate estricto, sin el volumen de artefactos generados de Spec Kit y sin la debilidad puramente consultiva de AGENTS.md a secas. Ese es todo el diseño.

Spec Kit vs. OpenSpec: misma apuesta, distinto peso

Spec Kit y OpenSpec coinciden en la parte que importa. La spec es la fuente de verdad, y el agente trabaja a partir de ella. Difieren en cuánta ceremonia hace falta para llegar ahí.

~

OpenSpec

1. 01CLI en Node. openspec init y listo. Más de 30 asistentes.
2. 02Una carpeta por cambio: proposal, specs, design, tasks.
3. 03Actualiza cualquier artefacto cuando quieras. Sin gates de fase, por diseño.
4. 04El archive integra cada cambio de vuelta en las specs vivas.
5. 05Pensado primero para codebases existentes.

|

Spec Kit

1. 01CLI en Python vía uv. specify init con una integración por agente.
2. 02Una constitution una vez, luego specify, plan, tasks, implement.
3. 03Las fases corren en orden, con clarify, analyze y checklist opcionales.
4. 04Converge repite hasta que el código coincide con los artefactos.
5. 05Más Markdown por cambio, y alguien tiene que leerlo.

La pista está en sus propias palabras. El README de OpenSpec describe a Spec Kit como completo pero pesado. Spec Kit sigue en la dirección contraria, con converge y un catálogo de extensiones: más estructura, no menos. Ninguno se equivoca. Están hechos para cambios de distinto peso.

Mi regla: cuenta las líneas que alguien tiene que revisar en un cambio de tres archivos. Si los artefactos de spec son más largos que el diff, la herramienta es demasiado pesada para ese cambio. Los cambios pequeños y frecuentes sobre un codebase existente quedan más cerca del peso de OpenSpec. Un producto nuevo, con un equipo que necesita que cada feature responda a los mismos principios, es donde la constitution y la secuencia fija de Spec Kit pagan el Markdown extra.

OpenSpec vs. Superpowers: hacen trabajos distintos

Es la pregunta que más me hacen, y está un poco mal planteada. OpenSpec y Superpowers no compiten.

OpenSpec se encarga del qué y del porqué: una propuesta, los requisitos y una spec que sobrevive al cambio. Superpowers se encarga del cómo: un plan cortado en tareas de pocos minutos, tests primero, un subagent nuevo por tarea, review antes del merge. OpenSpec no tiene opinión sobre escribir los tests primero. Superpowers no tiene dónde guardar la razón de un requisito, seis meses después de que llegó a producción.

Así que elige por la falla que se te repite. Si el agente construye lo que no era, u olvida una decisión de hace tres sesiones, tienes un problema de spec, y eso es OpenSpec. Si el agente construye lo correcto pero mal, se salta los tests o se desvía del plan después de una hora, tienes un problema de ejecución, y eso es Superpowers. Si tienes los dos problemas, no estás eligiendo. Estás combinando.

Cómo usar OpenSpec y Superpowers juntos

Combinarlos es el setup más común que veo, y funciona cuando cada herramienta se queda en su carril.

Un cambio, dos herramientas

Entrada

Un cambio que vale más de una sesión

↓

1. OPENSPECExplorar y proponer

   /opsx:explore para pensarlo, luego /opsx:propose para escribir la propuesta, las specs delta, el diseño y las tasks. Ese es el registro que queda.

   ↓
2. TÚLeer la propuesta

   El paso que ninguna de las dos impone. Nada avanza hasta que una persona lee la spec y dice que sí.

   ↓
3. SUPERPOWERSPlanear y construir

   writing-plans convierte las tasks aprobadas en pasos pequeños. Luego test-driven development, un subagent nuevo por tarea y review entre tareas.

   ↓
4. OPENSPECArchivar

   /opsx:archive integra en las specs lo que de verdad llegó a producción, para que la próxima sesión arranque desde la verdad y no desde el plan.

↓

Salida

OpenSpec recuerda el porqué. Superpowers controla la calidad. Tú decides cuándo.

Dos reglas evitan que se peleen. Primero, un solo paso de diseño, no dos. El brainstorming de Superpowers y el explore/propose de OpenSpec cubren el mismo terreno. Corre los dos y te quedan dos diseños que se van separando. Deja que OpenSpec escriba el diseño y dile a Superpowers que planee a partir de la carpeta del cambio aprobado. Segundo, escribe el ruteo. Una sección corta en AGENTS.md o CLAUDE.md que diga qué herramienta es dueña de qué fase es lo que evita que el agente improvise el traspaso.

No tienes que conectarlo a mano. OpenSpec lista schemas de la comunidad en su documentación, y uno de ellos, superpowers-bridge, hace este traspaso en la capa de prompt y agrega un artefacto de retrospectiva cuando el trabajo llega a producción. Revisa su línea de compatibilidad antes de adoptarlo. Al 30 de septiembre, su README lista OpenSpec 1.4.1 y Superpowers v5.1.0 como base probada, mientras que las versiones actuales son 1.14 y 6.4.2. El pegamento en la capa de prompt aguanta mejor la diferencia de versiones que el código. Pero la diferencia sigue ahí.

Esta es la parte que ninguna combinación resuelve por ti. Ninguna de las dos herramientas frena al agente entre una propuesta con pinta de aprobada y el código. OpenSpec es fluido por diseño. Superpowers te pide el visto bueno en la conversación, y un agente ansioso, o tú cansado a las 11 de la noche, lo deja pasar. Hasta el schema de la comunidad de OpenSpec construido alrededor de un review adversarial (anvil) lo dice sin vueltas en el catálogo: OpenSpec solo comprueba que los artefactos existen, así que impón el gate con tu propio CI o hook. Ese hueco es la razón de ser de pi-sdd-kit. En cualquier otro stack lo cierras igual: un archivo de estado o un hook que se niega a correr el apply hasta que exista un token humano.

¿Y BMAD y Kiro?

Los dos salen en cada hilo, así que brevemente.

BMAD (v6.12, unas 54k estrellas) se define como desarrollo ágil impulsado por IA. Trae perspectivas especializadas de producto, arquitectura, UX, desarrollo y testing, y dimensiona la planificación según el cambio: los cambios pequeños van directo al build, el trabajo complejo recibe brief, especificación y arquitectura antes de cualquier código. Es la opción más cargada de roles de esta lista. Cerca de Superpowers en alcance, pero organizada alrededor de un equipo ágil en lugar de TDD.

Kiro es el IDE de AWS con el workflow de spec integrado: requisitos, diseño y tasks dentro del editor. Elígelo si quieres SDD sin armar nada tú mismo y no te molesta vivir en ese editor.

De un vistazo

Herramientas de spec-driven, comparadas

Ordenadas más o menos por cuánto proceso impone cada una, con la mía al final. El enforcement es el eje que de verdad decide la elección.

Herramienta	Alcance	Enforcement	Ideal para
Memoria simple (AGENTS.md)	Solo reglas duraderas	Ninguno. Manual.	Codebases pequeños, solo, disciplinados
OpenSpec	Capa de spec + propuestas de cambio	Fluido. Sin gates de fase, por diseño.	Spec como verdad con cualquier agente
Spec Kit	Constitution + pipeline en secuencia	Fases en orden, aprobación por convención	Equipos que quieren los mismos artefactos siempre
Superpowers	Metodología de SDLC completa	Skills obligatorias que se disparan solas	TDD + subagents, de punta a punta
BMAD	Roles ágiles + planificación dimensionada	Workflows guiados	Planificación por roles en trabajos grandes
pi-sdd-kit	Solo el workflow de SDD	Gate .status estricto por fase	Spec-y-luego-aprobación estricto en Pi

La bifurcación real: fluido o con gate

Quita las listas de features y queda una decisión haciendo casi todo el trabajo. Cuando el agente tiene un plan que parece terminado, ¿puede empezar a programar, o una persona tiene que dar luz verde primero?

~

Fluido (OpenSpec, memoria simple)

1. 01Actualiza cualquier artefacto cuando quieras y sigue avanzando.
2. 02Poca ceremonia, iteración rápida, ideal para brownfield.
3. 03El agente puede actuar sobre un plan que parece completo.
4. 04La disciplina vive en ti, no en la herramienta.

|

Con gate (pi-sdd-kit, Superpowers)

1. 01Una fase no avanza hasta que hay una señal explícita.
2. 02Más fricción al principio, menos retrabajo por ir en la dirección equivocada.
3. 03Un borrador con pinta de terminado no es permiso para programar.
4. 04La disciplina vive en la herramienta, así que sobrevive a una noche de cansancio.

Spec Kit queda en el medio: el orden se impone, la aprobación no. Por eso “¿cómo se compara?” no tiene una sola respuesta. OpenSpec quita los gates a propósito porque la ceremonia frena la iteración. pi-sdd-kit agrega un gate estricto a propósito porque yo estaba entregando movimiento de dinero, y un borrador equivocado pero seguro de sí que llega al código sale caro. Mismo problema, apuestas opuestas. Tu contexto decide cuál apuesta es la correcta.

El veredicto honesto

El eje honesto no es una sola línea de menos proceso a más. Es alrededor de qué está construida la herramienta. Spec-first (OpenSpec, Spec Kit, pi-sdd-kit) pone la especificación en el centro. Harness-first (Superpowers) pone el proceso de ejecución en el centro y trata la spec como un paso más. Role-first (BMAD) pone un equipo ágil simulado en el centro. IDE-native (Kiro) pone el editor en el centro. Los steering docs (memoria simple) están debajo de todas. No se trata de lealtad a una marca. Se trata de saber qué problema tienes de verdad y agregar solo el proceso que ese problema necesita.

Si todavía estás decidiendo si necesitas disciplina de spec, el caso de estudio de 13 apps en 70 días es el argumento más fuerte que tengo. Si quieres el formato de una buena spec sin importar la herramienta, Cómo escribir una spec es agnóstico de herramienta a propósito.

Preguntas frecuentes

¿OpenSpec es mejor que Spec Kit?+

Ninguno es mejor en abstracto. Coinciden en que la spec es la fuente de verdad y difieren en el peso. OpenSpec es una CLI ligera en Node, con una carpeta por cambio, sin gates de fase y muy buena para codebases existentes. Spec Kit es una CLI en Python con una constitution y una secuencia fija (specify, plan, tasks, implement, converge) que produce más artefactos por cambio.

Elige OpenSpec cuando tus cambios son pequeños y frecuentes y quieres seguir avanzando. Elige Spec Kit cuando un equipo necesita que cada feature pase por el mismo pipeline documentado y puede darse el lujo de revisar el Markdown extra.

¿Se pueden usar OpenSpec y Superpowers juntos?+

Sí, y es el stack más común que veo. OpenSpec se encarga de la propuesta, las specs y el archive. Superpowers se encarga de la planificación, la implementación con tests primero, los subagents y el review. Usa un solo paso de diseño, no los dos, y escribe en AGENTS.md o CLAUDE.md qué herramienta es dueña de qué fase.

El schema superpowers-bridge, de la comunidad de OpenSpec, hace el traspaso por ti. Revisa antes las versiones probadas: en septiembre de 2026 lista OpenSpec 1.4.1 y Superpowers v5.1.0, bastante atrás de las versiones actuales. Y agrega tu propio gate de aprobación entre la propuesta y el apply, porque ninguna de las dos herramientas impone uno.

¿Qué herramienta de spec-driven development funciona mejor con Claude Code?+

Todas las de aquí corren en Claude Code, menos pi-sdd-kit, que es nativo de Pi. Superpowers se instala desde el marketplace oficial de plugins de Anthropic, OpenSpec y Spec Kit instalan sus comandos o skills en Claude Code al hacer init, y BMAD tiene un plugin para Claude Code. Claude Code no es la restricción. Tu problema sí.

Si el agente olvida decisiones, empieza por OpenSpec. Si ejecuta mal, empieza por Superpowers. Si quieres correr el loop en Claude Code sin ningún framework, mi guía de spec-driven development con Claude Code lo muestra solo con archivos.

¿Cuál es la diferencia entre pi-sdd-kit y OpenSpec?+

OpenSpec es una capa de spec ligera y agnóstica del agente, fluida a propósito: actualizas cualquier artefacto cuando quieras, sin gates rígidos entre fases. pi-sdd-kit es la apuesta opuesta. Es nativo de Pi e impone un gate de aprobación estricto vía .status entre fases, así que el agente no puede pasar de requisitos a diseño y a código sin un token humano explícito.

Los dos mantienen markdown como fuente de verdad. La diferencia real es el enforcement. Elige OpenSpec si quieres velocidad y flexibilidad con cualquier agente. Elige pi-sdd-kit si quieres que el gate evite que el agente se te adelante.

¿Cómo se compara pi-sdd-kit con Superpowers?+

Alcances distintos, y Superpowers es excelente. El Superpowers de Jesse Vincent es una metodología completa de desarrollo de software: brainstorming, planificación, test-driven development, ejecución con subagents y code review, todo como skills componibles que se disparan solas en muchos agentes, Pi incluido.

pi-sdd-kit hace una sola cosa acotada: el loop de spec-driven (prd, spec, tasks, exec, review) con un gate de aprobación estricto, en Pi. Si quieres un SDLC amplio y opinado con TDD incluido, usa Superpowers. Si solo quieres la disciplina estricta de spec y luego aprobación, eso es pi-sdd-kit. Incluso podrías correr la disciplina de SDD dentro de un setup con Superpowers.

¿De verdad necesito una herramienta de spec, o alcanza con AGENTS.md?+

En un codebase pequeño donde trabajas solo y refactorizas sin piedad, la memoria simple en AGENTS.md o CLAUDE.md de verdad alcanza. Mantén los archivos chicos, actualízalos a mano y no agregues ninguna herramienta.

La memoria simple se te queda corta cuando necesitas specs por feature, una forma de acordar un cambio antes de construirlo, o un gate impuesto para que el agente no programe lo que no era. Ahí es cuando OpenSpec, Spec Kit, Superpowers o pi-sdd-kit empiezan a pagarse solos.

¿Spec-driven development no es solo waterfall con otro nombre?+

Es la objeción más común, y tiene algo de razón. Escribir la intención antes del código es una idea vieja. Lo nuevo es que la spec es contexto ejecutable para un agente no determinista, no un documento que se firma y se archiva en un cajón. Waterfall escribía una spec grande al principio y castigaba los cambios. SDD escribe una spec pequeña por cambio, la mantiene como memoria viva que el agente lee en cada sesión y da por hecho que va a cambiar.

El valor nunca fue la ceremonia. Es el razonamiento que te obliga a hacer antes de que el agente programe, capturado en una forma desde la cual el agente puede ejecutar. Si tu spec es un doc que nadie lee, construiste la versión waterfall. Si es el archivo desde el que el agente regenera, construiste la útil.

Las herramientas no compiten realmente por el mismo trabajo. Son distintas cantidades de proceso montadas sobre la misma idea: escribe la intención antes de que corra el agente, porque el agente no la recuerda. Elige la cantidad de proceso que corresponda al costo de equivocarte.