---
title: "Spec-Driven Development"
type: "architectural-pattern"
slug: "spec-driven-development"
url: "http://localhost:3000/es/architectural-patterns/spec-driven-development.md"
also_known_as: "SDD"
description: "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."
languages: ["typescript"]
---
# 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

* 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.
## Relations

**Related patterns**

- [Desarrollo guiado por pruebas](/es/architectural-patterns/test-driven-development.md)

## Code Examples

### typescript

```typescript
// La especificación es la fuente de verdad: escenarios como datos.
export const slugifySpec = {
  name: 'slugify',
  cases: [
    { input: 'Hello World', expected: 'hello-world' },
    { input: 'A  B', expected: 'a-b' },
  ],
}

// Prueba de conformidad derivada de la especificación: la implementación debe satisfacerla.
for (const c of slugifySpec.cases) {
  test(`${slugifySpec.name}(${c.input})`, () => {
    expect(slugify(c.input)).toBe(c.expected)
  })
}
```