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).

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.

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.

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

Tres pilares

Documentos vivos — No son requisitos rígidos en cascada, sino texto que evoluciona con el problema.
Decisiones explícitas — No es burocracia por burocracia: es sacar la arquitectura del chat informal y volverla rastreable (pensamiento con control de versiones).
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.

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.

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.

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

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 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.

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)

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.

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

Spec-First — Un documento sólido para la entrega actual; a veces se descarta tras implementar.
Spec-Anchored — La spec vive en el repositorio y ancla el contexto para evolución y mantenimiento.
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.

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).

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.

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.

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.

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