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
