ConstructiCat Logo
CodeBust.
Browse section ▾

Spec-Driven Development.

Also known as — SDD

Escribe primero una especificación explícita y autoritativa y, a partir de ella, dirige la implementación, las pruebas y el código generado, manteniendo la especificación como única fuente de verdad.

##Intent

Convierte una especificación precisa en el artefacto principal del desarrollo. La implementación, las pruebas e incluso el código generado por IA se derivan de la especificación y se verifican contra ella, en lugar de que la especificación sea un documento desechable escrito antes del trabajo "de verdad".

##Problem

Los requisitos suelen vivir en la cabeza de las personas, en hilos de chat o en documentos obsoletos. La implementación se aleja de la intención y, cuando lo hace, no hay ninguna referencia autoritativa que zanje qué debería hacer el sistema.

Esto duele más con la programación asistida por IA: un prompt vago produce código de apariencia plausible que puede no coincidir con lo que de verdad se quería, y no hay nada concreto contra lo que comprobarlo.

##Solution

Captura el comportamiento previsto en una especificación clara y versionada (escenarios, criterios de aceptación y contratos) y trátala como la fuente de verdad. Genera o guía la implementación (a menudo con asistencia de IA) a partir de la especificación, deriva pruebas de conformidad de esa misma especificación y verifica la implementación contra ellas.

Cuando el comportamiento deba cambiar, cambias primero la especificación y dejas que la implementación y las pruebas la sigan. Lo que el equipo revisa y discute es la especificación, no el código.

##Structure

  • Especificación: intención, escenarios, criterios de aceptación y contratos/esquemas, mantenidos bajo control de versiones.
  • Generación / implementación: código producido o guiado para satisfacer la especificación.
  • Pruebas de conformidad: comprobaciones derivadas de la especificación que la implementación debe superar.
  • Bucle de retroalimentación: las discrepancias actualizan la especificación, que vuelve a dirigir el código y las pruebas.

##Applicability

  • Úsalo para el desarrollo asistido por IA, donde una especificación precisa convierte un prompt vago en una intención verificable.
  • Úsalo para APIs contract-first, la coordinación entre varios equipos y los sistemas regulados o auditables.
  • Evita las especificaciones pesadas para scripts diminutos o spikes exploratorios, donde cuestan más de lo que aportan.

##How to Implement

  1. Escribe la especificación: intención, escenarios concretos, criterios de aceptación y cualquier contrato o esquema.
  2. Revísala con las partes interesadas: aquí es donde se resuelven los desacuerdos.
  3. Deriva pruebas de aceptación / conformidad a partir de los escenarios.
  4. Implementa para satisfacer la especificación, con frecuencia con asistencia de IA guiada por la especificación.
  5. Ejecuta las pruebas de conformidad; trata los fallos como errores o como señales para refinar la especificación.
  6. Mantén la especificación como autoridad: actualízala primero cada vez que cambie el comportamiento.

##Pros & Cons

Pros
  • Una única fuente de verdad revisable mantiene la intención explícita.
  • Encaja de forma natural con la generación de código por IA, convirtiendo los prompts en contratos verificables.
  • La conformidad puede comprobarse automáticamente, reduciendo la deriva.
  • Las decisiones se debaten sobre la especificación, antes de escribir código.
Cons
  • Esfuerzo inicial real para escribir y mantener la especificación.
  • Las especificaciones se pudren y confunden si no se mantienen sincronizadas con la realidad.
  • Las herramientas y convenciones aún están madurando.
  • Sobreespecificar puede ser tan perjudicial como subespecificar.