Cuándo el desarrollo guiado por especificaciones es excesivo: explora primero, clasifica por complejidad y planifica lo que perdurará

Tras un año de herramientas para el desarrollo guiado por especificaciones (SDD), todas las demos muestran la misma película: un comando produce una especificación, el siguiente un plan, otro una lista de tareas y un agente construye la funcionalidad. Lo que las demos nunca muestran es la pregunta previa: ¿este cambio debería pasar por el flujo completo?

Me hice esa pregunta en mi propio repositorio porque mi configuración me obligó a hacerlo. El 29 de octubre de 2026, retiré OpenSpec de este sitio y estandaricé el trabajo en torno a GitHub Spec Kit. En el proceso encontré tres cosas. Las especificaciones canónicas eran correctas, pero nada las cargaba ya. Había cambios que se habían entregado sin llegar a incorporarse al canon. Y una política recién escrita en mi CLAUDE.md exigía el flujo de Spec Kit para cada cambio de funcionalidad o de herramientas que no fuera un artículo: sin niveles, sin excepciones y sin fecha de revisión.

Este artículo presenta el framework al que llegué. Es una continuación de ¿Cuándo basta un prompt y cuándo necesitan más los agentes de IA?, que cubría el extremo más pequeño de la escala, y de La parte humana de GitHub Spec Kit: cómo hablar con los agentes entre comandos, que trataba el juicio humano dentro del flujo. Este artículo trata de la clasificación antes del flujo y de lo que sobrevive después.

Para conocer los estudios de 2026 que respaldan la pregunta de cuándo vale la pena usar SDD, lee Después del desarrollo guiado por especificaciones: articula siempre, especifica a veces.

TL;DR

• No, no siempre deberías usar desarrollo guiado por especificaciones. Para trabajo pequeño, exploratorio, desechable o evidente, un prompt con una especificación breve —o el modo de planificación— es el nivel adecuado. Aplicar SDD completo ahí es pura ceremonia.
• La incertidumbre no es una señal para escribir una especificación; es una señal para explorar. SDD es una herramienta de ejecución. Cuando todavía no sabes qué construir, haz primero un spike o un prototipo; escribe la especificación una vez que ninguna incógnita pendiente pueda cambiar la forma de la solución.
• Después de explorar, clasifica según complejidad × irreversibilidad. La complejidad está en el acoplamiento, las personas que mantienen el sistema, la superficie de integración y la regulación, no en las líneas de código.
• Elige deliberadamente la vida útil de la especificación: spec-first (desechable), spec-anchored (duradera, pero con un costo de actualización) o spec-as-source (solo donde la generación sea madura y confiable). A 29 de octubre de 2026, la propia documentación de Spec Kit de GitHub plantea lo mismo mediante modelos de persistencia posteriores a la entrega y señala que ninguno es el predeterminado.
• Planifica la promoción dentro de las propias tareas del cambio. El conocimiento sobrevive cuando queda siempre en el camino del agente —instrucciones de carga automática o verificaciones que se ejecutan en cada build— o en un repositorio de consulta con un mecanismo real para encontrarlo. En mi repositorio, la promoción que se concretó estaba escrita como tareas, mientras que el paso de archivado que dependía de que alguien lo recordara quedó rezagado. Un repositorio y un puñado de cambios hacen de esto un caso, no una medición.
• Una obligación general de usar SDD es una política con fecha de vencimiento. Como piloto de duración limitada es defendible; si se mantiene indefinidamente sin niveles, métricas ni fecha de revisión, se convierte en la sobrecarga que buscaba evitar.

La pregunta que las herramientas no responderán

La documentación de las herramientas da por hecho que la respuesta es sí. El documento de postura de GitHub lo plantea en sus términos más contundentes: en el desarrollo guiado por especificaciones, «mantener software significa hacer evolucionar las especificaciones» y el código es la expresión final de la especificación. Es una visión coherente para los cambios a los que se ajusta.

La evidencia de quienes lo practican apunta en sentido contrario para todo lo demás. El informe de Nearform del 24 de junio de 2026 sobre fallos del mundo real enumera «usar SDD para todo» como el modo de fallo 2. Para tareas menores, escribir especificaciones, generar planes y validar resultados puede eclipsar el trabajo mismo. La solución es «ajustar el enfoque a la complejidad de la tarea»: un prompt exhaustivo que contenga una especificación breve, o el modo de planificación, para cambios pequeños; el flujo completo de SDD para los medianos y grandes.

Un informe técnico del 30 de enero de 2026 que examina el campo llega a una conclusión similar: el desarrollo guiado por especificaciones es excesivo para prototipos desechables, proyectos individuales de corta duración, programación exploratoria y operaciones CRUD simples con requisitos evidentes. Su regla de oro es «usar el nivel mínimo de rigor de especificación que elimine la ambigüedad en tu contexto».

La evaluación práctica de Birgitta Böckeler es más directa. Un bug pequeño procesado con Kiro se convirtió en cuatro historias de usuario y dieciséis criterios de aceptación —«matar moscas a cañonazos»— y una funcionalidad de 3–5 puntos procesada con Spec Kit en 2025 produjo tanto markdown para revisar que, en el mismo tiempo, ella pensó que podría haberla implementado con programación asistida por IA sin más y haberse sentido con mayor control.

Nada de esto significa que SDD sea una moda pasajera. Las mismas fuentes señalan beneficios claros: requisitos complejos que las partes interesadas deben validar antes de escribir código, sistemas mantenidos por varias personas, trabajo con muchas integraciones, ámbitos regulados que necesitan trazabilidad y modernización de sistemas heredados donde primero se captura el comportamiento existente en una especificación. La pregunta nunca fue si SDD funciona. Es una pregunta de clasificación: qué cambios lo justifican.

Primero, define la vida útil

La distinción más útil en la literatura sobre SDD es la de Böckeler, del 15 de octubre de 2025, que conservó en su actualización de septiembre de 2026. No trata de herramientas, sino de cuánto tiempo debe vivir una especificación y qué prevalece cuando la especificación y el código discrepan:

De esto se desprenden dos cosas. Primero, en mi interpretación, casi todas las herramientas que se autodenominan SDD son spec-first en la práctica, independientemente de sus aspiraciones. Segundo, spec-anchored es el único nivel en el que las especificaciones anteriores se trasladan a sesiones futuras, y solo mientras se pague el costo de mantenerlas.

La documentación oficial actual de Spec Kit de GitHub (consultada el 29 de octubre de 2026) añade una segunda pregunta relacionada: no solo cuánto tiempo importa la especificación, sino qué ocurre con spec.md, plan.md y tasks.md después de la entrega. El documento sobre persistencia menciona tres modelos:

• flow-back: reflejar los hallazgos aceptados en cualquier artefacto y reconciliarlos.
• flow-forward: las carpetas de funcionalidades completadas son historia inmutable; los nuevos requisitos reciben una carpeta nueva.
• living spec: spec.md sigue siendo el contrato; el plan y las tareas se regeneran como derivados.

Afirma claramente que Spec Kit «deja intencionalmente a los equipos el control» de esta elección, que ninguno es el modelo predeterminado y que los equipos deberían documentar la convención en su constitución o en las notas de incorporación del equipo.

Observa lo que ese documento dice y lo que no dice. No es una aprobación de la clasificación por parte del proveedor: el mismo documento insiste en que los tres modelos «usan el mismo proceso de entrega de funcionalidades» y que la persistencia «no es una forma alternativa de entregar ni de determinar si el trabajo está completo». GitHub mantiene un único flujo de entrega para cada funcionalidad y deja en tus manos la vida útil y la persistencia; decidir si un cambio pasa por el flujo sigue siendo tu responsabilidad. Incluso si solo hablamos de persistencia, un equipo que no ha elegido no ha evitado la decisión: la ha tomado por accidente. Cómo gestionar el feedback en GitHub Spec Kit antes y después de la implementación explica cómo elegir entre los tres modelos. Para completar el panorama del comportamiento actual, al 29 de octubre de 2026, la versión upstream de Spec Kit es v1.2.5. Su comando posterior a la implementación /speckit-converge añade el trabajo omitido a tasks.md en lugar de editar código. Su sistema de flujos de trabajo y extensiones permite mucha más personalización de lo que sugiere la descripción de 2025 de un pipeline fijo. Sigue habiendo una ruta central de entrega, y precisamente por eso la decisión de clasificación te corresponde a ti.

Exploración → Especificación → Entrega

Antes, mi instinto era recurrir a SDD precisamente cuando casi no sabía qué necesitaba hacer. La evidencia sobre modos de fallo indica que eso invierte el orden, y esa corrección reorganizó todo este framework.

El modo de fallo 1 de Nearform es «construir antes de entender el problema»: un equipo sigue el proceso de SDD a la perfección y produce una especificación detallada y una implementación limpia, pero de algo equivocado. «El desarrollo guiado por especificaciones amplifica la claridad, pero en última instancia no evita que construyas lo equivocado… SDD es una herramienta de ejecución, no de exploración, así que úsala solo después de comprender bien lo que estás construyendo». Su modo de fallo 3 afina esa idea para los sistemas agénticos, cuyo comportamiento surge de la interacción: los detalles «solo se aclaran cuando ves el sistema en acción», así que primero crea un prototipo de la experiencia y formalízala después.

La exploración es un problema resuelto fuera de SDD; simplemente no es una especificación. Para conocer las herramientas —mapeo de supuestos, spikes, premortems, decisiones de una o dos vías—, consulta Cómo resolver problemas ambiguos: explorar alternativas, identificar incógnitas y tomar decisiones. El flujo inicial de Spec Kit también puede dar cabida a ese tipo de investigación, como describe Usar GitHub Spec Kit para investigar alternativas antes de construir, con una especificación definitiva escrita solo después de aprobar una dirección. El único elemento que necesita este artículo es el criterio de salida, porque «explorar hasta sentirte cómodo» es la forma en que la exploración se convierte en procrastinación. La disciplina de spikes de James Shore lo proporciona: un spike es un experimento pequeño, generalmente de menos de un día, diseñado para responder una pregunta específica y, «cuando tienes la respuesta, el spike se descarta».

La formulación que uso ahora —mi síntesis, no un estándar citado— es:

La exploración termina cuando ninguna incógnita pendiente cambiaría la forma de la solución. Toda otra incógnita tiene una persona responsable identificada o un supuesto aceptado explícitamente.

Eso le da a la secuencia sus puntos de control:

• Exploración pregunta: ¿qué debería existir y es viable? Los artefactos son desechables: spikes, prototipos, una lista de preguntas abiertas con personas responsables. Todavía no hay una especificación formal.
• Especificación pregunta: ¿qué construiremos exactamente y cómo sabremos que funciona? Objetivos excluidos, criterios de aceptación y restricciones: suficientemente definidos para ejecutar el trabajo. Vale la pena conservar un matiz del caso práctico de Data Dynamics del 17 de junio de 2026: la clarificación no es «para funcionalidades complejas», sino para funcionalidades en las que los humanos dan por sentadas decisiones de forma inconsciente (cantidad de reintentos, backoff, comportamiento ante fallos) que, de otro modo, un agente inventará.
• Entrega plantea: constrúyelo en incrementos pequeños y validados. Revisa la especificación y el plan antes del código, porque un supuesto equivocado de una línea se propaga a la arquitectura y después a decenas de archivos; verifica después, porque quien implementa informa lo que hizo, no lo que omitió.

Y hay un retorno importante: cuando la entrega demuestra que un supuesto es falso, el ciclo vuelve a la exploración, no solo a editar la especificación. Una edición puede registrar una respuesta nueva; no puede decirte que la pregunta cambió. El mismo ciclo permite corregir una clasificación equivocada. Mi regla práctica, que es mi criterio y no un estándar respaldado por una fuente, es subir de nivel cuando la revisión del plan revela un cambio de contrato, datos o autorización que no contemplé al clasificar, y bajar de nivel cuando revisar la especificación cuesta más de lo que costaría revisar el diff.

flowchart TD
    A[Nuevo cambio] --> B{"¿Sabemos qué construir?<br/>Ninguna incógnita cambia la forma"}
    B -- No --> D[Exploración<br/>spike / prototipo / aclarar]
    D --> B
    B -- Sí --> C{Complejidad x irreversibilidad}
    C -- Pequeño y reversible --> P[Prompt + especificación breve<br/>o modo de planificación]
    C -- Mediano-grande y complejo --> S[SDD spec-first<br/>flujo completo]
    C -- Contrato duradero --> L[Spec-anchored<br/>pagar el costo de actualización]
    S --> T[Tareas<br/>incluidas las tareas de promoción]
    L --> T
    P --> V[Entregar + verificar]
    T --> V
    V -- Supuesto refutado --> D
    V -- Terminado --> K["Se cierran las tareas de promoción:<br/>regla / verificación en el camino / ADR-DR /<br/>nota de consulta / eliminación"]

Ajusta el rigor a la complejidad (después de explorar)

La complejidad no es tamaño. Los factores que elevan el nivel de especificación son el acoplamiento con otros sistemas, la cantidad de personas que los mantienen, la superficie de integración, las necesidades regulatorias o de trazabilidad y cualquier novedad que persista después de la exploración. La irreversibilidad es el segundo eje: si un solo revert no puede deshacer el cambio (una migración de datos, un contrato de API publicado, un límite de permisos), trátalo como una decisión de una sola vía, sin importar su tamaño. Un cambio de autorización de veinte líneas es de alta complejidad. Un cambio de nombre mecánico de dos mil líneas es de baja complejidad, pero de gran alcance de impacto; necesita un plan y verificaciones automatizadas, no un documento de requisitos de producto. Para calibrar el rigor según el alcance del impacto dentro de un flujo elegido, consulta La parte humana de GitHub Spec Kit: cómo hablar con los agentes entre comandos. Para conocer en detalle el nivel de cambios pequeños, consulta ¿Cuándo basta un prompt y cuándo necesitan más los agentes de IA?. Para los niveles entre un prompt y el flujo completo, consulta Después del desarrollo guiado por especificaciones: articula siempre, especifica a veces. Esta es la clasificación que uso:

¿Cuánto cuesta el flujo completo cuando lo aplicas donde no corresponde? La respuesta honesta: hay pocas mediciones. La única comparación directa publicada que encontré (una funcionalidad de aplicación de chat, dos ejecuciones, GPT-5.2/Codex, 18 de marzo de 2026) mostró que el pipeline más pesado de Spec Kit usó aproximadamente el doble de tokens que OpenSpec. Sus limitaciones son reales: una sola tarea, ninguna comparación contra el uso de ninguna especificación y ningún dato de tiempo transcurrido. Tómalo como una señal orientativa —los pipelines más pesados consumen más contexto—, no como prueba de que usar niveles ahorra dinero. A octubre de 2026, no encontré ninguna comparación medida y publicada entre un enfoque por niveles y uno uniforme, y yo tampoco he hecho una. Por eso esta tabla de clasificación es una recomendación, no un hallazgo.

Sí existe evidencia cualitativa de equipos. El Technology Radar de Thoughtworks (GitHub Spec Kit, Assess, abril de 2026) informa que algunos equipos —principalmente en sistemas brownfield— encontraron que una constitución útil ayuda a los agentes a operar dentro de los límites arquitectónicos previstos. También informa de dos costos recurrentes. El primero es el exceso de instrucciones que termina degradando el contexto; un equipo lo abordó extrayendo guías reutilizables a skills y manteniendo las instrucciones concisas. El segundo es el markdown excesivamente verboso que aumentaba la carga cognitiva; personalizar plantillas y limitar los archivos generados ayudó a abordar algunos de estos problemas. Observa el patrón de la primera solución: menos en el contexto que siempre se carga, más cargado bajo demanda. Ese patrón vuelve en la siguiente sección, porque ahí está la clave.

Promoción: planifica lo que sobrevive en las propias tareas del cambio

Este es el hallazgo que no esperaba al retirar OpenSpec de este repositorio.

OpenSpec es la herramienta spec-anchored de esta historia: /opsx:sync fusiona las especificaciones delta ADDED/MODIFIED/REMOVED de un cambio en una biblioteca canónica openspec/specs/, y /opsx:archive cierra el cambio completado incorporándolo a ese canon. (La mecánica se explica en OpenSpec vs GitHub Spec Kit: una comparación lado a lado del desarrollo guiado por especificaciones.) Si alguna configuración debía haber trasladado las especificaciones anteriores a sesiones futuras, era esta. Al contrastar el archivo con la realidad:

• De mis dos cambios completados en OpenSpec, uno fue archivado; el otro (con todas las tareas marcadas) nunca lo fue.
• Otros dos cambios entregaron comportamiento mientras sus tareas de verificación seguían abiertas, incluido el cambio de internacionalización al español. Un quinto cambio, el pipeline de resúmenes de audio, no tenía ninguna tarea marcada. OpenSpec se retiró con los tres todavía sin terminar.
• Las tres especificaciones canónicas eran correctas —verifiqué algunos de sus requisitos contra src/ y seguían vigentes—, pero sus campos Purpose todavía dicen «TBD» y, desde el 29 de octubre de 2026, nada las carga.

Esta no es una historia sobre saltarse el costo del archivado. Es retraso del canon: en una herramienta spec-anchored, el comportamiento entregado permanece fuera del canon hasta que el cambio se verifica y se archiva. Siempre que la verificación se retrasa —lo que, en mi experiencia, ocurre siempre que un equipo está ocupado—, el canon describe el sistema tal como estaba en el último momento en que todo quedó ordenado, no como está ahora. El archivado es un paso que puede quedarse atrás; y un paso que puede quedarse atrás terminará haciéndolo.

¿Qué fue lo que realmente trasladó el conocimiento de esos mismos cambios? Las piezas que no necesitaban un paso de archivado porque están en el camino del agente de forma predeterminada. El cambio al español que no se archivó exigía que un archivo suelto en content/articles/ hiciera fallar el build en vez de omitirse silenciosamente. Esa regla vive como prosa en CLAUDE.md —que se carga automáticamente en cada sesión— y como scripts/check-content-layout.mjs, que se ejecuta en cada build. Su regla translatedFrom siguió el mismo camino hacia las instrucciones y check-translation. El modelo de harness engineering de Böckeler de 2026 da nombre a estos elementos: las instrucciones de carga automática son guías (controles anticipativos que orientan antes de que actúe el agente), y las pruebas, los linters y las verificaciones son sensores (controles de retroalimentación que le permiten corregirse después). La promoción más sólida convierte una guía escrita en un sensor computacional; la más débil deja el conocimiento en una carpeta que una sesión futura tendría que abrir por casualidad.

Así que la regla que ahora aplico a cada fragmento de especificación al cerrar un cambio se resume en una pregunta:

¿Esto debe estar en el camino del agente de forma predeterminada o basta con consultarlo bajo demanda?

• En el camino, como prosa: invariantes y convenciones de uso frecuente → CLAUDE.md / constitución. Este presupuesto es limitado: se carga en cada sesión y el exceso de instrucciones es el modo de fallo documentado por el Radar. Extrae los detalles a skills que se carguen bajo demanda.
• En el camino, ejecutable: cualquier cosa que pueda verificarse mecánicamente → un script, una prueba o un control de CI. Prefiere esto a la prosa siempre que la regla pueda volverse determinista; una verificación no se puede pasar por alto al leer.
• Registro de decisión: elecciones arquitectónicamente significativas → ADR (plataforma) o DR (alcance de una funcionalidad). Es un destino de promoción entre varios, no el activo duradero universal que alguna vez supuse que era. (Para patrones de aplicación de ADR, consulta Gobernanza de arquitectura para la generación de código con IA).
• Consulta: detalles de comportamiento que solo importan cuando se modifica esa funcionalidad → una nota mantenida con un mecanismo de consulta identificado (un índice, una skill que dirija a ella o una referencia en una lista de verificación). Una consulta sin mecanismo es un archivo de escritura únicamente; eso fue en lo que se convirtieron mis especificaciones canónicas el día que se retiró la herramienta.
• Eliminar: todo lo demás. La especificación cumplió su función como andamiaje. Eliminarla evita que el siguiente agente confíe en prosa obsoleta por encima del código en ejecución.

Nada de esto es un paso nuevo que haya que recordar. Mis propios artículos anteriores ya prescribían la promoción como parte de la definición de terminado para espacios de trabajo agénticos: «archivar la especificación y promover los ADR antes de cerrar la iniciativa» (Workspaces agénticos: submódulos, skills, conocimiento y entrega guiada por especificaciones). El cambio al español ilustra el mecanismo desde el lado positivo. Es un solo cambio, así que es un caso, no una prueba. Su promoción funcionó porque la actualización de CLAUDE.md y los tres scripts de verificación eran literalmente las tareas 1.4, 1.5, 2.6 y 7.0 del propio cambio. La promoción planificada como tareas se entrega; la promoción que queda como una buena intención se convierte en retraso del canon. Escribe las tareas de promoción cuando escribas las demás tareas, mientras todavía sabes qué fragmentos importan.

La trampa de la obligación

Todo lo anterior también responde la pregunta a nivel de equipo: ¿obligar a usar Spec Kit para todo el desarrollo —como sospecho que hicieron muchos equipos en 2025–26 y como hacía mi propio CLAUDE.md el 29 de octubre de 2026— fue una decisión equivocada tomada demasiado pronto?

Separa la decisión de la política. Como decisión, ante la incertidumbre de 2025 —un término con significado difuso, herramientas que cambiaban cada mes y agentes que necesitaban algunas salvaguardas—, una obligación uniforme aplicada como piloto de aprendizaje de duración limitada era defendible: lenguaje compartido, una superficie de revisión consistente y menos fatiga al tomar decisiones. Laura Tacho le dijo a Birgitta Böckeler en mayo de 2026 que veía «una amplia variedad» de prácticas que todas se llamaban desarrollo guiado por especificaciones, con «poca estandarización»; esperar a que el campo madurara también tenía un costo.

Como política mantenida indefinidamente, falla a la luz de la evidencia anterior. Aplica por decreto el modo de fallo 2. Paga el costo de la ceremonia spec-anchored sin obtener sus beneficios. La señal más reveladora es la ausencia de fecha de revisión y de métricas: sin ninguna de las dos, nada puede demostrar que la política está equivocada. El error nunca fue empezar pronto. Es imponer la obligación sin una reevaluación programada.

La solución es reducir su alcance, no eliminarla: Spec Kit se convierte en la opción predeterminada para trabajo mediano y grande (donde su constitución y sus puntos de control de clarify y converge justifican su uso), con niveles inferiores explícitos, una regla de ADR/DR para cualquier nivel y una fecha de revisión con métricas de tiempo de ciclo, carga de revisión y retrabajo. Los equipos conservan el lenguaje compartido; el trabajo pequeño deja de pagar el costo; y la propia política se vuelve —como una buena especificación— revisable según la evidencia.

La política de clasificación, lista para pegar

Este es el ejemplo práctico: la regla por niveles con la que estoy reemplazando la obligación uniforme de este repositorio. Es la política de un repositorio, ofrecida como punto de partida, no como estándar.

## Spec-Driven Changes (tiered)

Route the change BEFORE starting. When in doubt between two tiers, take the lower one and note why.

- **Discovery** — unknown or emergent behavior: spike, prototype, or explore.
  No spec yet. Exit when no remaining unknown would change the shape of the
  solution; park the rest as named assumptions with owners.
- **Tiny, known, reversible** — one area, no contract/data/auth change:
  prompt or plan mode; truth is the diff plus tests. No spec folder.
- **Medium-large, complex, cross-cutting, or hard to reverse**: full SDD flow
  (specify -> clarify -> plan -> tasks -> analyze -> implement -> converge).
  Tasks MUST include promotion tasks (next bullet).
- **Promotion (planned as tasks, part of definition of done)** — for each
  durable fragment of the spec, decide its home while writing tasks:
  in-path rule (CLAUDE.md/constitution) / executable check or test /
  ADR (platform) or DR (feature) / lookup note with a named lookup mechanism /
  delete as scaffolding. "We will document it later" is not a home.
- **Architecturally significant at any tier**: record the decision (ADR/DR).
- **Spec lifespan**: default spec-first (mark historical or delete after
  delivery). Claim spec-anchored only for named long-lived contracts, and
  name who pays the update tax. Persistence model: <flow-back | flow-forward
  | living spec> for this repo.
- **Policy review date: <YYYY-MM-DD>** (or after N spec'd features, whichever
  first). Review against cycle time, review burden, and rework. Adjust the
  tiers; do not just renew.

Qué estoy cambiando en mi propia configuración

De la clasificación anterior se desprenden tres cambios; al 30 de octubre de 2026 están redactados, pero aún no se han aplicado, y los enumero para asumir mi responsabilidad respecto de la política de este artículo. Primero, la obligación uniforme en CLAUDE.md que envía cada cambio de funcionalidad o de herramientas que no sea un artículo a Spec Kit se convierte en la política por niveles anterior, con una fecha de revisión del 29 de enero de 2027 o al llegar a cinco funcionalidades de Spec Kit, lo que ocurra primero. Segundo, la elección de persistencia se define donde la documentación de GitHub sugiere hacerlo —en la constitución del proyecto—, en lugar de dejarla a la herramienta que tenga instalada en ese momento; mi constitución sigue siendo una plantilla sin completar, lo que muestra qué tan en serio me había tomado mi propia configuración. Tercero, el canon congelado de OpenSpec permanece como registro histórico de solo lectura y explícitamente de consulta, mientras que las reglas que deben llegar a cada sesión viven en CLAUDE.md y en las verificaciones del build, donde, en la práctica, ya estaban haciendo el trabajo.

Ese es todo el argumento en pocas palabras. Las especificaciones son un andamiaje excelente y, en el extremo spec-anchored, contratos reales. Pero el conocimiento sobrevive a las sesiones y a las herramientas en la medida en que está en el camino: se carga de forma predeterminada, se ejecuta en cada build o se encuentra mediante un mecanismo que realmente mantienes. Planifica eso mientras escribes la especificación, asigna a cada cambio el rigor que justifica y deja que el resto sea andamiaje que puedes desechar.

Fuentes

• Birgitta Böckeler, “Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl,” 15 de octubre de 2025: https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html — spec-first/spec-anchored/spec-as-source, las observaciones sobre el uso excesivo para un bug pequeño y una funcionalidad de 3–5 puntos, especificación frente a banco de memoria.
• Birgitta Böckeler, “Understanding Spec-Driven-Development” (versión actualizada de la autora), última actualización septiembre de 2026: https://birgitta.info/posts/spec-driven.html — vidas útiles conservadas; spec-as-source y el paralelismo con el desarrollo guiado por modelos.
• Birgitta Böckeler, “Harness engineering for coding agent users,” 2 de abril de 2026: https://martinfowler.com/articles/harness-engineering.html — guías (controles anticipativos) frente a sensores (retroalimentación); controles computacionales frente a inferenciales.
• Alfonso Graziano (Nearform), “Lessons from real-world failures using spec-driven development,” 24 de junio de 2026: https://nearform.com/insights/lessons-from-real-world-failures-using-spec-driven-development/ — modos de fallo 1–5, incluidos «SDD es una herramienta de ejecución, no de exploración» y «usar SDD para todo».
• Deepak Babu Piskala, “Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants,” 30 de enero de 2026: https://arxiv.org/abs/2602.00180 — el espectro de especificación, §VIII sobre cuándo usarlo y la lista de casos en que es excesivo, «nivel mínimo de rigor de especificación que elimine la ambigüedad».
• Thoughtworks Technology Podcast, “What is spec-driven development?” (Böckeler con Laura Tacho), 28 de mayo de 2026: https://www.thoughtworks.com/insights/podcasts/technology-podcasts/what-is-spec-driven-development — difusión semántica y ausencia de estandarización ocho meses después.
• Thoughtworks Technology Radar, “GitHub Spec Kit” (Assess), 15 de abril de 2026, y Vol. 34 (abril de 2026): https://www.thoughtworks.com/radar/languages-and-frameworks/github-spec-kit — informes de equipos: constitución útil, exceso de instrucciones y degradación del contexto, markdown verboso y personalización de plantillas.
• GitHub, repositorio de Spec Kit — spec-driven.md («mantener software significa hacer evolucionar las especificaciones»), docs/concepts/spec-persistence.md (flow-back/flow-forward/living spec; sin modelo predeterminado; documentar la convención en la constitución o en las notas de incorporación del equipo), templates/commands/converge.md y CHANGELOG.md (v1.2.5, 28 de octubre de 2026). Consultado el 29 de octubre de 2026: https://github.com/github/spec-kit
• Michael Nygard, “Documenting Architecture Decisions,” 15 de noviembre de 2011: https://www.cognitect.com/blog/2011/11/15/documenting-architecture-decisions — alcance y formato de los ADR.
• James Shore, “Spike Solutions,” The Art of Agile Development: https://www.jamesshore.com/v2/books/aoad2/spike_solutions — los spikes responden una pregunta y se descartan.
• Jamie Telin, “Spec Driven Development Is Wasting Tokens,” 18 de marzo de 2026: https://medium.com/it-chronicles/is-your-safe-choice-burning-your-budget-1cfddf8782e4 — comparación de tokens para una sola tarea (57,740 OpenSpec frente a 120,947 Spec Kit; segunda ejecución 91,729 frente a 181,040); citada en el texto con sus limitaciones.
• Evidencia local (este repositorio, verificada el 29 de octubre de 2026): docs/legacy-openspec/changes/*/tasks.md (estados de finalización y archivado), docs/legacy-openspec/specs/ (tres especificaciones canónicas), CLAUDE.md (obligación Spec-Driven Changes; regla de estructura de artículos), scripts/check-content-layout.mjs, scripts/check-locale-parity.mjs y scripts/check-translation.mjs (controles de build).
• Data Dynamics, “[Spec Kit Part 7] In Practice — Building a Data Quality Monitoring Service with SDD (Retrospective),” 17 de junio de 2026: https://data-dynamics.io/en/blog/spec-kit-case-study — caso práctico de la empresa sobre un solo proyecto; aportó la observación sobre clarify en el texto; tratado como anécdota, no como dato (el propio autor califica sus cifras como ilustrativas).