Los equipos de ingeniería de IA están abandonando el Vibe Coding por las especificaciones

En el primer trimestre de 2026, varios equipos de ingeniería que habían pasado el año anterior "vibe coding" — dando indicaciones sueltas a un AI agent e iterando hasta que algo funcionara — invirtieron silenciosamente el rumbo. La razón no fue que los agents empeoraran. Es que la indicación no estructurada dejó de escalar una vez que se confió a los agents cambios en múltiples archivos y Pull Requests autónomos. La solución en la que convergieron los equipos es el desarrollo impulsado por especificaciones (Spec-Driven Development): escribir una especificación estructurada antes de que un agent toque el código, y tratar esa especificación — no el diff resultante — como la fuente de verdad.

Esto no es un retorno a los documentos de requisitos estilo Waterfall que nadie lee. Es una respuesta directa a un modo de fallo específico: código seguro y plausible que silenciosamente resuelve el problema equivocado porque nadie basó el trabajo del agent en una definición real de "terminado". Para mediados de 2026, todos los principales proveedores de coding agents — GitHub, AWS, el ecosistema Claude Code de Anthropic, y una ola de frameworks Open Source — han lanzado su propia versión de flujos de trabajo primero-especificación, y el patrón ha pasado de "experimento interesante" a práctica predeterminada en equipos de producción.

Por qué el Vibe Coding falla a escala

Una corrección de error de un solo archivo o un pequeño script tolera la indicación suelta porque el radio de explosión es pequeño y un humano revisa todo el diff en segundos. Las funciones de varios archivos no funcionan así. A un agent que se le pide "agregar facturación por suscripción" tiene que inferir decisiones de esquema de base de datos, convenciones de manejo de errores, patrones de nombres y casos límite que nunca fueron declarados — y lo inferirá con confianza, incluso cuando esté equivocado. El fallo no se muestra como un crash; aparece tres sprints después como desviación arquitectónica, lógica duplicada y una base de código que ya no coincide con el modelo mental de nadie.

La evidencia comercial de esto ahora es pública. GitHub ha informado que los equipos que usan su kit de herramientas Spec Kit en proyectos internos entregan funciones con aproximadamente un orden de magnitud menos de ciclos de "regenerar desde cero" que los equipos que usan indicaciones ad hoc. AWS ha publicado casos de clientes donde funciones estimadas en 40 horas de tiempo de ingeniería se entregaron en menos de 8 horas de esfuerzo humano una vez que el trabajo se redactó primero como especificación, con el agent manejando la implementación mecánica contra criterios de aceptación claros.

Las herramientas que hacen de las especificaciones el estándar

Cinco frameworks definen ahora el panorama impulsado por especificaciones, y toman enfoques genuinamente diferentes:

• GitHub Spec Kit — una CLI de código abierto con licencia MIT con más de 93,000 estrellas en GitHub (v0.8.7 lanzada en mayo de 2026). Cada proyecto de Spec Kit comienza con una "constitución": un archivo Markdown con principios inmutables y de todo el proyecto — estándares de prueba, restricciones arquitectónicas, convenciones de nombres — que persiste en cada sesión del agent como un contrato permanente entre el desarrollador y el agent.
• AWS Kiro — un fork de VS Code que alcanzó una amplia disponibilidad global en mayo de 2026 y sitúa las especificaciones en el centro del propio IDE. Kiro impone un pipeline estricto: requirements.md (historias de usuario con criterios de aceptación escritos en notación EARS — "WHEN [condición] THE SYSTEM SHALL [comportamiento]", un formato desarrollado originalmente en Rolls-Royce para sistemas críticos de seguridad) → design.md (diagramas de arquitectura y secuencia) → tasks.md (pasos de implementación discretos y rastreables) → código.
• BMAD-METHOD — un framework con licencia MIT (v6.6.0, abril de 2026; más de 46,700 estrellas) que orquesta más de doce roles especializados de agent — gerente de producto, arquitecto, diseñador UX, desarrollador, QA, scrum master — cada uno leyendo el documento del agent anterior y produciendo el suyo, creando una cadena rastreable desde el requisito hasta el código entregado.
• Tessl — se instala como "tiles" en el directorio .tessl/ de un proyecto y funciona con cualquier agent compatible con MCP, incluidos Claude Code y Cursor. Sus agents reciben la instrucción de hacer preguntas aclaratorias primero, escribir la especificación, esperar la aprobación explícita del desarrollador, y solo entonces implementar — con la especificación persistiendo en el repositorio como memoria a largo plazo y un rastro de auditoría a medida que la aplicación evoluciona.
• OpenSpec — la opción más ligera: gratuita, con licencia MIT, vive completamente en el repositorio, no necesita clave API ni servidor MCP. Utiliza escenarios opcionales Given/When/Then y un modelo de seguimiento delta distintivo (ADDED / MODIFIED / REMOVED) construido específicamente para evolucionar una base de código existente en lugar de construcciones Greenfield.

El trabajo académico está empezando a ponerse al día con la práctica: un artículo de taxonomía de procesos de 2026 que comparaba frameworks para agents de desarrollo de software de IA encontró que el hilo común en todos ellos es separar "qué construir" de "cómo construirlo" en artefactos distintos y legibles por agent — exactamente la disciplina que el Vibe Coding omite.

Un mal prompt vs. una especificación real

La diferencia es más fácil de ver lado a lado. Aquí hay un prompt típico de Vibe Coding para una función real:

Malo: "Agrega una forma para que los usuarios exporten sus datos como un archivo CSV, haz que se vea bonito."

Entregado a un agent con acceso de escritura a múltiples archivos, ese prompt deja cada decisión real sin tomar: qué campos exportar, cómo se aplana la datos anidados o relacionados, qué sucede con exportaciones de 500,000 filas, si el endpoint necesita ámbito de autenticación, cuál debería ser el nombre del archivo y la codificación. El agent elegirá respuestas — y las elegirá de manera diferente en cada regeneración.

Aquí está la misma función como especificación, en el formato estilo EARS que tanto Kiro como Spec Kit fomentan:

Bueno:

• WHEN un usuario con una cuenta activa hace clic en "Export Data" THE SYSTEM SHALL generará un CSV que contenga las columnas: id, email, created_at, last_login, subscription_tier.
• WHEN la exportación contiene más de 50,000 filas THE SYSTEM SHALL transmitirá la respuesta en lugar de almacenarla en búfer en memoria.
• WHEN un usuario sin permiso de exportación solicita el endpoint THE SYSTEM SHALL devolverá un 403 con un cuerpo de error que coincida con el esquema de error de la API existente.
• THE SYSTEM SHALL nombrará el archivo export-{userId}-{ISO8601 date}.csv y lo codificará como UTF-8 con BOM para compatibilidad con Excel.

Nada de esto es ingeniería exótica — es el mismo pensamiento que un ingeniero competente haría en una revisión de diseño. La diferencia es que está escrito antes de que el agent comience, por lo que el agent implementa contra criterios explícitos en lugar de improvisarlos, y un revisor puede verificar el diff contra la especificación en lugar de aplicar ingeniería inversa a la intención a partir del código.

Lo que una buena especificación debe incluir

Independientemente del framework que adopte un equipo, las especificaciones que realmente se mantienen en flujos de trabajo impulsados por agentes comparten una forma común:

• Límites de alcance explícitos — lo que la función NO hace, no solo lo que hace.
• Criterios de aceptación comprobables — escritos como declaraciones WHEN/THEN o Given/When/Then que un agent (o un conjunto de pruebas) puede verificar mecánicamente, no prosa que un humano tenga que interpretar.
• Forma de datos y casos límite — esquema, nulabilidad, límites de tamaño, y qué sucede en los límites (entrada vacía, entrada máxima, acceso concurrente).
• Restricciones no funcionales — presupuestos de rendimiento, requisitos de autenticación/autorización y convenciones de manejo de errores que coincidan con la base de código existente.
• Una "constitución" o documento de dirección persistente — las reglas de todo el proyecto (estándares de prueba, patrones arquitectónicos, dependencias prohibidas) que no deberían tener que repetirse en cada especificación.
• Una puerta de aprobación humana explícita — el punto donde un desarrollador aprueba la especificación antes de que se permita al agent generar código, no después.

Conclusiones

Los equipos que adopten AI coding agents en 2026 deben tratar la especificación, no el prompt, como la unidad de trabajo de ingeniería. En concreto: elija un framework de especificaciones (OpenSpec para un inicio de baja fricción en una base de código existente, Spec Kit o Kiro si el equipo quiere un pipeline obligatorio de requisitos-diseño-tareas) y exija que cada tarea de agent con múltiples archivos comience a partir de una especificación escrita con criterios de aceptación comprobables. Mantenga un documento "constitución" permanente con las reglas arquitectónicas y de estilo que se aplican a cada función, de modo que las especificaciones solo necesiten cubrir lo que realmente es nuevo. Y construya el hábito de revisión en torno a verificar el código contra los criterios de aceptación de la especificación — no releer todo el diff línea por línea, que es exactamente el cuello de botella que el desarrollo impulsado por especificaciones está diseñado para eliminar.