Adiós al "Vibe Coding": 5 Revelaciones sobre cómo la Inteligencia Artificial está Reestructurando la Ingeniería de Software con SDD

1. Introducción: El Caos del Prompting Impreciso y la Emergencia del SDD

La incorporación masiva de herramientas de Inteligencia Artificial en el desarrollo de software ha dado lugar a una práctica tan extendida como arriesgada: el "vibe coding". Esta aproximación, basada en la interacción con modelos de lenguaje mediante instrucciones informales y ad-hoc, promete velocidad inmediata, pero frecuentemente desemboca en un ciclo frustrante. Sin un arnés de gobernanza estructural, los modelos generan alucinaciones de código, arquitecturas desestructuradas, acumulación masiva de deuda técnica y el fenómeno conocido como intent drift (divergencia de intención), donde el software final deja de responder a las necesidades reales del negocio.

Como respuesta a las limitaciones operativas del prompting impreciso, la industria está adoptando formalmente el Desarrollo Basado en Especificaciones (SDD, Spec-Driven Development). El SDD es una metodología de ingeniería de software en la que una especificación formal, estructurada y legible por máquina actúa como la fuente única de verdad del sistema antes de escribir código ejecutable. Al separar de forma rigurosa el qué del cómo, el SDD transforma la generación asistida por IA de un proceso estocástico e impredecible a una disciplina arquitectónica controlada e ingeniada.

A continuación, exploraremos las 5 revelaciones más impactantes sobre cómo la metodología SDD y su ecosistema agéntico están reestructurando la ingeniería de software moderna hacia un paradigma determinista y escalable.

2. Revelación 1: Del Caos Prompteado al Determinismo Estructurado (SDD vs. Vibe Coding)

El contraste fundamental entre la programación imprecisa (Vibe Coding) y el Desarrollo Basado en Especificaciones radica en la ubicación de la autoridad del sistema. En el vibe coding, el programador confía ciegamente en las iteraciones del LLM, tratando al código generado como la verdad absoluta y re-prompteando parches sobre parches cuando ocurren fallos. Por el contrario, el SDD establece que la especificación aprobada y los documentos de gobernanza constituyen la fuente innegociable de autoridad técnica y funcional.

Pasar de la improvisación textual a especificaciones formales previas a la codificación elimina de raíz las alucinaciones de los modelos de lenguaje. Al recibir una especificación acotada con contratos explícitos y esquemas definidos, los agentes de IA no tienen que adivinar reglas de negocio, estructuras de datos ni dependencias autorizadas. Esto garantiza un control determinista sobre la ejecución agéntica, acotando el espacio de estados en el que opera la IA y asegurando que el software resultante sea predecible, repetible y plenamente auditable.

Criterio	Programación Imprecisa (Vibe Coding)	Desarrollo Basado en Especificaciones (SDD)
Punto de Inicio	Prompts informales y ad-hoc.	Especificación formal previa (spec.md / OpenAPI).
Fuente de Autoridad	El código generado por la IA.	La especificación aprobada y la Constitución.
Revisión de Calidad	Aceptación a ciegas del output.	Auditoría previa en plan y posterior en validación.
Manejo de Cambios	Re-promptear y parchar el código.	Actualizar la spec primero y regenerar/refactorizar.
Riesgo Principal	Alucinaciones, deuda técnica y intent drift.	Inversión de tiempo en el análisis inicial.
Caso de Uso Ideal	Prototipos desechables y scripts de una sola ejecución.	Software empresarial, microservicios y producción.

3. Revelación 2: La Taxonomía del SDD: Por qué "Spec-Anchored" es el Punto Dulce

La adopción de la metodología SDD no ocurre de forma homogénea en la industria; se clasifica en tres niveles o enfoques principales según el comportamiento y la persistencia de la especificación tras la fase inicial de codificación:

• Spec-First: La especificación se redacta detalladamente para arrancar el proyecto y servir como punto de entrada o prompt estructurado. Sin embargo, una vez generado el código inicial, la especificación no se mantiene activa de forma continua y suele quedar obsoleta (intent drift). La fuente de verdad definitiva pasa a ser el código fuente. Es el nivel ideal para prototipos rápidos, pruebas de concepto (PoCs) o proyectos de ciclo de vida corto.
• Spec-Anchored: La especificación y el código coexisten, evolucionan y se sincronizan continuamente en Git a lo largo de todo el ciclo de vida del software. Si los requisitos cambian, primero se actualiza la especificación y luego se refleja en el código mediante pruebas de contrato y pipelines de integración continua. Existe una doble fuente de verdad sincronizada. Es la alternativa óptima para entornos empresariales, microservicios y proyectos de mediano y largo plazo.
• Spec-as-Source: Representa el nivel más alto de abstracción. La especificación es la única fuente de verdad editada directamente por los seres humanos. Los desarrolladores jamás modifican el código de implementación ejecutable; este es generado al 100% de forma automática por compiladores, emitters o agentes de IA. Si hay un cambio, se modifica la especificación abstracta y se recompila todo el sistema. Es el nivel ideal para la generación automatizada de SDKs multilenguaje o esquemas altamente estandarizados.

El análisis de la industria ubica al nivel Spec-Anchored como el equilibrio práctico perfecto. Otorga un marco estricto de gobernanza y control de contexto para que los agentes de IA colaboren sin degradar la arquitectura, manteniendo al mismo tiempo la flexibilidad técnica para ajustar el código cuando sea necesario.

"En la práctica diaria de la ingeniería de software actual, el nivel Spec-Anchored es la opción más recomendada y extendida, ofreciendo el equilibrio ideal entre gobernanza y flexibilidad."

4. Revelación 3: EARS: El "Idioma Secreto" para que la Inteligencia Artificial no Alucine

Para redactar requisitos que los modelos de lenguaje interpreten sin ambigüedades, el SDD adopta la notación EARS (Easy Approach to Requirements Syntax). Desarrollada por Alistair Mavin y su equipo en Rolls-Royce plc durante el análisis de sistemas críticos de control aeronáutico, EARS restringe el lenguaje natural mediante un orden temporal fijo y palabras clave estandarizadas. Su aplicación en SDD elimina las suposiciones imprecisas del LLM, convirtiendo requisitos funcionales en instrucciones deterministas y analizables sintácticamente.

Los 5 patrones sintácticos principales de EARS se estructuran a partir de disparadores explícitos:

1. Ubicuo (Siempre activo): El <sistema> debe <respuesta>
2. Dirigido por Eventos (WHEN / Cuando): WHEN <evento desencadenante>, el <sistema> debe <respuesta>
3. Dirigido por Estados (WHILE / Mientras): WHILE <estado activo>, el <sistema> debe <respuesta>
4. Característica Opcional (WHERE / Donde): WHERE <opción habilitada>, el <sistema> debe <respuesta>
5. Comportamiento No Deseado / Excepción (IF / THEN / Si... entonces): IF <error o condición no deseada>, THEN el <sistema> debe <respuesta>

Además de estos patrones individuales, EARS permite modelar lógica de negocio compleja mediante el patrón de Requisitos Complejos (Complex Requirements), que combina cláusulas temporales de estado y evento en una sola estructura declarativa: WHILE <estado activo>, WHEN <evento desencadenante>, el <sistema> debe <respuesta> (por ejemplo: "WHILE la aeronave esté en tierra, WHEN se ordene empuje inverso, el sistema de control del motor debe habilitar el empuje inverso").

Restringir la prosa libre mediante la notación EARS simplifica la traducción de los requisitos de negocio a suites de pruebas automatizadas y pruebas de contrato. Al contar con precondiciones, disparadores WHEN y respuestas del sistema claramente acotadas, la IA carece de margen para interpretar reglas no escritas, reduciendo las alucinaciones a cero y permitiendo validar automáticamente el software contra cada cláusula.

5. Revelación 4: Los Nuevos Archivos de Gobernanza: AGENTS.md y constitution.md

El Desarrollo Basado en Especificaciones introduce una capa de gobernanza operacional y arquitectónica mediante archivos Markdown estandarizados que actúan como System Prompts persistentes y leyes constitutivas para los agentes de IA.

El archivo AGENTS.md funciona conceptualmente como el "README para agentes de IA". Es un estándar abierto administrado por la Agentic AI Foundation bajo la Linux Foundation. Su objetivo es declarar la misión, stack autorizado, comandos de entorno, mapa de directorios y prohibiciones explícitas del repositorio. Para garantizar la máxima eficiencia operativa, la especificación de AGENTS.md exige ubicarlo en la raíz del proyecto (/AGENTS.md) —o anidado en paquetes específicos dentro de monorrepositorios— y mantener una extensión breve y concisa, idealmente de 30 a 60 líneas útiles. Esta restricción evita la saturación inútil de la ventana de contexto y optimiza el consumo de tokens en cada invocación agéntica.

Por su parte, el archivo constitution.md (ubicado habitualmente en docs/constitution.md) representa la ley suprema del repositorio. Establece los principios arquitectónicos innegociables que tanto humanos como agentes deben acatar obligatoriamente antes de proponer planes o modificar código. Entre sus mandatos destacan reglas como "La especificación manda sobre el código", el aislamiento estricto de la lógica de dominio pura respecto a los módulos de I/O, el uso de tipado estricto y la obligatoriedad del desarrollo guiado por pruebas (TDD).

"Mientras que un README.md está escrito para humanos, AGENTS.md y constitution.md son la guía contextual innegociable que dictan cómo debe comportarse la IA antes de tocar una sola línea de código."

6. Revelación 5: La Evolución del SDLC: El Ciclo de Vida Nativo de IA en 7 Etapas

Partiendo de la base de gobernanza y las leyes del repositorio establecidas en la Etapa 1 mediante constitution.md y AGENTS.md, el Ciclo de Vida del Desarrollo de Software (SDLC) tradicional evoluciona en el SDD puro hacia un flujo riguroso de 7 etapas secuenciales orientadas a la colaboración agéntica:

1. Etapa 1: Constitución / Setup: Establece el marco normativo y los límites del proyecto mediante constitution.md y /AGENTS.md.
2. Etapa 2: Especificación / Specify: Transforma los requisitos de negocio en la intencionalidad pura del sistema escrita en notación EARS dentro de spec.md.
3. Etapa 3: Clarificación / Clarify: Audita la especificación en clarify.md para identificar vacíos lógicos, resolver ambigüedades mediante un Q&A de negocio y cubrir casos borde.
4. Etapa 4: Planificación Técnica / Plan: Diseña el cómo técnico en plan.md, detallando la arquitectura de módulos, esquemas de datos (JSON Schema, SQL) y contratos de integración.
5. Etapa 5: Tareas Atómicas / Tasks: Descompone el plan técnico en tasks.md mediante una secuencia de unidades de trabajo atómicas, independientes y accionables en lapsos de 15 a 30 minutos.
6. Etapa 6: Implementación / Implement: Ejecuta el desarrollo tarea por tarea mediante un bucle TDD agéntico estricto. El agente lee la primera casilla no marcada (- [ ]) en tasks.md, escribe una prueba unitaria que falla (Fase Roja), genera el código de producción mínimo para hacerla pasar (Fase Verde), verifica la ejecución mediante el test runner de terminal (pytest, vitest) y actualiza la casilla a completada (- [x]) antes de detenerse.
7. Etapa 7: Validación / Validate: Emite validation_report.md evaluando el código resultante contra la matriz EARS y ejecutando pruebas de contrato automatizadas para confirmar la convergencia al 100% con la especificación.

El Ecosistema Agéntico: OpenCode, Subagentes y Protocolos MCP

Este flujo SDLC de 7 etapas es orquestado de forma nativa por el ecosistema agéntico moderno a través de mecanismos especializados:

• Modos Operativos en OpenCode: Las herramientas modernas de ingeniería agéntica diferencian conceptualmente el diseño del código. En Plan Mode (Shift + Tab), el agente opera en un entorno de solo lectura analizando la arquitectura, investigando la base de código y redactando artefactos como plan.md y tasks.md sin riesgo de modificación fortuita. Por el contrario, en Build Mode, se otorgan permisos explícitos para modificar archivos y ejecutar comandos en la terminal durante la fase de implementación.
• Aislamiento de Contexto mediante Subagentes Especializados: Para evitar sesgos de confirmación y contaminación de contexto, el trabajo se delega en subagentes con roles delimitados. Un subagente @planner diseña la estructura, un subagente @coder escribe la solución en TDD, y un subagente @reviewer —configurado con permisos estrictos de solo lectura (edit: false)— audita objetivamente si el código cumple los contratos de la constitución antes del merge.
• Expansión Dinámica vía Protocolos MCP (Model Context Protocol): Los servidores MCP actúan como conectores universales para inyectar información dinámica al agente. Mediante servidores MCP como Context7, los agentes consultan la documentación oficial y actualizada de librerías en tiempo real, evitando sintaxis obsoletas; mientras que mediante MCPs de automatización como Playwright o Chrome DevTools, el subagente de validación puede abrir un navegador real, interactuar con la interfaz y comprobar visualmente los criterios de aceptación EARS.

7. Conclusión: El Futuro de la Ingeniería de Software

La llegada de la Inteligencia Artificial al desarrollo de aplicaciones no elimina la ingeniería de software ni la necesidad del pensamiento crítico humano. Por el contrario, la eleva a su máxima expresión: desplaza el esfuerzo intelectual desde la codificación sintáctica manual —cada vez más asumida por agentes automatizados— hacia el análisis riguroso de requisitos, la definición de arquitecturas robustas y la gobernanza determinista de los sistemas.

El Desarrollo Basado en Especificaciones (SDD) demuestra que para programar eficazmente con IA no se necesitan mejores prompts improvisados, sino mejores especificaciones, barreras de seguridad transparentes y arneses de contexto bien estructurados. La disciplina reemplaza al azar, devolviendo el control de calidad al centro del proceso de ingeniería.

Sabiendo que el vibe coding genera deuda técnica acelerada e impredecibilidad arquitectónica, ¿está su equipo de desarrollo listo para abandonar la improvisación de prompts y adoptar la gobernanza determinista del SDD?

---

Dominar la transición del vibe coding hacia una ingeniería agéntica determinista no ocurre por casualidad: exige arquitectura sólida, gobernanza estricta y visión técnica en producción. Si te interesa profundizar en estas metodologías, implementar flujos agénticos escalables o colaborar en proyectos de desarrollo, datos e inteligencia artificial, te invito a explorar mi trabajo y conectar conmigo a través de sebaxtian.dev. Conversemos sobre cómo llevar la ingeniería de software moderna al siguiente nivel.