# Del “vibe coding” al plano vivo: Spec-Driven Development

Del “vibe coding” al plano vivo: por qué la especificación estructurada vuelve a mandar sobre el código.

*Basado en la presentación Spec-Driven Development (JoeDayz).*

![Contenido del artículo](https://media.licdn.com/dms/image/v2/D4E12AQHE-sN0aq3y2g/article-inline_image-shrink_1000_1488/B4EZ3MICrXJMAQ-/0/1777246164501?e=1778716800&v=beta&t=2RtjBeveMZdY0iJ5kS7mVmynK16AvaB14VesIiaZfeY align="center")

*Portada de la presentación: SDD, transición del “vibe coding” y el plano vivo frente a prompts vagos.*

Durante meses vimos el auge del *vibe coding*: prompts rápidos, la IA “adivinando” y entregas que parecen mágicas al principio. El problema es que **tratar a los agentes como buscadores generativos genera deuda técnica al instante**: sin contexto explícito, el modelo rellena huecos. Ahí aparecen el stack equivocado, APIs sin las salvaguardas correctas o bloques enormes de código difíciles de mantener.

![Contenido del artículo](https://media.licdn.com/dms/image/v2/D4E12AQHZqutlNd6T2w/article-inline_image-shrink_1000_1488/B4EZ3MIUrzKwAU-/0/1777246235397?e=1778716800&v=beta&t=-oIv8dnNAvEgD6Dr3qGmjN1VQvC4VYMnWj8TvEdjHg4 align="center")

*Tratar al agente como buscador generativo obliga a adivinar: aparecen incompatibilidades, vulnerabilidades y código imposible de mantener.*

**Spec-Driven Development (SDD)** propone un giro claro: **la intención bien capturada es el artefacto principal; el código es su última expresión.** No es volver a un waterfall de PDFs muertos: es llevar la documentación al **plano vivo** (documentos que iteran con tu entendimiento del problema) y usarla como **contrato estructurado** que la IA puede generar, probar y validar.

En el desarrollo tradicional, el código era la fuente de verdad y la documentación quedaba obsoleta. En SDD, la **especificación ejecutable** ocupa ese lugar: refactorizar pasa a ser **reordenar la intención**, no pelear solo con la sintaxis.

![Contenido del artículo](https://media.licdn.com/dms/image/v2/D4E12AQFEV0l1l1sSfA/article-inline_image-shrink_1000_1488/B4EZ3MIbvYJUAQ-/0/1777246261680?e=1778716800&v=beta&t=QcTNKUp49cBRDNogTRaL0hm2WSMt6tKDBZKKdYsoufY align="center")

*Contraste: código como rey (spec desechable) frente a spec ejecutable generada: la especificación gobierna, el código la expresa.*

### **Tres pilares**

1.  **Documentos vivos** — No son requisitos rígidos en cascada, sino texto que evoluciona con el problema.
    
2.  **Decisiones explícitas** — No es burocracia por burocracia: es sacar la arquitectura del chat informal y volverla **rastreable** (pensamiento con control de versiones).
    
3.  **Motor de generación** — El spec no es solo para humanos: es el insumo que los agentes usan para producir y verificar código de forma repetible.
    

![Contenido del artículo](https://media.licdn.com/dms/image/v2/D4E12AQGyBwtjgNMp0w/article-inline_image-shrink_1000_1488/B4EZ3MIgIvIwAQ-/0/1777246282046?e=1778716800&v=beta&t=w52KIpAIGpnj_9gyQaP9oY7kdidNQBaoTkax1QsqsUo align="center")

*Qué es y qué no es cada pilar: iteración real frente a cascada, control de versiones del pensamiento frente a burocracia, contrato estructurado para agentes frente a texto solo humano.*

### **Evolución del paradigma**

Una forma útil de ver el cambio: del **código** como verdad → al **prompt** efímero → al **Markdown / spec** como ancla. El cambio deja de ser “reescrituras impredecibles” y se acerca a **regeneración sistemática** cuando cambian negocio o restricciones.

![Contenido del artículo](https://media.licdn.com/dms/image/v2/D4E12AQHNqY8jKz89YA/article-inline_image-shrink_1000_1488/B4EZ3MIkzzJQAU-/0/1777246301665?e=1778716800&v=beta&t=VSRIGj21fvUcOjuMlhxzAlu-RSqXtVP_5Kor2uw_oZQ align="center")

*Comparación de enfoques: qué manda, cómo se gestionan los cambios y qué hace el desarrollador en cada mundo.*

### **Flujo de trabajo (regla de oro)**

**Ninguna fase avanza hasta que el artefacto actual está validado por quien desarrolla.**

FaseEnfoque**Especificar**El qué y el por qué, sin mezclar todavía decisiones técnicas.**Planificar**Traducción técnica (modelos, contratos, alternativas) con **trazabilidad** a lo acordado antes.**Tareas e implementación**Fragmentación inteligente, paralelismo donde encaja, revisión **cognitiva** sobre piezas pequeñas y probadas, no sobre volcados de mil líneas.

![Contenido del artículo](https://media.licdn.com/dms/image/v2/D4E12AQHV8nXXVmJZ8w/article-inline_image-shrink_1000_1488/B4EZ3MIpwhJMAQ-/0/1777246321567?e=1778716800&v=beta&t=_vbg-8Vh67xe-rZdTOy_OAlKAIw0Gk13WAkN_Zw9OQ4 align="center")

*Regla de oro: validar el artefacto de cada fase antes de avanzar; el humano revisa, el agente ejecuta piezas acotadas.*

### **Constitución: filtro de arquitectura**

Un archivo tipo [constitution.md](http://constitution.md) fija principios que protegen UX y arquitectura, por ejemplo:

*   **Library-first:** la funcionalidad como bibliotecas modulares.
    
*   **CLI-first:** interfaces accesibles por línea de comandos.
    
*   **Test-first:** sin implementación que no esté cubierta por pruebas acordadas.
    

Así se reduce la “sobreingeniería” de la IA y se valida compatibilidad con el sistema real.

![Contenido del artículo](https://media.licdn.com/dms/image/v2/D4E12AQHsML1JMq9bjQ/article-inline_image-shrink_1000_1488/B4EZ3MIu6uK4AQ-/0/1777246342422?e=1778716800&v=beta&t=bs5iVtWZd7kfOhuQl-3exX2DYTjQqRyXs4Hbbyt64qg align="center")

*Constitución: ADN de arquitectura inmutable; límites claros para que la IA no se pase de alcance ni invente capas inútiles.*

### **Detalle de fases (ejemplos)**

![Contenido del artículo](https://media.licdn.com/dms/image/v2/D4E12AQGqRkJdKBcj9g/article-inline_image-shrink_1000_1488/B4EZ3MI15UIMAQ-/0/1777246372311?e=1778716800&v=beta&t=YqgY1bmux-WQnGWeJNfUBFbs-KpayHhzg1r07RieF28 align="center")

*Especificar: requisitos e historias con criterios de aceptación; evitar que la IA alucine detalle técnico demasiado pronto.*

*Planificar: modelos, contratos y arquitectura vinculados a requisitos; abre comparar implementaciones (por ejemplo, distintos lenguajes) bajo la misma especificación.*

![Contenido del artículo](https://media.licdn.com/dms/image/v2/D4E12AQEI1YJF_QsUpg/article-inline_image-shrink_1000_1488/B4EZ3MJD6QGkAQ-/0/1777246430400?e=1778716800&v=beta&t=eKHvtZJZlSt8fXg4WExequwLScfs97CWbJsy3Sl3lOY align="center")

*Tareas e implementación: tareas atómicas, etiquetado para paralelismo, revisiones pequeñas y validadas con pruebas en lugar de dumps enormes.*

### **Madurez: tres niveles**

1.  **Spec-First** — Un documento sólido para la entrega actual; a veces se descarta tras implementar.
    
2.  **Spec-Anchored** — La spec vive en el repositorio y ancla el contexto para evolución y mantenimiento.
    
3.  **Spec-as-Source** — La especificación manda a largo plazo; el humano edita el texto y el código puede **regenerarse** automáticamente.
    

Cada nivel tiene coste: más Markdown que revisar, más disciplina para separar **intención funcional** de **detalle técnico**.

![Contenido del artículo](https://media.licdn.com/dms/image/v2/D4E12AQHqqWCghF1zdA/article-inline_image-shrink_1000_1488/B4EZ3MJI3rGYAQ-/0/1777246451691?e=1778716800&v=beta&t=faeoQiTVMlZtVzh_TCalEDN9xmT5Um0ZmUDt_uRioTE align="center")

*Subir de nivel implica más compromiso con el spec como ancla o como fuente que gobierna el código generado.*

### **Matriz de herramientas (estado del ecosistema)**

En la práctica, herramientas y flujos se sitúan en distintos puntos de madurez: desde enfoques *spec-first* ligeros hasta integraciones *spec-anchored* con comandos y constitución, hasta *spec-as-source* (visión a futuro, con los retos clásicos del model-driven).

![Contenido del artículo](https://media.licdn.com/dms/image/v2/D4E12AQGt0MgdVf-jmA/article-inline_image-shrink_1000_1488/B4EZ3MJPEtIgAQ-/0/1777246475507?e=1778716800&v=beta&t=rWgzff4_mySSjDfrEgSugSKyF28-_C2L177aktS1cV4 align="center")

*Pros y contras: lo ligero puede ser exceso para toques pequeños; lo potente genera mucho Markdown; lo “spec como fuente” evoca lecciones del MDD.*

### **Dónde brilla el SDD**

*   **Greenfield (0 → 1):** alinear el producto desde el día uno sin soluciones genéricas desalineadas.
    
*   **Sistemas existentes (N → N+1):** el plan codifica restricciones del sistema actual para que lo nuevo se sienta nativo, no como parche.
    
*   **Modernización de legacy:** extraer especificaciones limpias y reconstruir sin arrastrar toda la deuda original.
    

![Contenido del artículo](https://media.licdn.com/dms/image/v2/D4E12AQGOAHHDVmrSUg/article-inline_image-shrink_1000_1488/B4EZ3MJWo2HMAQ-/0/1777246508057?e=1778716800&v=beta&t=rWirMRLGj6tZfagKxkJ3on9tzJjLGeMok0GpliVQA5o align="center")

*Cuándo el SDD aporta más: intención única desde cero, respeto a arquitectura existente, o reversión a spec y regeneración en legacy.*

### **Desafíos (baño de realidad)**

*   **Fatiga de Markdown:** revisar muchos archivos de texto puede ser tan pesado como revisar solo código.
    
*   **Falsa sensación de control:** contextos enormes no garantizan obediencia; los agentes aún pueden ignorar reglas o aplicarlas de forma rígida y contraproducente.
    
*   **Funcional vs técnico:** los equipos suelen mezclar intención pura e implementación; SDD exige disciplina explícita.
    

![Contenido del artículo](https://media.licdn.com/dms/image/v2/D4E12AQFUT1WJtE_XHQ/article-inline_image-shrink_1000_1488/B4EZ3MJcAmJQAQ-/0/1777246529651?e=1778716800&v=beta&t=gAAOtS-30p1HcgoE94gEg20x9dq_IW-2wGy3zSRNcus align="center")

*Ser honesto con el coste de revisar specs y con los límites de la IA incluso con reglas claras.*

### **Síntesis**

**Escribir Markdown estructurado y riguroso hoy se parece más a “compilar intención” que a redactar un README de adorno.** El rol del desarrollador se desplaza hacia **arquitectura de sistemas, gestión de restricciones y validación de ejecución**. Cuando la especificación manda, un giro brusco de negocio puede dejar de ser una reescritura traumática y convertirse en **regeneración ordenada**.

![Contenido del artículo](https://media.licdn.com/dms/image/v2/D4E12AQH8dWh8x7SKDg/article-inline_image-shrink_1000_1488/B4EZ3MJg.1JMAQ-/0/1777246551525?e=1778716800&v=beta&t=nUb5IjDriDSgqqpuRyToaiNPFanzHnLy7vGNuOD7rto align="center")

*Cierre: de escribir sintaxis a orquestar intención; los cambios de negocio como regeneración en lugar de reescritura manual descontrolada.*

* * *

Si trabajas con IA en producción, ¿en qué nivel te sitúas hoy: Spec-First, Spec-Anchored o Spec-as-Source?

#SoftwareEngineering #SpecDrivenDevelopment #IA #IngenieriaDeSoftware #DeveloperExperience #JoeDayz