Ingeniería de procesos
Desarrollo guiado por especificaciones con IA
Con un agente que escribe código en segundos, el cuello de botella deja de ser programar y pasa a ser decidir qué hay que construir. El desarrollo guiado por especificaciones (SDD, *spec-driven development*) pone ese «qué» por escrito antes del código y lo convierte en la fuente de verdad.
El problema que resuelve
El *vibe coding* («pídeselo y a ver qué sale») sirve para un prototipo. En un proyecto que dura, sin especificación pasa esto:
- Cada sesión, el agente reinterpreta qué querías.
- Los cambios rompen lo que ya funcionaba y nadie lo nota.
- Nadie sabe qué está hecho, qué falta y por qué se decidió algo.
Las cuatro piezas
1. La constitución
Un documento corto con las reglas que mandan sobre todo: principios, restricciones y lo que nunca se hace. El agente lo lee siempre.
2. Las specs
Una especificación por pantalla, módulo o servicio: para qué existe, qué datos usa y una lista de requisitos con identificador, estado y evidencia.
### RQ-FAC-003 · Avisar de las facturas vencidas
- **Estado:** pendiente | implementado
- **Qué hace:** cada lunes lista las facturas con más de 30 días sin cobrar y envía el resumen al responsable.
- **Evidencia:** src/facturas/vencidas.js, pruebas/vencidas.test.js
- **Se comprueba:** con una factura de hace 31 días, aparece en el resumen.3. Los cambios
Para un cambio grande, antes del código va un documento de cambio: qué molesta hoy, qué tendría que pasar, cómo sabremos que funciona, qué toca, qué decidimos no hacer y los riesgos. De ahí salen los requisitos nuevos, que entran como «pendiente».
4. La comprobación automática
Un pequeño programa revisa que cada requisito «implementado» cite ficheros que existen y que su prueba pase. Si alguien (o el agente) marca algo como hecho sin evidencia, la comprobación falla.
El flujo de trabajo con un agente
- Escribes o actualizas la spec y dejas el requisito como «pendiente».
- Pides al agente que lo implemente cumpliendo la spec y con pruebas.
- El agente ejecuta las pruebas y la comprobación de specs.
- Revisas el cambio y lo ves funcionando.
- El requisito pasa a «implementado» con su evidencia.
Lee specs/CONSTITUCION.md y specs/modulos/facturas.md. Implementa RQ-FAC-003 tal como está escrito. Primero dime qué ficheros tocarás y cómo lo probarás. Escribe primero la prueba, después el código, y ejecuta las pruebas y la comprobación de specs. No marques el requisito como implementado hasta que todo pase.Herramientas de SDD
| Herramienta | Qué es | Para quién |
|---|---|---|
| GitHub Spec Kit (se abre en otra pestaña) | Plantillas y comandos para especificar, planificar y descomponer en tareas, compatible con más de 20 agentes | Equipos que quieren un método estándar y portable |
| Kiro (se abre en otra pestaña) | Editor que genera requisitos, diseño y tareas antes del código | Quien prefiere todo integrado en un editor |
| AGENTS.md (se abre en otra pestaña) | Formato abierto de instrucciones para agentes | Cualquier proyecto con agentes |
| Ficheros propios (CLAUDE.md, specs/) | Tu constitución y tus specs en Markdown, con un comprobador sencillo | Quien quiere el máximo control con lo mínimo |
Un ejemplo real
Esta misma web sale de una incubadora que trabaja así: una constitución, una spec por pantalla con requisitos numerados, documentos de cambio para lo grande y un comprobador que falla si un requisito «implementado» no tiene evidencia. El agente lee las reglas al empezar y deja todo en el estado correcto al terminar. En el kit tienes las plantillas que usamos.
Cuándo no merece la pena
Para un script de una tarde o un prototipo que vas a tirar, no. A partir de que un proyecto dure semanas, tenga usuarios o lo toque más de una persona (o más de un agente), sí.
Fuentes
- GitHub Spec Kit (se abre en otra pestaña)
- Comparativa de Spec Kit, Kiro y flujos con Claude Code (se abre en otra pestaña)
- AGENTS.md (se abre en otra pestaña)
Siguiente guía: Del vibe coding a programar con IA en serio