Spec Driven Development - potenciando aún más el vibe coding

Antes de empezar

Kiro, un IDE, ya fue cubierto anteriormente en GeekNews.

Sin embargo, no se había presentado desde la perspectiva de Spec Driven Development (SDD), la filosofía de metodología de desarrollo a la que apunta Kiro,

y se publicó un video muy bueno para entender Spec Driven Development, así que lo compartimos aquí.

---

Kiro

• IDE de tipo agente: ayuda con el desarrollo en lenguaje natural, pero con un sesgo que pone a las “especificaciones como artefacto de primera clase”.

• Mantiene la velocidad del “vibe coding” de los IDE de agentes existentes, mientras define en documentos de especificación las decisiones, supuestos y restricciones.

• Flujo de trabajo: al ingresar una idea, comienza de inmediato generando tres archivos: requirements, design y tasks. El editor está construido sobre un fork de Code OSS al que se le agregan las pestañas “Specs / Hooks / Steering”.

  • Specs: estructura los requisitos (historias de usuario + criterios de aceptación en formato EAR) y luego conecta implementación, pruebas y cambios con la especificación.
  • Hooks: monitorea cambios en archivos/código para activar el flujo de trabajo de especificaciones.
  • Steering: hace check-in de guías del equipo como reglas (markdown) dentro de .kiro/ en la raíz del repositorio; por ejemplo, se pueden agregar reglas de TDD para hacer más consistente el comportamiento del agente.

La necesidad de Spec Driven

• Complementar las limitaciones del vibe coding: cuando se crea código rápidamente con intercambios de chat, el fundamento de las decisiones queda enterrado en el flujo de conversación y después se vuelve difuso “qué se hizo y por qué”. SDD propone establecer primero especificaciones centradas en el comportamiento y usarlas como una brújula estable.

• Definición de una especificación (comportamiento, propiedades, invariantes): describe cómo debe comportarse el sistema, no cómo está implementado. Toma conceptos como propiedades de safety/liveness e invariantes, pero con la filosofía de hacerlos accesibles mediante una sintaxis amigable para desarrolladores.

Ventajas de SDD

• Visibilidad y reutilización de decisiones: la especificación se convierte en la “fuente” de los cambios de código, facilitando revisiones y acuerdos, y dejando registrada la intención (behaviors) incluso cuando cambian las funciones.

• Especificaciones vivas y combinables: escenarios de usuario, criterios de aceptación, contratos de interfaz/datos, rendimiento/SLAs, etc., pueden modularizarse para reutilizarse y componerse (de servicio a nivel de sistema).

• Aplicación a todo el SDLC: desde la alineación inicial de requisitos y diseño hasta el ciclo de retroalimentación de incidentes después del despliegue. La idea es mantener revisión, calidad y consistencia incluso en una era de IA con generación de código acelerada.

Demo de SDD

• Para el enlace al momento en que empieza la demo en el video publicado en Main link, consulta esta URL: https://youtu.be/olMxlFSxydc?si=sei-bBZ0Q0yszaWn&t=1085

Flujo de SDD

A. Configuración inicial

1. Configuración del proyecto - Hooks, Steering, MCP
2. Configuración de TDD (recomendado)
3. Configuración de Spec - redacción de especificaciones basada en formato EAR (recomendado) (también puede generarse automáticamente con IA a partir del análisis de un proyecto existente)

B. Implementación de funciones

1. Derivación de Spec - reflejar/actualizar nuevos requisitos en la especificación
2. Configuración de guardrails (recomendado) - stubs de prueba, redacción de reglas
3. Implementación <-> pruebas - esta sección se repite mayormente a través de IA, y el desarrollador solo interviene para pequeños ajustes de código que la IA no logra corregir bien

• Una vez completada la configuración del proyecto, las funciones se amplían repitiendo la etapa 'B. Implementación de funciones'.

Precauciones

• No funciona si la calidad del documento de especificación no alcanza un nivel mínimo.
• En el video no se explican en detalle las reglas base del documento Spec. (Referencia: https://kiro.dev/docs/specs/)
• Se recomienda usar TDD, pero se dice que la mayoría de los proyectos donde TDD no estaba aplicado no lograron percibir mucho efecto de esta metodología.

---

Opinión personal

• Una de las metodologías propuestas desde otra perspectiva para aprovechar bien la IA.
• Los documentos siempre que estén “bien” escritos tienen muchísimas ventajas. Sin embargo, por la experiencia realista de que bastantes documentos no se mantienen adecuadamente, parece que la clave está en cuánto consenso logre generar entre más personas.
• En este momento, la estrategia de desarrollo con IA + TDD es una metodología con la que muchos desarrolladores coinciden y que está validada hasta cierto punto. Si se valida su efectividad comparando el uso independiente de TDD con el uso combinado de SDD, probablemente ganará mucha más aceptación.