Sigue la presentación

spec-driven-development.pages.dev

Spec-Driven Development

De la cascada al vibe coding y de vuelta a las specs

Foto: Kiban — CC BY-SA 3.0 / Wikimedia Commons

BETA

Prehistoria

El SDLC antes de la IA

Idea → Lanzamiento, a la vieja usanza

flowchart LR
  I@{ icon: "lucide:lightbulb", form: "circle", label: "Idea", pos: "b", h: 50 }
  R@{ icon: "lucide:clipboard-list", form: "square", label: "Requisitos", pos: "b", h: 40 }
  D@{ icon: "lucide:palette", form: "square", label: "Diseño y prototipo", pos: "b", h: 40 }
  Impl@{ icon: "lucide:code", form: "square", label: "Implementación", pos: "b", h: 40 }
  AT@{ icon: "lucide:flask-conical", form: "square", label: "Pruebas automatizadas", pos: "b", h: 40 }
  U@{ icon: "lucide:clipboard-check", form: "square", label: "UAT", pos: "b", h: 40 }
  Dep@{ icon: "lucide:server", form: "square", label: "Despliegue", pos: "b", h: 40 }
  Rel@{ icon: "lucide:rocket", form: "circle", label: "Lanzamiento", pos: "b", h: 50 }
  I --> R --> D --> Impl --> AT --> U --> Dep --> Rel
  class R,U pm
  class D designer
  class Impl,AT,Dep engineer
  classDef pm fill:#eef0ff,color:#111928,stroke:#788cfc
  classDef designer fill:#fdf2f8,color:#111928,stroke:#c084fc
  classDef engineer fill:#def7ec,color:#111928,stroke:#25b51f
  • Idea → Requisitos — «lo reconoceré cuando lo vea» se convierte en un PRD de 40 páginas que nadie lee
  • Requisitos → Diseño — el diseñador interpreta sin todo el contexto; las suposiciones se cuelan en los mockups
  • Diseño → Implementación — el ingeniero abre Figma y pregunta «…¿qué pasa cuando no hay datos?»
  • Implementación → Pruebas automatizadas — CI/CD detecta regresiones y bugs en cada commit — pero no puede detectar carencias en los requisitos
  • Pruebas automatizadas → UAT — el happy path pasa; los casos límite se escapan del recorrido
  • UAT → Despliegue — cada arreglo invita a otro; los plazos se escurren en silencio
  • Despliegue → Lanzamiento — pipeline en verde, stakeholders en rojo: «no era eso lo que quería»

La era del vibe coding

Prompt → generar → enviar

Qué es

flowchart LR
  I@{ icon: "lucide:lightbulb", form: "circle", label: "Idea", pos: "b", h: 50 }
  P@{ icon: "lucide:message-square", form: "square", label: "Prompt", pos: "b", h: 40 }
  G@{ icon: "lucide:sparkles", form: "square", label: "Generar", pos: "b", h: 40 }
  S@{ icon: "lucide:rocket", form: "circle", label: "Enviar", pos: "b", h: 50 }
  I --> P --> G --> S
  class P human
  class G ai
  classDef human fill:#e0e7ff,color:#111928,stroke:#6366f1
  classDef ai fill:#fef3c7,color:#111928,stroke:#f59e0b

Vibe coding = prompt → generar → enviar, hecho por una persona en tiempo real. Sin traspasos, sin spec formal, sin puerta de revisión.

Pros

  • Velocidad relámpago — código funcionando en minutos, no en sprints
  • Barrera de entrada baja — no se requieren conocimientos de programación
  • Democratizado — PMs, diseñadores y no-devs pueden prototipar directamente
  • Ideal para prototipos y proyectos personales — el código desechable está bien
  • Experimentación barata — prueba tres enfoques en una hora

Contras

  • Un solo contribuidor a la vez — el contexto vive en una única ventana de chat
  • QA manual — sin pruebas automatizadas; cada cambio se verifica a mano
  • Preocupaciones de seguridad — la IA puede alucinar patrones inseguros
  • No determinista — mismo prompt, otro día, otro resultado
  • Complejidad oculta — código que «funciona» pero que nadie entiende
  • Vendor lock-in — código, prompts y flujo de trabajo viven dentro de un solo SaaS

El tradeoff

Brillante para prototipos individuales y exploración de una sola persona.

Hostil con los equipos, la longevidad y cualquier cosa que deba ser confiable.

Spec-Driven Development

Escribe el plan antes que el código

Spec-Driven Development

Escribe un plan de implementación detallado y revisable antes de escribir código.

flowchart LR
  I@{ icon: "lucide:lightbulb", form: "circle", label: "Idea", pos: "b", h: 50 }
  R@{ icon: "lucide:clipboard-list", form: "square", label: "Requisitos", pos: "b", h: 40 }
  Gen@{ icon: "lucide:sparkles", form: "square", label: "Generar", pos: "b", h: 40 }
  Proto@{ icon: "lucide:mouse-pointer-click", form: "square", label: "Prototipo interactivo", pos: "b", h: 40 }
  V@{ icon: "lucide:check-circle", form: "square", label: "Validar", pos: "b", h: 40 }
  I --> R --> Gen --> Proto --> V
  V -->|Refinar| R
  class R,Proto pm
  class V stakeholder
  class Gen ai
  classDef pm fill:#eef0ff,color:#111928,stroke:#788cfc
  classDef ai fill:#fef3c7,color:#111928,stroke:#f59e0b
  classDef stakeholder fill:#ccfbf1,color:#111928,stroke:#14b8a6
Listo ↓
flowchart LR
  Spec@{ icon: "lucide:file-text", form: "square", label: "Spec", pos: "b", h: 40 }
  Plan@{ icon: "lucide:list-checks", form: "square", label: "Tickets del plan", pos: "b", h: 40 }
  Impl@{ icon: "lucide:code", form: "square", label: "Implementar", pos: "b", h: 40 }
  AT@{ icon: "lucide:flask-conical", form: "square", label: "Pruebas automatizadas", pos: "b", h: 40 }
  U@{ icon: "lucide:clipboard-check", form: "square", label: "UAT", pos: "b", h: 40 }
  Ship@{ icon: "lucide:rocket", form: "circle", label: "Enviar", pos: "b", h: 50 }
  Spec --> Plan --> Impl --> AT --> U --> Ship
  class Spec,U pm
  class Plan ai
  class Impl,AT,Ship engineer
  classDef pm fill:#eef0ff,color:#111928,stroke:#788cfc
  classDef engineer fill:#def7ec,color:#111928,stroke:#25b51f
  classDef ai fill:#fef3c7,color:#111928,stroke:#f59e0b

La spec es la fuente de la verdad

  • Los PMs la escriben — un documento, iterado con los stakeholders, antes de que empiece ingeniería
  • Los stakeholders la leen — y la aprueban antes de que exista el código
  • Los ingenieros la leen — cada ticket enlaza con una decisión documentada
  • Los agentes de IA la leen — la estructura elimina las alucinaciones y la deriva

Cómo — product_trego

Workspace de investigación de PM para TREGO.

frontend/ y backend/ viven como submódulos de git de solo lectura

Las skills de Claude impulsan el bucle SDD.

product_trego/
├── CLAUDE.md                       # reglas: audiencia = PM, submódulos de solo lectura
├── frontend/                       # submódulo git → pandago-saas (solo lectura)
├── backend/                        # submódulo git → smart-delivery-backend
├── prototypes/                     # worktrees con nombre desde origin/dev
│   ├── 8081-dashboard-redesign/
│   ├── 8082-live-ops-dashboard/
│   └── …
├── prototypes.json                 # registro de sandboxes activos
└── .claude/skills/
    ├── prd/                        # PRD a partir del código real + estrategia en Notion
    ├── prototype-create/           # levanta un sandbox aislado desde origin/dev
    ├── prototype-start / -stop / -list/
    ├── frontend-feature-map/       # investigación: pantallas, roles
    ├── frontend-user-flow/         # investigación: flujos paso a paso
    ├── backend-data-model/         # investigación: entidades, ciclos de vida
    ├── backend-tech-stack/         # investigación: deps, env, terceros
    ├── sync-submodules/            # trae lo último, resumen en lenguaje de PM
    ├── git-buddy/                  # narra cada comando de git
    └── setup-mcp-linear-notion/    # conecta ticketing + docs (OAuth)

Demo

Pros y contras

Pros

  • Alineamiento — todos acuerdan el qué antes que el cómo
  • Revisable — desarrolladores y PMs revisan el plan, no solo el código
  • Trazable — cada ticket enlaza con una decisión en la spec
  • Escalable con IA — los agentes de IA ejecutan sobre una spec bien estructurada
  • Elimina las malas ideas pronto — descarta propuestas defectuosas antes de la implementación
  • Mejor calidad — una spec bien elaborada produce mejor resultado

Contras

  • Inversión inicial — escribir una buena spec lleva tiempo
  • Requiere disciplina — saltarse la spec anula el propósito
  • Conocimiento técnico mínimo — el vibe coding DIY requiere algo de nivel técnico básico
  • No tan rápido como el vibe coding — la planificación previa cambia velocidad por estructura

Gracias.

Especifícalo. Constrúyelo. Envíalo.