Desarrollo guiado por especificación: la práctica en la que convergió la categoría

Todas las herramientas serias de programación con IA publicaron la misma función con menos de un año de diferencia entre ellas, algo que casi nunca ocurre por accidente.

En 2025 la pregunta interesante era cuánto estaban mejorando los modelos. En 2026 la pregunta interesante es qué les entregas.

GitHub publicó Spec Kit. AWS publicó Kiro, un IDE construido alrededor de la idea. BMAD-METHOD, OpenSpec y Tessl lo intentaron cada uno por su lado. Cursor llegó ahí a través de los archivos de reglas. Martin Fowler ha publicado una comparación de las implementaciones. Cuando seis equipos independientes convergen en la misma respuesta en doce meses, no se están copiando. Todos están chocando con el mismo muro.

El muro ya tiene nombre. Y la solución también.

Qué es realmente el desarrollo guiado por especificación

Escribe los requisitos, las restricciones y los criterios de éxito antes de generar cualquier código. Trata ese documento como la fuente de verdad. Deja que el agente construya contra él.

Eso es todo. No es una idea nueva: es ingeniería de requisitos, algo que la industria pasó treinta años haciendo mal y después abandonó en buena medida por ser demasiado lento. Lo que cambió no es el concepto. Es la economía.

Las especificaciones eran caras de escribir y caras de mantener al día, lo que significaba que la mayoría de los equipos escribía los trazos gruesos y descubría todo lo demás en la revisión de código. Ese era un intercambio racional cuando construir la función llevaba tres semanas de todas formas. Dejó de ser racional cuando la generación se volvió rápida, porque ahora la especificación es la parte lenta, y la parte lenta es donde vive todo el criterio.

El modo de fallo contra el que se inventó

Las herramientas que empiezan por el prompt se saltan la especificación por completo. Describes un resultado, la herramienta produce algo que se le parece, y cada decisión que la descripción no cubría la toma el generador en silencio.

¿Qué decisiones? Las que resultan importar. Si una dirección de correo es única, y única respecto a qué. Qué puede seguir viendo una cuenta cancelada. Qué pasa cuando dos personas editan el mismo registro. Si esa lista necesita paginación antes de tener diez mil filas.

Nadie hizo esas preguntas, así que nadie las respondió, pero la aplicación tiene una respuesta para cada una, elegida por inferencia a partir de un contexto que nunca incluyó tu negocio.

La misma dinámica aparece en toda herramienta que se salta el paso de definición. Es el mecanismo detrás del problema del 70%: el progreso se estanca no porque el trabajo restante sea difícil, sino porque está bloqueado por una decisión arquitectónica tomada de forma implícita, cientos de generaciones antes, que ya no se puede cambiar sin desarmar el sistema.

Los datos de lo que pasa sin ello

El informe State of AI-assisted Software Development de DORA de 2025 es la lectura más clara disponible. El 90% de los profesionales de tecnología usa ya IA en el trabajo y más del 80% cree que ha aumentado su productividad. Y una mayor adopción de IA se asocia con un aumento del rendimiento de entrega de software y con un aumento de la inestabilidad de esa entrega, al mismo tiempo.

Más rápidos lanzando. Peores manteniendo las cosas funcionando. Las dos cosas, juntas.

El análisis de GitClear de 2026 sobre 623 millones de cambios de código muestra la forma del daño. Contra la línea base de 2023: bloques de código duplicados un 81% arriba, el copiar y pegar dentro de un mismo commit subiendo del 9,4% en 2022 al 15,7% en la primera mitad de 2026, construcciones que enmascaran errores un 47% arriba. Mientras tanto, las llamadas a funciones entre archivos (el mejor indicador disponible de reutilización de código) un 35% abajo, y la actividad de refactorización desplomada del 21% de los cambios en 2022 al 3,8% en 2026.

Quienes desarrollan tienen ahora unas cinco veces más probabilidades de copiar y pegar que de refactorizar. En 2022 esa proporción iba en el sentido contrario.

Nada de eso es un problema de calidad del modelo. Es lo que pasa cuando generar es barato y la estructura no es el trabajo explícito de nadie.

Los tres grados de compromiso

No todo el mundo quiere decir lo mismo con esto, y las diferencias importan en la práctica. El encuadre de Martin Fowler es el más limpio que he visto.

Especificación primero. Escribes la especificación, generas a partir de ella y después mantienes el código a mano. La especificación dirige la construcción inicial y luego se convierte poco a poco en documento histórico. Lo más fácil de adoptar, las garantías más débiles: seis meses después, el documento describe un sistema que ya no existe.

Especificación anclada. La especificación y el código evolucionan juntos. Cambias la especificación, regeneras las partes afectadas, mantienes ambas al día. Más disciplina, y la recompensa es que el documento sigue siendo fiable.

Especificación como fuente. La especificación es el único artefacto que editas. El código es salida, igual que un binario compilado es salida: no lo parcheas a mano. Las garantías más fuertes, y el salto más grande en cómo trabaja un equipo.

La mayoría de los equipos que se llaman guiados por especificación están haciendo especificación primero. Eso es una mejora real sobre lanzar prompts a ciegas, y es también la versión que se degrada en silencio.

Qué va en la especificación

La prueba útil: si el generador tendría que adivinarlo, va en el documento.

• El modelo de datos. Entidades, relaciones, cardinalidad, qué hace único a un registro, qué pasa al borrar. Es la sección de mayor valor y la que más a menudo se salta.
• Tipos de usuario y permisos. Quién existe, qué puede ver y hacer cada uno, qué pasa en los límites.
• Los invariantes. Reglas que nunca deben violarse, dichas sin rodeos. No “gestionar los errores con elegancia”: eso es un deseo, no una restricción.
• Criterios de éxito. Cómo sabrás que la cosa funciona, en términos lo bastante concretos como para que un desacuerdo sobre si funciona sea resoluble.

Qué no va: detalle de implementación que el generador elige mejor que tú. Una especificación que nombra variables no es una especificación, es código con peores herramientas.

La parte que todo el mundo hace mal

Una especificación solo ayuda si se puede hacer cumplir en algún sitio que no sea la prosa.

Si una restricción vive solo en el documento, es una sugerencia. El generador la leyó una vez y puede que la haya respetado o no en el decimocuarto archivo que tocó. Las restricciones tienen que acabar en algún lugar que el sistema compruebe: not-null y unique en la base de datos y no en un manejador de formulario, tipos en los límites y no en un comentario, autorización como una política que el sistema evalúa y no como una condición que alguien se acordó de escribir.

Esta es la diferencia entre el desarrollo guiado por especificación como práctica y el desarrollo guiado por especificación como género literario. El documento es cómo decides. La aplicación efectiva es cómo mantienes la decisión.

Cómo saber si de verdad lo estás practicando

Cuatro preguntas, y son incómodas a propósito.

1. Cuando algo se rompe, ¿arreglas el código o la especificación? Si la respuesta es siempre el código, estás haciendo especificación primero en el mejor de los casos y el documento ya está obsoleto.
2. ¿Podría alguien nuevo leer la especificación y predecir cómo se comporta el sistema? Si tendría que leer el código para saberlo, la especificación es un resumen y no una fuente.
3. ¿Hay algo en la especificación que el sistema no pueda violar? Si todas las reglas son prosa, ninguna está garantizada.
4. ¿Revisas la especificación o el diff? Revisar miles de líneas de código generado es teatro. Discute sobre el documento mientras discutir sigue siendo barato.

Dónde deja esto a las herramientas

La mayoría de las implementaciones actuales están guiadas por especificación para la generación de código en concreto. Producen una especificación y generan una implementación contra ella, y el artefacto sobre el que operan es una base de código.

La versión más difícil extiende la misma lógica a toda la aplicación (el modelo de datos, la superficie de API, la frontera de autenticación, la interfaz) de modo que la especificación cubre no solo qué hace el código sino qué es el sistema. Eso es lo que es la fase de blueprint de Archie, y es por lo que la describo como desarrollo guiado por especificación aplicado al stack completo en lugar de a un repositorio. Alcance distinto, mismo principio: definir antes de generar.

Personas razonables discrepan sobre hasta dónde llevarlo. Nadie serio defiende volver atrás.

Qué cuesta

Adelantar el criterio es más lento durante la primera semana de un proyecto y más rápido en todas las semanas siguientes. Ese coste es real y se paga exactamente en el momento en que el impulso parece más valioso, mientras un competidor lanza algo visible. Habrá sprints en los que el equipo que se saltó esto parezca ir ganando.

La disciplina también se degrada. Escribir restricciones es menos divertido que ver aparecer una interfaz, y revisar un documento es menos satisfactorio que revisar código. Estos hábitos se erosionan bajo presión de plazos, que es la misma presión que los hace importar.

Y genuinamente no se aplica a todo. Si estás validando una idea este fin de semana con intención de tirar el resultado, tíralo. Nada de esto merece la pena para software con dos días de vida.

La razón por la que esto se quedó

Todo intento anterior de hacer que los equipos escribieran especificaciones primero fracasó, y fracasó por una buena razón: la especificación era sobrecarga encima del trabajo real. Escribías el documento y después seguías teniendo que construir la cosa.

Ese ya no es el intercambio. Ahora el documento es la mayor parte del trabajo, y la construcción es la parte barata. Seis equipos independientes se dieron cuenta de esto en menos de un año porque era la consecuencia obvia de que el modelo se pusiera bueno.

La práctica no ganó una discusión. La economía se movió por debajo.

Lecturas relacionadas

El diagnóstico original: el vibe coding rompió su promesa. Hacia dónde fue la categoría después: qué viene después del vibe coding. El mismo argumento aplicado a sistemas completos: diseño de software AI-first desde primeros principios. Y el encuadre más antiguo de la misma idea: dejar de escribir el software dos veces.

Preguntas frecuentes

¿Qué es el desarrollo guiado por especificación? Escribir los requisitos, las restricciones y los criterios de éxito antes de generar cualquier código, y tratar esa especificación como la fuente de verdad contra la que construye el agente de IA. Surgió en 2025 y 2026 como respuesta directa a los flujos de trabajo que empiezan por el prompt y se saltan el paso de definición.

¿En qué se diferencia de los documentos de requisitos tradicionales? El concepto es el mismo; la economía no. Las especificaciones tradicionales eran lo bastante caras como para que los equipos escribieran los trazos gruesos y descubrieran el resto durante la implementación. Cuando redactar una lleva horas en lugar de meses y se puede revisar de forma barata, merece la pena terminarla y merece la pena mantenerla al día.

¿Qué herramientas soportan el desarrollo guiado por especificación? GitHub Spec Kit, AWS Kiro, BMAD-METHOD, OpenSpec y Tessl son las implementaciones con nombre, y Cursor soporta una versión más ligera a través de archivos de reglas. Se diferencian sobre todo en cuán fuerte es la unión entre la especificación y el código: si dirige la generación una vez, si evoluciona junto a él, o si es el único artefacto que editas.

¿Cuáles son los tres grados del desarrollo guiado por especificación? Especificación primero, donde la especificación dirige la construcción inicial y mantienes el código a mano. Especificación anclada, donde especificación y código evolucionan juntos. Especificación como fuente, donde la especificación es lo único que editas y el código se trata como salida. La mayoría de los equipos que lo practican están haciendo especificación primero.

¿El desarrollo guiado por especificación frena a los equipos? Reubica el trabajo en lugar de añadirlo. Las decisiones de una especificación se toman o deliberadamente al principio o de forma implícita por un generador que adivina después, y el segundo camino es de donde viene el retrabajo. Es más lento la primera semana y más rápido después.

¿Qué debería ir en una especificación? Cualquier cosa que el generador tendría que adivinar en otro caso: el modelo de datos con relaciones y reglas de unicidad, los tipos de usuario y permisos, los invariantes que nunca deben violarse, y criterios de éxito lo bastante concretos para zanjar un desacuerdo. Deja fuera el detalle de implementación que el generador elige mejor que tú.

¿El desarrollo guiado por especificación es lo mismo que el diseño AI-first? El desarrollo guiado por especificación es la práctica de definir antes de generar. El diseño AI-first es el conjunto más amplio de consecuencias arquitectónicas, que cubre también dónde se hacen cumplir las restricciones, el orden en que tomas las decisiones y diseñar para consumidores agénticos además de humanos.