Desarrollo dirigido por especificación (SDD)
Enfoque de desarrollo en el que una especificación explícita, revisable y verificable guía la planificación, la implementación y las pruebas, en lugar de que el agente infiera el trabajo entero a partir de un solo prompt. Es la respuesta de ingeniería al límite del Vibe coding.
La diferencia con un documento de requisitos tradicional es que la especificación no es estática: es una fuente de verdad viva y versionada de la que se generan planes, código, pruebas y evidencia de revisión.
La especificación se convierte en el contrato operativo compartido entre la persona y el agente.
La cadena
intención → especificación → plan → código → evidencia
Artefactos aprobados por humanos van acotando progresivamente qué significa «terminado».
Por qué hace falta
A medida que sube la autonomía del agente, la ambigüedad se convierte en el cuello de botella. Los seis modos de fallo que enumera el curso: intención ambigua (supuestos ocultos sin resolver), deriva de contexto entre sesiones y agentes, optimización local (código que funciona pero viola la arquitectura), completitud débil («parece correcto» no demuestra que se cumplan todos los requisitos), brecha de mantenimiento (nadie puede reconstruir después por qué se decidió así) y cambio sin límites.
Cuanto más capaz es el agente, mayor es la palanca — y mayor el coste de una intención mal entendida.
La pila de especificación
| Capa | Qué fija |
|---|---|
| Constitución | Principios de ingeniería no negociables: estándares, gobernanza, calidad |
| Especificación | Qué necesitan los usuarios y cómo se observa el éxito: escenarios, requisitos, aceptación |
| Plan técnico | Cómo satisfará el sistema la especificación: arquitectura, interfaces, riesgos |
| Tareas | Unidades ejecutables acotadas, con dependencias, propiedad y secuencia |
| Evidencia | Prueba de que lo implementado coincide con la intención: pruebas, revisión, trazabilidad |
Es un bucle, no un traspaso
Especificar → clarificar → planificar → dividir en tareas → implementar → validar, y de vuelta. Implementar genera aprendizaje, y ese aprendizaje puede cambiar el plan o la propia especificación.
Vibe coding frente a SDD
| Dimensión | Vibe coding | SDD |
|---|---|---|
| Objetivo | Descubrir qué podría funcionar | Entregar lo que debe funcionar |
| Superficie de control | La conversación y lo que se ve salir | Artefactos versionados y criterios de aceptación |
| Encaje | Prototipo, aprendizaje, herramienta personal | Sistema de equipo, producción, trabajo regulado |
| Modo de fallo | Supuestos ocultos y deriva | Documentación obsoleta o sobreespecificada |
En el curso
No aparece en el material de los módulos: es aportación de las sesiones en directo.
- Welcome Webinar — la presentación Spec-Driven Development: From Vibes to Engineering de John Williams y Abel Sanchez, donde se desarrolla completo, con el reparto del trabajo cognitivo entre persona y agente.
- Sara Artigas, sesión 2 — con su ciclo de seis pasos y las tres propiedades que aporta: alineación, trazabilidad y control.
- Sandra Ortiz, sesión 2 — la versión práctica: «congelar el diseño en una especificación antes del código».
- Hitachi es el caso que lo respalda con cifras.
El vibe coding sube el suelo. La ingeniería agéntica sube el techo. El SDD es el mecanismo de coordinación entre ambos.
Relacionado
Harness engineering · Vibe coding · Ingeniería de prompts · Pruebas adversarias · Human-in-the-loop
Referencias
Enlaces entrantes
- Curso IA Agéntica (MOC)Índice
- Habilidad de agente (SKILL.md)Concepto
- Harness engineeringConcepto
- OH Sandra OrtizSesión
- OH Sara ArtigasSesión