Spec-Driven Development: darle memoria y dirección a los agentes de IA

Wed, 23 Sep 2026 00:00:00 +0000

Los agentes LLM escriben código con una velocidad sorprendente. También olvidan con una velocidad sorprendente. Una conversación puede contener decisiones importantes y, sin embargo, esas decisiones se pierden cuando cambia la sesión, el modelo, la persona que mantiene el proyecto o simplemente el contexto que cabe en la ventana del agente.

Ahí aparece el Spec-Driven Development (SDD), o desarrollo dirigido por especificaciones. La idea es sencilla: antes de pedir código, se escribe qué queremos construir, por qué, qué límites debe respetar y cómo sabremos que está bien. Esa especificación deja de ser un documento efímero y se convierte en un contrato de trabajo que pueden leer el equipo y los agentes.

Especificar es construir memoria

Un prompt dice: “añade autenticación”. Una especificación dice qué usuarios existen, qué pueden hacer, qué ocurre cuando fallan, qué datos no deben filtrarse y qué escenarios deben pasar. La diferencia no es solo de longitud: es la diferencia entre una intención momentánea y un contexto que puede sobrevivir meses.

Para que un agente pueda trabajar en el largo plazo conviene conservar, como mínimo:

el objetivo y el problema que se quiere resolver;
historias de usuario y escenarios de aceptación;
restricciones funcionales, de seguridad, rendimiento y accesibilidad;
decisiones técnicas y sus motivos;
una lista de tareas pequeñas, verificables y ordenadas;
el estado de lo implementado y las comprobaciones que siguen pendientes.

El agente puede proponer la primera versión, pero la responsabilidad de revisar si describe el producto correcto sigue siendo humana. La especificación no elimina la conversación: la hace acumulativa.

Un flujo SDD práctico

Un ciclo razonable separa cuatro preguntas:

Especificar: ¿qué problema resolvemos y para quién?
Planificar: ¿qué diseño y decisiones técnicas permiten resolverlo dentro de las restricciones?
Descomponer: ¿qué tareas independientes puede ejecutar y verificar el agente?
Implementar y comprobar: ¿el código satisface los escenarios y sigue respetando la especificación?

Cuando aparece nueva información, se actualiza la especificación y se vuelve a planificar. No se trata de imponer una cascada rígida: se trata de que el cambio quede registrado y no dependa de que alguien recuerde una conversación antigua.

Spec Kit

Spec Kit es el toolkit de código abierto de GitHub para este enfoque. Su flujo propone pasar de /specify a /plan, /tasks y /implement, con artefactos Markdown que proporcionan contexto estructurado al agente. También incluye comandos para establecer principios del proyecto, aclarar ambigüedades y analizar la coherencia de los artefactos.

Un arranque típico se parece a esto:

/specify Describe el problema, los usuarios y los escenarios
/clarify Resuelve las preguntas que hayan quedado abiertas
/plan Elige la arquitectura y las decisiones técnicas
/tasks Convierte el plan en tareas verificables
/implement

Su punto fuerte es hacer explícita la transición entre intención, diseño y ejecución. Es especialmente útil cuando el repositorio tiene varias reglas, cuando participan varios agentes o cuando queremos que el trabajo futuro pueda reanudarse leyendo los archivos del proyecto.

OpenSpec

OpenSpec se presenta como un framework ligero y configurable para crear y mantener especificaciones. Su flujo actual gira alrededor de /opsx:explore, /opsx:propose, /opsx:apply, /opsx:verify y /opsx:archive: primero se entiende el problema y el código existente, después se redactan una propuesta, requisitos, diseño y tareas, y finalmente se implementa, verifica y archiva el cambio.

/opsx:explore
/opsx:propose añade una preferencia de tema
/opsx:apply
/opsx:verify
/opsx:archive

La diferencia de énfasis es interesante: Spec Kit ofrece una secuencia muy clara de artefactos para pasar de la idea a la implementación; OpenSpec pone mucho peso en mantener los cambios, verificar que la implementación coincide con la especificación y trabajar sobre proyectos existentes. Ambos persiguen lo mismo: que el agente no improvise el producto a partir de una instrucción aislada.

Ventajas de trabajar así

Continuidad: un agente nuevo puede retomar el trabajo leyendo la especificación, sin reconstruir toda la historia desde cero.
Menos ambigüedad: los escenarios de aceptación obligan a concretar qué significa “terminado”.
Mejor delegación: las tareas pequeñas y ordenadas son más fáciles de asignar, revisar y repetir.
Revisiones más útiles: se puede comparar el código con una intención escrita, no solo con una conversación.
Menos deriva: los cambios de alcance, las restricciones y las decisiones quedan visibles para todo el equipo.
Mayor portabilidad: el conocimiento del proyecto no queda encerrado en un proveedor, un IDE o una sesión de chat.
Aprendizaje acumulativo: las especificaciones, decisiones y verificaciones forman memoria operativa del sistema.

Hay un coste: escribir y mantener especificaciones requiere disciplina. Un documento obsoleto puede desorientar tanto como la ausencia de documentación. Por eso la especificación debe ser breve cuando el problema es pequeño, revisarse junto con el código y eliminar ceremonias que no aporten claridad.

Otros proyectos para explorar

El ecosistema está creciendo y no hay una única forma correcta de practicar SDD. Merece la pena comparar Kiro, que organiza el trabajo alrededor de requisitos, diseño y tareas; The BMAD Method, un framework abierto con agentes y roles especializados para distintas fases del ciclo; SpecD, que trata especificaciones, cambios y hooks como conceptos de primera clase; y Tessl, que explora un enfoque en el que la especificación tiene un papel todavía más central que el código.

También son buenas lecturas el repositorio de ejemplos y herramientas de Spec Kit y el artículo de GitHub sobre desarrollo dirigido por especificaciones con IA. Conviene comprobar siempre la documentación actual: los comandos, integraciones y niveles de madurez de estos proyectos cambian deprisa.

La regla de oro

Un agente LLM no necesita que le repitamos infinitamente el mismo contexto: necesita que lo convirtamos en un artefacto consultable, versionado y revisable. Especificar no es escribir burocracia antes de programar. Es decidir qué memoria queremos dejarle al siguiente agente —o a nuestro yo de dentro de seis meses— para que pueda continuar sin adivinar.

La última palabra sigue siendo humana: revisar la especificación, comprobar el código y validar el comportamiento real. Pero, cuando el proyecto dura más que una sesión de chat, trabajar sin una especificación es pedirle al agente que construya con amnesia.

Inteligencia Artificial el josiete.com