Spec-Driven Development: cuando programar deja de ser el cuello de botella

Spec-Driven Development es un enfoque en el que una especificación estructurada del estado deseado del software guía la planificación, la implementación y la validación. En lugar de pedirle a un agente que escriba código a partir de una conversación, se acuerda primero qué hay que construir, bajo qué restricciones y cómo se demostrará que funciona.

Eso es la definición. Lo interesante empieza al preguntarse por qué aparece justo ahora, si especificar software no tiene nada de nuevo.

Ha cambiado quién lee la especificación. Durante treinta años la escribíamos para una persona, que la interpretaba con todo el contexto que llevaba en la cabeza y rellenaba en silencio los huecos que el documento se había dejado abiertos. Ahora la consume el sistema que ejecuta el trabajo.

Qué es Spec-Driven Development, y qué no es

Empecemos por la escena que todo el mundo reconoce. Alguien le pide a un agente que añada autenticación con Google. En dos minutos hay cuatrocientas líneas funcionando. Compilan. Y en el minuto tres llegan las preguntas que nadie hizo: qué pasa con los usuarios que ya existían, cuánto dura la sesión y qué la invalida, qué ocurre cuando Google no responde, y quién tiene permiso para invitar a quién.

El código nunca fue el problema. Nunca. El problema era definir el sistema con la precisión suficiente para que nadie tuviera que adivinar, y eso no lo arregla escribir un prompt mejor ni sumar a alguien que los escriba mejor todavía.

La diferencia entre trabajar por prompts, lo que el sector ya llama vibe coding, y trabajar por especificación no está en la longitud del texto que le pasas al agente, sino en dónde vive la intención: en un sitio que otra persona pueda abrir mañana y entender sin haber estado en la conversación original, o evaporándose con la pestaña del navegador.

El equipo de Microsoft lo formula con una imagen que funciona: la especificación como tejido conectivo. En su artículo del 10 de junio de 2026, Apoorv Gupta la describe como el elemento que une la intención de negocio con la arquitectura, la implementación y la validación.

Conviene decir también lo que no es. No es waterfall con otro nombre. Ni de lejos. Tampoco es documentar cuarenta páginas antes de escribir la primera línea de código, que es la objeción que aparece siempre en cuanto se menciona la palabra especificación delante de un equipo que lleva diez años trabajando en iteraciones cortas: una especificación útil para una funcionalidad pequeña cabe en unas decenas de líneas, con objetivo, requisitos, restricciones, casos límite, criterios de aceptación y qué queda fuera de alcance.

Con la escena del principio, la de la autenticación con Google, una especificación suficiente cabe en esto:

# Objetivo
Permitir que una persona acceda con su cuenta de Google.

# Requisitos
- Quien no tenga cuenta previa, se registra en el mismo flujo.
- Quien ya exista con ese correo, vincula Google a su cuenta actual.
- La sesion dura 30 dias y se invalida al cerrar sesion.

# Restricciones
- No se crean organizaciones en este alcance.
- El correo verificado por Google es el identificador; no se pide contrasena.

# Casos limite
- Google no responde o devuelve error: mensaje y vuelta al login, sin cuenta a medias.
- El correo ya existe con contrasena: se vincula, no se duplica.
- Quien entra desde una URL protegida vuelve a ella despues de autenticarse.

# Criterios de aceptacion
- Alguien sin cuenta entra con Google y aterriza autenticado.
- Alguien con cuenta previa entra con Google y conserva sus datos.
- Cerrar sesion invalida el token: recargar exige volver a entrar.
- Un fallo de Google no deja registros a medias en la base de datos.

# Fuera de alcance
- Otros proveedores de identidad.
- Roles y permisos.
- Recuperacion de cuenta.

22 líneas. Y ya no queda nada que el agente tenga que adivinar, que es todo el objetivo.

Donde esto se vuelve tangible es en la herramienta. GitHub Spec Kit lo convierte en un proceso ejecutable: se declara una constitución de principios del proyecto, se escribe la especificación, se genera el plan, se descompone en tareas y se implementa, con pasos opcionales para clarificar lo ambiguo antes de tocar código.

Solo el 0,23 % de las ofertas tech en España nombra un agente de codificación

Hasta aquí la teoría, que está bien contada en inglés y ya la firman GitHub, Microsoft, IBM y Martin Fowler. El hueco está en otro sitio: nadie ha mirado si esto ha llegado al mercado laboral. Lo medimos con nuestro propio sistema de análisis del mercado tech, el mismo con el que censamos qué pide de verdad una oferta de AI Engineer en España.

Sobre 22.986 ofertas activas en España entre el 14 de junio y el 23 de agosto de 2026, buscamos las que piden explícitamente un agente de codificación entre las competencias del puesto. Son 52 ofertas distintas, de 31 empresas. Dos de cada mil.

La cifra, dicha con precisión para que no se cite mal: el 0,23 % de 22.986 ofertas tech publicadas en España entre el 14 de junio y el 23 de agosto de 2026 menciona explícitamente una herramienta de agente de codificación, en concreto Claude Code, Cursor o GitHub Copilot, entre las competencias del puesto. Este dato no mide la adopción de Spec-Driven Development, que es una metodología y no una herramienta, y que no aparece de forma medible en las descripciones de puesto. Mide mención de herramienta en la oferta de empleo, que es un indicador tardío de lo que ya se hace dentro del equipo.

La comparación que importa es la de arriba con la de abajo. Los marcos para construir IA se piden entre diez y trece veces más que los agentes para construir con IA, lo que significa que las empresas españolas ya tienen interiorizado que necesitan gente capaz de montar un sistema con modelos de lenguaje dentro, y todavía no han llegado a asumir que su propia forma de escribir software también cambia.

Ese desfase tiene un coste medido. En su estudio Build for the Future 2025, de septiembre de 2025 y sobre más de 1.250 empresas, BCG encontró que solo el 5 % obtiene valor de la IA a escala y que el 60 % no obtiene valor material alguno, con ganancias mínimas de ingreso y de coste pese a haber invertido. Ese es el implementation gap. Y la capacidad que falta ahí no es la de construir modelos. Es la de definir bien qué debe hacer el sistema y demostrar después que lo hace.

La concentración refuerza la lectura: 52 ofertas repartidas entre 31 empresas, con dos aportando seis cada una. Esto no es adopción de mercado, es un grupo pequeño de empresas que ya escribe en la oferta lo que hace por dentro, y la diferencia entre esas dos cosas es la que separa una tendencia real de una que solo existe en las conferencias.

Hay una señal más fina en los títulos. Cinco ofertas nombran el cambio en el propio encabezado del puesto: AstraZeneca busca en Barcelona un Senior Software Engineer para AI-Native Development, SEPTEO publica un Full Stack al que llama AI-First Developer, y Joppy tiene abiertos un Forward Deployed Engineer y un puesto de Agentic AI.

Una advertencia sobre el método, que es la parte que casi nunca se publica. La búsqueda por texto libre de "spec-driven development" devuelve 27 ofertas, y entre ellas hay un frontend de Angular que no tiene nada que ver: el buscador engancha la palabra development. Ese 27 no es citable. No lo usamos. Las cifras de la tabla salen del campo de competencias etiquetadas y están filtradas por localización, porque el conjunto trae ofertas italianas mezcladas: de las 49 que etiquetan Claude Code, 15 estaban en Italia.

Y una cautela de interpretación. Que una competencia no figure en la oferta no significa que no se use dentro. Las descripciones de puesto van por detrás de la práctica. Casi siempre por meses.

Dónde se ha movido el cuello de botella

El activo escaso fue durante mucho tiempo la capacidad de producir código. Cuando eso era caro tenía sentido organizar los equipos y las entrevistas alrededor de esa escasez: se preguntaba por años con un framework porque los años con un framework predecían razonablemente bien la velocidad de producción, y durante dos décadas esa correlación aguantó lo suficiente como para que nadie la cuestionara en serio.

Con agentes que generan volúmenes grandes de código correcto en minutos, esa escasez se desplaza, y lo que queda escaso es otra cosa: la capacidad de reducir la ambigüedad.

Eso incluye entender el problema antes de resolverlo, traducir una necesidad de negocio a condiciones comprobables, ver cómo un cambio afecta al resto del sistema, anticipar los casos límite que nadie mencionó en la reunión y decidir si el resultado está terminado. Ninguna de esas cosas la resuelve un agente solo. Todas dependen de contexto que no está en el repositorio, sino repartido entre una conversación con negocio, una decisión que se tomó hace dos años y un compromiso con un cliente que nadie escribió en ningún sitio.

Y conviene separar dos capacidades que se confunden. Una es redactar la especificación, que es oficio y se aprende. La otra es decidir qué entra en ella, que es criterio y se acumula. La segunda es la que se está encareciendo, y explica por qué han empezado a aparecer roles definidos justo ahí, como el product engineer.

Qué cambia para quien monta el equipo

Tres consecuencias. La primera es la más incómoda.

Más código no es más producto. Nunca lo fue. Un equipo con agentes puede generar mucho más software y a la vez acumular más deuda técnica, más superficie de ataque y más funcionalidades que nadie pidió. Los agentes son extraordinariamente eficientes construyendo lo que no hacía falta, y esa eficiencia aplicada a un objetivo mal definido produce exactamente el mismo resultado que la lentitud, con la diferencia de que llega antes y ocupa más sitio.

La segunda es que el cuello de botella sube en la cadena. Si la implementación se abarata, el trabajo se acumula antes y después, en definir bien y en verificar que lo construido corresponde a lo definido, que son las dos partes que ningún agente cierra por su cuenta.

La tercera es que cambia la pregunta con la que se abre un puesto. Deja de ser cuántos años lleva alguien con una tecnología y pasa a ser si puede coger un problema ambiguo, convertirlo en un sistema bien definido, construirlo con agentes y demostrar que el resultado es correcto. Son dos preguntas distintas. No las responde el mismo currículum.

Hay un efecto de estructura que conviene decir con prudencia, porque es donde más se especula. Si los agentes absorben parte de la ejecución mecánica, un proyecto puede necesitar menos capacidad puramente productiva y más perfiles con criterio sobre el resultado. Favorece blended teams: un núcleo estable con acceso a especialistas en los momentos donde el criterio es caro, sean de arquitectura, seguridad, datos o producto. Es el mismo reparto que hace falta cuando se montan agentes de IA en una empresa. No es una predicción. Es la dirección del desplazamiento.

Qué cambia para quien hace el trabajo

La lectura fácil es que la IA sustituye a los desarrolladores. No es lo que dicen los datos ni lo que dice la práctica. Lo que cambia es el contenido del trabajo, que es una afirmación bastante menos espectacular y bastante más exigente para quien tiene que reorganizar su carrera alrededor de ella.

El recorrido de siempre iba de un ticket a un commit. Poco más. El que empieza a valer arranca en un problema mal planteado por alguien que no es técnico y termina en un resultado demostrable, y por el camino hay que clarificar lo pedido, escribir la especificación, decidir la arquitectura, repartir trabajo entre agentes y evaluar si el problema quedó resuelto.

Las competencias que ganan peso son concretas. Entender el producto lo suficiente para preguntar por qué se construye algo antes de construirlo. Dar al agente el contexto correcto, que es un oficio propio y se aprende haciéndolo mal unas cuantas veces. Y distinguir entre que el agente produjo código y que el problema está resuelto, que no es lo mismo y se parece mucho.

Hay una asimetría interesante en esto. Lo que un agente hace bien se aprende de un tutorial. Lo que no hace es lo que solo se acumula habiendo tomado decisiones y habiéndose equivocado en algunas. La experiencia deja de valer por las herramientas que has tocado y empieza a valer por los problemas que has cerrado, que es una forma bastante más incómoda de medirse porque no se puede rellenar con un curso de fin de semana.

Cuándo no hace falta una spec, y cómo probarlo

Añadir estructura cuesta, y se nota desde el primer minuto, así que la pregunta de cuándo no aplica es legítima. El vibe coding no se muere con esto: sigue siendo lo correcto para experimentar, para prototipar algo y verlo en pantalla, o para montar una herramienta interna que van a usar tres personas. Nadie necesita criterios de aceptación para un script que corre una vez.

Kiro, construido y operado por AWS, está montado sobre esa idea: ofrece un modo conversacional y otro por especificación, y deja elegir. Su documentación nombra dos señales. Una es que más de una persona necesite entender el código. La otra es que alguien vaya a depender del sistema en producción.

Le añadiríamos una tercera por experiencia propia: cuando hay más de un agente sobre el mismo código. Sin artefacto compartido, dos agentes resuelven la misma ambigüedad de formas distintas. Y ninguno se entera.

Para probarlo, cuatro pasos.

1. Elegir una funcionalidad real y pequeña, no el proyecto crítico del trimestre.
2. Escribir la especificación corta.
3. Pedirle al agente el plan y no el código. Es el paso que todo el mundo se salta y el que da la información, porque si el plan no tiene sentido la especificación estaba mal, y descubrirlo ahí cuesta cinco minutos en vez de dos días.
4. Validar contra los criterios que se escribieron al principio.

Lo que esto dice del mercado, más allá del código

Spec-Driven Development es útil como método. Es más interesante como síntoma.

Lo que señala es que la IA está moviendo el valor profesional desde ejecutar instrucciones hacia definir, dirigir y verificar sistemas capaces de ejecutarlas. Y eso no se queda en la forma de programar: afecta a cómo se diseñan los equipos, a qué se evalúa en una entrevista y a qué se mide exactamente cuando alguien dice que va a medir la productividad de un equipo de ingeniería.

Nuestros números dicen que ese cambio todavía no ha llegado a la descripción del puesto en España. El 0,23 % es pequeño, y es exactamente el punto: la conversación va muy por delante de la práctica declarada, así que quien lo interiorice ahora lo hace sin competencia por ese perfil.

Para una empresa, la ventaja no estará en tener acceso a la IA, que será tan corriente como el alojamiento en la nube. Estará en tener a las personas capaces de dirigirla con criterio. Y como ese criterio hace falta en momentos concretos del problema y no de forma continua durante todo el año, el acceso a especialistas en la fase exacta donde el criterio es caro empieza a importar más que la capacidad de ampliar la plantilla.

Para quien hace el trabajo, la conclusión es más directa. Durante años una parte grande del valor de un perfil técnico estaba en convertir requisitos en código. Los agentes han abaratado esa conversión de forma brusca. Y rápida. El experto que destaque no será el que más código produzca, sino el que mejor sepa decidir qué debe existir, usar agentes para construirlo y demostrar que lo construido es correcto.

Preguntas frecuentes sobre Spec-Driven Development

¿En qué se diferencia de escribir prompts más detallados?

En que la especificación es un artefacto persistente y versionado, no un mensaje: sobrevive a la sesión de chat, la puede revisar otra persona y sirve de referencia para validar el resultado. Un prompt largo sigue dejando la intención en un historial que nadie vuelve a leer.

¿No es volver a waterfall?

No, porque no se especifica el sistema entero antes de empezar, sino la unidad de trabajo que toca, con el detalle justo para que el agente no tenga que inventar, y se itera. La especificación se trata como código: se versiona y se cambia.

¿Cuánto debe medir una especificación?

Lo justo para que no quede ambigüedad sobre lo que hay que construir y cómo se comprueba. Para una funcionalidad pequeña, unas decenas de líneas: objetivo, requisitos, restricciones, casos límite, criterios de aceptación y qué queda fuera de alcance. El objetivo no es documentar, es eliminar las decisiones que el agente tomaría por su cuenta.

¿Sirve con cualquier agente de codificación?

Sí. GitHub Spec Kit declara compatibilidad con más de treinta agentes distintos, y el enfoque no depende de la herramienta: es una forma de ordenar el trabajo, no un producto. Kiro, el entorno de AWS, implementa la misma idea con dos modos, uno conversacional y otro por especificación.

¿Se pide ya Spec-Driven Development en las ofertas de empleo en España?

Prácticamente no. Sobre 22.986 ofertas tech activas en España entre el 14 de junio y el 23 de agosto de 2026, solo 52 nombran algún agente de codificación entre las competencias del puesto, el 0,23 %, y se concentran en 31 empresas. La metodología como tal no aparece de forma medible en las descripciones de puesto.