SDD con OpenSpec y ClaudeCode

Aprenderemos sobre SDD – Spec Driven Development instrumentalizado sobre OpenSpec. Haremos un primer acercamiento usando ClaudeCode con Sonnet, para luego, en un artículo posterior pasarnos a la versión gratuita de OpenCode con Gemma4
SDD con OpenSpec y ClaudeCode para hacer la web de una tabla periódica

Aprenderemos sobre SDD – Spec Driven Development instrumentalizado sobre OpenSpec. Haremos un primer acercamiento usando ClaudeCode con Sonnet, para luego, en un artículo posterior pasarnos a la versión gratuita de OpenCode con Gemma4

Índice de contenidos

1. Introducción a Spec Driven Development (SDD)

No hará ni seis meses que escuché el término SDD y realmente es un cambio de paradigma. La idea es desarrollar a través de las especificaciones. Si, sí. Eso está muy guay, pero todos fuimos a la universidad, estudiamos precondiciones, invariante, postcondiciones, etc… Lo cierto es que es un poco más complejo. Tú le dices a la IA lo que quieres hacer, las especificaciones, la IA te entiende y las enriquece con lo que ella cree que tú quieres, detallándolo a niveles muy muy precisos. Tú lo revisas, y puedes modificar y añadir por ejemplos test, reglas de cómo debe comportarse. Al final aplicas y te genera el código en base a esas especificaciones.

Si están bien hechas, son tan importantes, que podrías borrar el código y pedir a la IA que lo regenerara en base a las especificaciones, y el resultado no debería cambiar demasiado. Ante este nuevo paradigma han aparecido una serie de herramientas que nos ayudan en el flujo de SDD. Por ejemplo, SpecKit. Aquí vamos a analizar el flujo simple de OpenSpec.

2. SDD con OpenSpec y ClaudeCode

OpenSpec no es una IA. Se apoya en una interfaz y en un LLM para generar sus specs. El interfaz puede ser ClaudeCode y el LLM puede ser Sonnet o Opus.

En el fondo es un conjunto de herramientas de código abierto. Su objetivo principal es servir como la fuente de verdad compartida entre humanos y agentes de Inteligencia Artificial antes de escribir código. Las specs sirven para no perder el contexto entre sesiones. Obliga al agente a leer un documento de especificaciones versionado y a trabajar estrictamente bajo ese marco. A través de comandos, genera un plan con dependencias (propuesta, especificaciones, diseño y lista de tareas). Una vez que el agente completa el código, las modificaciones se integran en la especificación, manteniendo un histórico de qué se construyó y por qué.

La instalación es muy sencilla.

	npm install -g @fission-ai/openspec@latest

Una vez instalado, nos vamos hacia una carpeta donde queremos probarlo y ejecutamos el comando

	openspec init

SDD con OpenSpec y ClaudeCode. Iniciando OpenSpec

Nos preguntará con qué agente queremos interactuar.
SDD con OpenSpec y ClaudeCode. Seleccionando ClaudeCode

3. Cómo funciona OpenSpec

Lo primero es arrancar ClaudeCode en ese directorio.

Una vez entramos en el cliente de Claude podemos ejecutar comandos de openspec. En el flujo básico nos vienen cuatro.

  • /opsx:explore Explora el código que hay, matiza ideas, clarifica requerimientos, etc…
  • /opsx:propose Propones una nueva funcionalidad. OpenSpec la enriquecerá y generará todos los ficheros con las specs
  • /opsx:apply Se aplican los cambios propuestos una vez revisados y generaran el código.
  • /opsx:archive Los cambios los archivará y volvemos al proceso iterativo con la siguiente historia de usuario.

Vamos a verlo en funcionamiento y le hacemos la siguiente propuesta.

/opsx:propose Quiero una web con la tabla periódica.
1) Con fondo claro y los elementos en color pastel
2) Que funcione sin necesidad de un servidor web, usando solo estándares HTML, CSS3 y JavaScript (Vainilla)
3) Que tenga un buscador
4) Que cuando selecciones un elemento muestre los detalles, sin que la tabla periódica reescale de tamaño.
5) Que los lantánidos y actínidos estén separados de la tabla periódica por al menos una fila

SDD con OpenSpec y ClaudeCode. Resultado de nuestra primera propose

Ha creado varios ficheros.

proposal.md
SDD con OpenSpec y ClaudeCode. Detalle del fichero generado proposal.md

design.md
SDD con OpenSpec y ClaudeCode. Detalle del fichero generado design.md

tasks.md
SDD con OpenSpec y ClaudeCode. Detalle del fichero generado con la lista de tareas a implementar por la IA

Y las specs de los distintos componentes.
Vamos a ver el del buscador, por ejemplo
SDD con OpenSpec y ClaudeCode. Un ejemplo del fichero generado con las specs del componente del buscador

4. Aplicando las specs

Bien, ya tenemos los archivos generados con las especificaciones detalladas. Hemos dedicado un rato a leerlas y a comprobar que, en efecto, es lo que queremos. Podemos enriquecerlas con ejemplos y casos de uso, o con otros detalles. Una vez lo hayamos hecho estamos en condiciones de aplicarlas y ahí, ahí es donde sucede la magia.

	/opsx:apply

Al aplicar los cambios se han generado los ficheros y, en efecto, se ha generado la página web que queríamos y se muestra sin necesidad de tener un servidor web.
SDD con OpenSpec y ClaudeCode. Primea versión de la tabla periódica

No me gusta mucho el panel ese que dice «Haz click en un elemento para ver sus propiedades»

5. Archivando las specs

Cuando archivamos mediante el comando archive se mueven los cambios activos a la carpeta «archive». Y nos preguntas si queremos sincronizar el cambio a archivar con los specs del proyecto, que ahora mismo están vacíos. Decimos que sí, y se crearán las specs centrales del proyecto. Y ya estamos en condiciones de comenzar el ciclo proponiendo un nuevo cambio.

	/opsx:archive 

SDD con OpenSpec y ClaudeCode. Sincronización y archivado

	/opsx:propose no me gusta mucho el panel blanco que dice «Haz click en un elemento para ver sus propiedades». Prefiero que no se muestre y cuando se haga click en un elemento para ver el detalle del mismo aparezca el panel de detalle

SDD con OpenSpec y ClaudeCode. Nuevos cambios propuestos

Lo aplicamos, que ejecutará los cambios necesarios para que se comporte como queremos. Tras eso, lo archivamos, que moverá la carpeta de «changes» a «archive», y nos pedirá sincronizar, que mezclará las nuevas specs con las specs centrales del proyecto, aplicando los deltas.
SDD con OpenSpec y ClaudeCode. Respuesta a los cambios propuestos

6. Añadiendo el modo oscuro

Ya le estamos pillando el tranquillo a esto. Cada cambio debe ir acompañado de una nueva prouesta:

	/opsx:propose quiero añadir un botón arriba que alterne entre modo oscuro y modo claro. 

SDD con OpenSpec y ClaudeCode. Proponiendo que añada el modo oscuro a la web

Y la plicamos

	/opsx:apply

SDD con OpenSpec y ClaudeCode. Resultado de la propuesta de modo oscuro

La página web ahora tiene modo claro y modo oscuro.
SDD con OpenSpec y ClaudeCode. Tabla periódica con modo oscuro

Archivamos el resultado y sincronizamos para que añada el delta spec del modo oscuro a los specs centrales del proyecto.

7. La fuente de la verdad ya no es el código

Pero, ¿y qué pasaría si borrase el código e hiciera una propuesta de que me lo regenerase en base a los specs? Bueno, los LLMs no son deterministas. Con mucha probabilidad no saldría exactamente igaul, pero el funcionamiento y lo programado cumpliría las especificaciones.

Hasta ahora repositábamos solo los cambios en el código, pero es legítimo preguntarse si deberíamos repositas las specs y la realidad es que sí.

Y, claro, poco a poco, según vamos trabajando vamos dándonos cuenta de sus ventajas:
1) podemos seguir trabajando en el mismo proyecto en diferentes sesiones.
2) podemos trabajar en equipo, y las specs son como una memoria del contexto compartida.

Se me antoja que GitFlow será complejo de gestionar con SDD. Seguramente haya que ir a estrategias de ramas de Trunk Base Development y hacer integraciones frecuentes, acercándonos a un despliegue contínuo de verdad.

8. Conclusiones

Es muy fácil acomodarse a OpenSpec. Aquí lo hemos usado con ClaudeCode y el modelo que he utilizado es Sonnet 4.6. No hemos usado el Opus que se habría fundido los tokens en un pis-pas. Tenemos que prestar atención a estas cosas. Probablemente no necesitamos el modelo más potente.

Creo que es muy fácil ser complaciente y acabar confiando en que lo que nos propone es suficientemente bueno y acabar por no revisarlo. Y de ahí pueden venir efectos laterales. Voy a proponer tres buenas prácticas que creo fundamentales para reducir la entropía de trabajar con SDD.

  • Hacer una buena propuesta.
    Cuanto mejor y más detallada sea la especificación de lo que queremos, más concreta y precisa será su propuesta.
  • Revisar y ampliar las specs
    Debemos revisar con detalle todo lo que nos propone. El proposal.md, el design.md, tasks.md y los specs.md
  • Añadir test antes del apply
    Si de verdad queremos que algo se comporte de una forma determinada, debemos escribir los nombres de los test de forma que reflejen ese comportamiento. Por ejemplo, «comprueba que cuando el usuario hace esto entonces pasa esto otro». En el fondo estos tests, que si hicieras TDD los harías antes de programar, aquí los sumas como validaciones del comportamiento que se espera.

 

9. Enlaces y referencias

Comentarios

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

He leído y acepto la política de privacidad

Información básica acerca de la protección de datos

  • Responsable: IZERTIS S.A.
  • Finalidad: Envío información de carácter administrativa, técnica, organizativa y/o comercial sobre los productos y servicios sobre los que se nos consulta.
  • Legitimación: Consentimiento del interesado
  • Destinatarios: Otras empresas del Grupo IZERTIS. Encargados del tratamiento.
  • Derechos: Acceso, rectificación, supresión, cancelación, limitación y portabilidad de los datos.
  • Más información: Puedes ampliar información acerca de la protección de datos en el siguiente enlace:política de privacidad

Juan Antonio tiene más de 20 años de experiencia en el desarrollo del software. Curioso, y con una predisposición a la abstracción matemática, no deja de aprender. Consolida su aprendizaje en forma de tutoriales en este portal. Que además son fruto de su afán por devolver a la comunidad parte del conocimiento adquirido. Trabaja como arquitecto de software en Autentia. Y acaba de publicar su primera novela: Mutagénesis Convergente

¿Quieres publicar en Adictos al trabajo?

Te puede interesar

22/06/2026

Juan Antonio Jiménez Torres

Vamos a instrumentalizar un SDD para un microservicio bancario. En este artículo sobre SDD - Spec Driven Development, instrumentalizado sobre OpenSpec vamos a construir una PoC de algo más serio que una tabla periódica. Un microservicio bancario muy simplificado que gestione cuentas y permita hacer transferencias

16/06/2026

Juan Antonio Jiménez Torres

Este es el segundo artículo sobre SDD, Spec Driven Development, instrumentalizado sobre OpenSpec. Pero esta vez nos acercaremos usando softwere gratuito. Por un lado OpenCode en lugar de ClaudeCode y usando el modelo gratuito Gemma4 de Google en lugar de otros de pago.

02/03/2026

José Antonio Sánchez Segovia

Zephyr es un RTOS open source respaldado por la Linux Foundation que permite desarrollar dispositivos embebidos conectados, eficientes y escalables, facilitando el paso de prototipo a producto final con una arquitectura mantenible.