Dejar de escribir el software dos veces: desarrollo guiado por especificación y el fin de las reescrituras
Por qué el software siempre se ha escrito dos veces (una en especificaciones y otra en código) y por qué esa segunda escritura está por fin desapareciendo.
En el desarrollo de software, cuando se hace bien, hay que escribir el software dos veces: primero, en especificaciones detalladas que explican exactamente qué debe hacer el software, y después otra vez como código que da vida a esas especificaciones. Pero aquí va una verdad incómoda: rara vez se hace bien la primera vez.
El proceso se rompe a menudo porque crear especificaciones exhaustivas consume tiempo, y los equipos casi nunca capturan todos los detalles necesarios de antemano. Eso lleva a huecos, suposiciones y retrabajo costoso. Como resultado, los proyectos de software se pasan de presupuesto, incumplen plazos y dejan a todo el mundo frustrado.
Los costes ocultos de escribir el software dos veces
Para entender por qué escribir el software dos veces es necesario pero rara vez se hace bien, desglosemos las dos fases:
1. La primera escritura: especificaciones en lenguaje natural
La primera vez que se escribe el software no estamos escribiendo código en absoluto. Se están creando requisitos, historias de usuario y documentos de diseño, redactados en lenguaje natural. Aquí es donde los equipos describen cómo debería funcionar el software, qué pueden hacer los usuarios y cómo debería ser la experiencia.
Pero aquí está el problema: ningún equipo tiene nunca el lujo de escribir todos los detalles. Quienes llevan producto a menudo tienen que correr para cumplir plazos agresivos, y algunos proyectos ni siquiera cuentan con perfiles profesionales de producto. Esbozan los trazos gruesos, pero se quedan fuera funciones e interacciones clave. Como dijo Steve Jobs en una frase célebre, “los grandes productos se hacen con 5.000 decisiones pequeñas”, pero en la mayoría de los proyectos no tomamos esas decisiones de antemano. Se dejan para que alguien de desarrollo las interprete después, lo que lleva al segundo paso.
2. La segunda escritura: traducir especificaciones a código
Una vez entregadas las especificaciones, quienes desarrollan son responsables de convertir esas descripciones en código funcional. Pero cuando la primera “escritura” está incompleta, tienen que usar su imaginación para rellenar los huecos. Se hacen suposiciones y, aunque dominen la tecnología, puede que no tengan la imagen completa de la visión del producto.
Aquí es donde afloran los problemas:
- Los detalles que faltan generan fricción: cuando los equipos de producto no especifican una función o un caso de uso importante, desarrollo tiene que adivinar o improvisar. Eso suele acabar en funcionalidad que no cumple las expectativas.
- Las suposiciones generan retrabajo: al rellenar los huecos, se pueden construir funciones de formas que no se alinean con la visión del producto, causando retrabajo masivo más adelante en el proyecto.
- Señalar con el dedo se vuelve inevitable: a medida que los plazos se escurren y los presupuestos se desbordan, los equipos se echan la culpa. Producto acusa a ingeniería de “no entenderlo”, mientras ingeniería señala a producto por especificaciones poco claras.
El resultado es una cascada de problemas que llevan a plazos incumplidos, presupuestos desbordados y resultados insatisfactorios. La investigación CHAOS del Standish Group ha documentado durante años que la mayoría de los proyectos de software se pasan de presupuesto e incumplen sus fechas de entrega. Un estudio de McKinsey con la Universidad de Oxford encontró que los grandes proyectos de tecnología se pasan de media un 45% del presupuesto y un 7% del tiempo, entregando un 56% menos de valor del previsto, y que el 17% de los grandes proyectos de tecnología van tan mal que amenazan la propia existencia de la empresa.
Claramente, algo en este proceso está roto.
La práctica ya tiene nombre
La industria se decidió por un término para esto mientras la mayoría discutía sobre prompts: desarrollo guiado por especificación. Escribe primero los requisitos, las restricciones y los criterios de éxito. Trata esa especificación como la fuente de verdad. Deja que el agente construya contra ella.
GitHub publicó Spec Kit. AWS publicó Kiro. BMAD-METHOD, OpenSpec y Tessl lo intentaron todos. Martin Fowler lo ha documentado. La convergencia no es casualidad: es lo que pasa cuando toda una categoría descubre el mismo modo de fallo al mismo tiempo.
Y el modo de fallo es el descrito arriba. Las herramientas que empiezan por el prompt se saltan la primera escritura por completo. Van directas a la segunda, adivinando cada decisión que la especificación nunca tomó. Lo cual está bien para una demo y es ruinoso para un producto.
El desarrollo guiado por especificación no elimina la primera escritura. Hace que la primera escritura sea la única que requiere criterio humano.
La nueva primera escritura: especificaciones que puedes terminar de verdad
Esto es lo que cambia. La razón por la que nadie escribía especificaciones completas nunca fue que no quisieran: era que el trabajo era demasiado lento para justificarlo. Semanas de descubrimiento para producir un documento que se quedaba obsoleto al contacto con el primer sprint. Así que los equipos escribían los trazos gruesos y dejaban las 5.000 decisiones pequeñas para descubrirlas después, una interpretación a la vez.
Cuando redactar una especificación lleva horas en lugar de meses, la aritmética se invierte. Puedes permitirte ser exhaustivo. Requisitos funcionales, diseño visual, modelo de datos, casos límite: capturados antes de que nadie abra un editor, y lo bastante baratos de revisar cuando aprendes algo.
Esa última parte importa. Una especificación que no se puede revisar de forma barata se convierte en una mentira en el momento en que llega la realidad. Este es el mismo instinto que hay detrás de construir API-first: acierta las decisiones que soportan el peso antes de que nadie escriba una pantalla, y el resto se sigue.
La nueva segunda escritura: generación de código, no traducción
Una vez completa la especificación, la segunda escritura deja de ser un problema de traducción. Se convierte en un problema de generación. Lenguajes estándar: JavaScript, TypeScript, Python. Frameworks estándar: React, Next.js. Código real, en las formas que ya se conocen, derivado de un documento que ya tomó todas las decisiones.
La diferencia no es que quienes desarrollan trabajen más rápido. Es que dejan de hacer la parte que nunca fue ingeniería: la reformulación mecánica de decisiones que alguien más ya había tomado.
Qué cambia aguas abajo
Tres cosas cambian a la vez:
- La primera escritura se termina: cuando el trabajo de especificación cuesta horas en lugar de meses, los equipos pueden permitirse tomar las decisiones pequeñas de antemano en lugar de descubrirlas en revisión.
- Nadie rellena huecos: el código generado a partir de una especificación completa no exige que nadie adivine qué quería decir el equipo de producto. Adivinar fue siempre de donde venían los defectos.
- El retrabajo deja de acumularse: la intención y la implementación arrancan alineadas. Lo que antes era una reescritura se convierte en una edición de la especificación.
El futuro de escribir software: lenguaje natural
Desde que existe el software, el trabajo exigía escribirlo dos veces: una en lenguaje natural y otra en código. Esa segunda escritura nunca fue la parte valiosa. Era el peaje que pagábamos porque no había otro camino.
Este es el movimiento alrededor del cual se organiza la siguiente generación de constructores de aplicaciones con IA: claridad antes que código. Describe la aplicación como un blueprint, acierta la arquitectura, deja que el código se genere contra ella. No es un atajo que evita el trabajo de definición, es una razón para hacerlo por fin como se debe.
Ahora hay otra forma. El software siempre debió escribirse una sola vez.
Lecturas relacionadas
La guía completa de la práctica: desarrollo guiado por especificación. Por qué la generación que empezaba por el prompt se saltó este paso está en el vibe coding rompió su promesa, y qué lo reemplaza en qué viene después del vibe coding.
Preguntas frecuentes
¿Qué es el desarrollo guiado por especificación? El desarrollo guiado por especificación consiste en 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 como respuesta directa a los flujos de trabajo que empiezan por el prompt y se saltan el paso de definición por completo.
¿En qué se diferencia del documento de requisitos tradicional? El documento es la misma idea; la economía no. Las especificaciones tradicionales eran lo bastante caras como para que los equipos escribieran los trazos gruesos y descubrieran el resto en revisión de código. Cuando una especificación 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 al código, o si es el único artefacto que editas.
¿El desarrollo guiado por especificación frena a los equipos? Mueve el trabajo, no lo añade. Las decisiones capturadas en una especificación son decisiones que alguien toma de todas formas: o deliberadamente al principio, o de forma implícita cuando alguien de desarrollo o un modelo adivina después. El segundo camino es de donde viene el retrabajo.
¿Qué pasa con quienes desarrollan si el código se genera a partir de especificaciones? Desaparece la reformulación mecánica de las decisiones de otra persona. El criterio sobre arquitectura, compromisos, corrección y qué no construir no desaparece. Esas fueron siempre las partes que requerían ingeniería.
