Del Vibe Coding al Desarrollo Guiado por Especificaciones (SDD): Guía y Herramientas 2026 (Kiro, Spec Kit, Tessl)

Este artículo de Turing Post, firmado por Alyona Vert y Ksenia Se, aborda un debate cada vez más relevante en el desarrollo de software asistido por IA: por qué el llamado "vibe coding" —ese flujo de prompt, código generado, parche, repetir— se vuelve frágil a medida que los proyectos crecen, y cómo el Spec-Driven Development (SDD, desarrollo guiado por especificaciones) propone solucionarlo.

El texto arranca con un breve repaso histórico que ayuda a contextualizar la idea: desde la programación procedural de C o Fortran, pasando por SQL en los años 70 (donde ya se describía el resultado deseado en lugar del procedimiento exacto), hasta los intentos de Model-Driven Development y Behavior-Driven Development en los 2000. Todos estos enfoques buscaban, de una forma u otra, separar la intención (el "qué") de la implementación (el "cómo"). La era actual de asistentes de código generativo y agentes autónomos llevó esa lógica a un extremo distinto: el vibe coding, que bajó drásticamente la barrera de entrada a la programación pero introdujo un problema estructural: no existe un plan persistente, los resultados son no deterministas, los requisitos viven dispersos en el historial de chat, y las decisiones previas pueden ser sobrescritas por cambios posteriores. El resultado es arquitectura frágil y agentes que se "pierden" en tareas complejas.

La propuesta central del artículo es el SDD como término medio entre el rigor de MDD/BDD y la flexibilidad del vibe coding. La especificación pasa a ser el artefacto central y la "fuente de verdad": una descripción estructurada, versionada y legible por máquina de qué debe hacer el sistema, qué restricciones debe cumplir, cómo debe comportarse y qué historias de usuario satisface. Se cita a Marc Brooker, distinguido ingeniero de AWS especializado en IA agéntica, quien resume la idea señalando que el SDD permite al agente de código avanzar sin retroceder, dándole el contexto necesario para construir software de forma continua. Según el artículo, la especificación cumple una doble función: sirve para construir y mantener el software, y para construir la infraestructura de pruebas alrededor de él.

El flujo de trabajo se organiza en un bucle interno y un bucle externo. El interno —que un agente puede ejecutar de forma autónoma— consiste en escribir o actualizar la especificación, generar código y tests a partir de ella, ejecutar el código contra esos tests, iterar hasta que pasen, y verificar que los tests siguen alineados con la especificación original. El bucle externo pone ese software frente a usuarios reales, recoge feedback, actualiza la especificación y vuelve a disparar el ciclo interno. La verificación se integra en pipelines de CI/CD, y los ingenieros pueden definir invariantes (idempotencia, monotonicidad, consistencia de estado, etc.) que el sistema de IA estresa automáticamente generando grandes espacios de entradas. El artículo conecta esto con la IA neurosimbólica: los LLM proponen implementaciones y refactors en lenguaje natural, mientras sistemas simbólicos —solvers de restricciones, motores de reglas, métodos formales— verifican consistencia lógica.

Entre los beneficios que destaca el texto: mayor repetibilidad y escalabilidad del código, posibilidad de codificar explícitamente qué cuenta como buena o mala salida y refinarlo con el tiempo, testing y verificación integrados como parte del propio flujo, agentes capaces de operar de forma autónoma durante períodos más largos sin perderse, y cambios registrados en la especificación versionada en lugar de en un historial de chat efímero.

La segunda mitad del artículo repasa tres herramientas concretas que materializan este enfoque. Kiro, de AWS, es un IDE de IA construido explícitamente alrededor de SDD: las especificaciones se organizan como directorios de markdown estructurado, y las historias de usuario se reescriben automáticamente en formato EARS (Easy Approach to Requirements Syntax), un lenguaje controlado con patrones tipo "WHEN <disparador>, el sistema SHALL <respuesta>" que hace cada requisito directamente verificable. Kiro incorpora también property-based testing —definir propiedades generales que debe cumplir la salida en función de la entrada, en vez de casos de ejemplo manuales— y anuncia, como capacidad futura, detección de ambigüedades en la especificación mediante técnicas neurosimbólicas. El artículo recoge cifras que AWS reporta sobre el uso de Kiro: un proyecto de rearquitectura estimado en 18 meses y 30 ingenieros se completó en 76 días con 6 ingenieros, y Socure (empresa de verificación de identidad digital) completó una migración de Scala a Go de tres semanas en dos días. Conviene señalar que estas cifras provienen directamente de AWS/Kiro tal como las cita el artículo, y no de una fuente independiente verificada.

Spec Kit, de GitHub, implementa el desarrollo como un pipeline fijo de artefactos ejecutado mediante comandos de CLI: /speckit.specify, /speckit.plan, /speckit.tasks y /speckit.implement, cada uno generando un artefacto concreto que alimenta al siguiente, de modo que el agente no puede saltarse la planificación. Incluye además un archivo de "constitución" del proyecto que fija reglas persistentes (estándares de testing, presupuestos de rendimiento, estilo de código, restricciones de UX) aplicadas a todas las especificaciones futuras. La diferencia clave con Kiro es dónde reside la lógica de planificación: en Spec Kit está externalizada en comandos y artefactos explícitos, mientras que en Kiro ocurre dentro del bucle de un único agente autónomo.

Tessl, por su parte, estructura el contexto del agente como paquetes instalables: documentación versionada, reglas de estándares de codificación siempre inyectadas en el contexto, y "skills" o flujos procedimentales. Estos elementos se empaquetan en "tiles" instalables mediante un gestor de paquetes propio, y Tessl organiza el SDD en torno a tres artefactos persistentes —plan, spec y tests— que permanecen en el repositorio para que futuras ejecuciones del agente los reutilicen como contexto. Su Spec Registry, según el artículo, contiene más de 10.000 especificaciones de uso alineadas con versiones concretas de librerías, permitiendo a los agentes instalar contexto estructurado en lugar de depender solo de los datos de entrenamiento del modelo.

El artículo también matiza dónde encajan herramientas populares como GitHub Copilot, Claude Code y Cursor: aunque pueden participar en un flujo SDD, operan fundamentalmente mediante un bucle de prompt-razonamiento-código donde la especificación existe solo implícitamente en el chat, por lo que se consideran agentes de ejecución más que frameworks de SDD propiamente dichos.

Finalmente, se ofrece una guía práctica de cuándo usar SDD y cuándo evitarlo. Es más adecuado para bases de código grandes y de larga vida, equipos que usan múltiples agentes de IA (donde la especificación actúa como fuente de verdad independiente del modelo), desarrollo de producto con muchas features, y entornos empresariales donde las specs pueden codificar reglas de cumplimiento normativo y estándares de arquitectura. En cambio, resulta menos adecuado para prototipado rápido, desarrollo altamente exploratorio con requisitos cambiantes, scripts o utilidades de baja complejidad, y para investigación o desarrollo de algoritmos donde escribir la especificación podría tomar más tiempo que el propio código.

En conjunto, el artículo plantea el SDD no como un reemplazo total del vibe coding sino como una capa de disciplina y verificabilidad para escenarios donde la fiabilidad, la trazabilidad y la escalabilidad importan más que la velocidad de iteración pura, ofreciendo un panorama útil —aunque basado en gran parte en materiales y cifras proporcionados por los propios fabricantes de las herramientas mencionadas— de por dónde está evolucionando la ingeniería de software asistida por agentes de IA.