SDD, OpenSpec y context engineering: ¿en qué se diferencian?
Context engineering decide qué información llega al modelo; SDD es el acuerdo de equipo sobre dónde viven las specs y cómo se verifican; OpenSpec es un framework que concreta cada paso. Así encajan.
El punto de confusión
Tres términos aparecen juntos en cualquier conversación sobre desarrollo con IA: context engineering, Spec-Driven Development y OpenSpec. Se usan casi como sinónimos, y eso genera confusión: ¿adoptar OpenSpec es hacer SDD? ¿Hacer context engineering ya es hacer SDD?
No son lo mismo: son tres niveles distintos que se apoyan unos en otros.
Cuatro conceptos, cuatro niveles
| Concepto | Qué es | Nivel |
|---|---|---|
| Context engineering | Decidir qué información llega al modelo, cuándo y con qué prioridad | Técnica |
| Spec-Driven Development | Acuerdo de equipo: todo desarrollo parte de specs organizadas, compartidas y verificables | Metodología |
| OpenSpec (o Spec Kit, BMAD…) | Framework que concreta cada fase con comandos y artefactos | Framework |
| Flavor propio (reglas del equipo) | Las convenciones exclusivas del producto que se añaden encima del framework | Harness del equipo |
En el fondo, SDD es un contrato: el equipo acuerda que las reglas están aquí, las specs allí, y nadie las mueve porque "parece más cómodo" o porque ha salido una versión nueva. Ese contrato incluye también cómo se observa, se valida, se mantiene y se modifica, y cómo se deja evidencia de que el trabajo se hizo correctamente.
OpenSpec: la lupa sobre cada fase
Cualquier metodología SDD comparte tres fases genéricas: planificar, ejecutar y validar. Un framework como OpenSpec pone la lupa dentro de cada una y la convierte en comandos concretos:
- Planificar: explore + propose
- Ejecutar: apply (ejecución trazable)
- Validar: verify + archive (tantos sensores como hagan falta)
Una diferencia práctica importante: los comandos del framework se actualizan cuando actualizas el framework, mientras que las reglas propias del equipo (su flavor) hay que mantenerlas a mano. Por eso conviene tenerlas separadas y saber en todo momento cuáles son de cada tipo.
Implicaciones prácticas
Con SDD, el foco se desplaza del código al "antes" y al "después": una imagen clara de lo que tiene que pasar antes de ejecutar y de lo que tiene que haberse conseguido después, accesible para todo el equipo. Eso cambia también la forma de medir: el burndown clásico deja de ser la referencia cuando la ejecución la hace un agente, y los roles que siguen la velocidad del equipo tienen que adoptar métricas nuevas.
Hay además un equilibrio que mantener: los copilots cambian cada semana dónde esperan los ficheros (commands, skills, rules). Mantenerse al día es necesario, pero si cada semana se reorganiza todo, el equipo acaba siendo "un movedor de ficheros". Hay que elegir un framework, quedarse con él y adoptar solo los cambios que aportan valor.
Resumen rápido
- Context engineering es la técnica: decidir qué información llega al modelo, cuándo y con qué prioridad.
- SDD es la metodología: un contrato de equipo sobre dónde viven las specs y cómo se verifican.
- OpenSpec es un framework: concreta planificar, ejecutar y validar en comandos; tus reglas propias van encima y se mantienen a mano.
¿Quieres aplicar esto en tu equipo?
En Kuuli Technologies llevamos estas metodologías a equipos reales. Escríbenos si quieres una sesión de trabajo o una consultoría sobre agentes IA y SDD.