Spec-Driven Development: si la IA escribe los tests, ¿para qué nos pagan a los QA?

Spec-Driven Development es lo más mencionado en tecnología desde hace meses. La explicación que circula es siempre la misma: escribes una spec detallada, una IA genera el código, esa misma IA genera los tests, y el equipo de testing se libera para “tareas más estratégicas”.

Casi nadie aclara qué significan exactamente esas tareas más estratégicas cuando ya no es el QA quien escribe los tests. Es la pregunta incómoda que ningún hilo entusiasta de LinkedIn se anima a responder:

Esa pregunta hay que contestarla sin esquivar, antes de hablar de productividad 10x o de cualquier otra promesa de las landing pages. Porque la respuesta determina si SDD eleva al QA al rol que siempre debió tener — o lo entierra debajo de un proceso que no entendió a tiempo.

Te cuento qué cambia, qué no cambia, y dónde van a vivir los bugs caros del próximo ciclo.

Primero — qué es SDD (y qué tiene que ver con QA)

Para que estemos en la misma página antes de meternos en el lío.

¿Qué es una spec en este contexto? No es un user story de Jira. No son tres bullet points con criterios de aceptación. Es un documento estructurado — normalmente en YAML, Markdown o un lenguaje específico de dominio (DSL) — que describe con precisión qué hace un componente del sistema: qué inputs recibe, qué outputs produce, qué errores devuelve, qué condiciones de borde maneja, qué reglas de negocio aplica. Cuando se hace bien, es la documentación más detallada que tu sistema haya tenido nunca.

¿Quién la escribe? Hoy la respuesta varía según el equipo: a veces el dev, a veces el product owner, a veces un arquitecto. Y ahí ya tenemos el primer problema. En equipos maduros con SDD, escribir la spec debería ser un trabajo colaborativo donde el QA tiene un rol clave. Pero la mayoría de equipos arrancan dejando esa responsabilidad al dev — exactamente donde el modelo se rompe (lo veremos más adelante).

¿De dónde sale la información? De los insumos de siempre: requisitos de producto, conversaciones con stakeholders, criterios de aceptación. Lo nuevo es el formato. Toda esa información hay que traducirla a un lenguaje preciso, sin ambigüedades, que la IA pueda interpretar de manera determinística — porque sobre esa interpretación se va a generar el código y los tests.

El ciclo completo, simplificado:

1. Alguien (idealmente con QA en la mesa) escribe la spec
2. Una IA toma la spec y genera el código que la implementa
3. La misma IA, u otro agente especializado, genera los tests que validan ese código contra la spec
4. El equipo revisa lo generado, encuentra los huecos, vuelve a la spec, ajusta, regenera

La spec es la fuente de verdad. El código es derivado. Los tests son derivados. Si la spec está bien, todo el ciclo funciona. Si la spec está incompleta o ambigua, el ciclo entero queda envenenado desde el origen — y nadie se da cuenta hasta que el bug aparece en producción.

Tres herramientas que ya están corriendo en producción: GitHub Spec Kit (open source, integración con Copilot), Claude con su modo de specifications (Anthropic), y los modos spec-first de Cursor. Hay más, pero esas tres ya tienen tracción real en equipos serios.

Y acá empieza lo que no te están contando en LinkedIn.

Agentes — ¿quién hace exactamente qué en este ciclo?

Cuando digo “la IA genera el código” o “un agente escribe los tests” estoy resumiendo algo que en la práctica tiene varias capas. En un workflow real de SDD no hay una sola inteligencia artificial haciendo todo. Hay varios agentes especializados, cada uno con un rol específico.

Un agente, en este contexto, es un programa que combina tres cosas:

1. Un modelo de lenguaje (Claude, GPT, Gemini) — la “cabeza” que entiende el lenguaje natural y genera contenido
2. Un conjunto de herramientas (acceso a archivos, capacidad de ejecutar comandos, conexión a APIs externas vía MCP) — las “manos” que actúan sobre el sistema
3. Un system prompt que define su rol — la “personalidad” que limita y dirige lo que el agente va a intentar hacer

En un ciclo de SDD bien armado suelen aparecer estos roles:

• Spec interpreter — lee la spec y la analiza para detectar ambigüedades antes de empezar
• Code generator — toma la spec interpretada y produce el código de implementación
• Test generator — toma la spec más el código generado y escribe los tests que validan ambos
• Validator — corre los tests, lee resultados, verifica que la implementación cumpla la spec
• Orchestrator (opcional) — coordina a los agentes anteriores, decide cuándo iterar y cuándo dar el ciclo por terminado

En herramientas como GitHub Spec Kit todos estos roles vienen pre-configurados — el equipo solo ejecuta el comando del ciclo y los agentes hacen su parte en orden. En workflows más custom (Claude Code con subagentes, Cursor con agentes personalizados, frameworks como LangGraph o AutoGen) los puedes definir tú según la necesidad real de tu proyecto.

Por qué esto importa para el QA: no estás validando una “caja negra llamada IA”. Estás validando un sistema de agentes encadenados, donde cada uno puede fallar de forma distinta. Si el código sale incorrecto, puede ser que el code generator interpretó la spec con un sesgo. Si los tests no cubren un caso obvio, puede ser que el test generator usó solo el “happy path” descrito en la spec. La trazabilidad del ciclo — saber qué agente hizo qué con qué input — se vuelve parte del trabajo de QA.

Ahora sí, con esto en mente, vamos a la pregunta que importa.

La pregunta incómoda — y por qué casi nadie la responde

La narrativa de los devs en LinkedIn es: “ahora no necesitamos escribir tests, la IA los hace por nosotros”. Lo dicen alegremente porque, para ellos, los tests siempre fueron una carga. Repetitivos. Aburridos. Una tarea que delegaban con gusto.

Pero los QA sabemos algo que los devs entusiastas no están diciendo: los tests nunca fueron lo más valioso del trabajo de QA. Los tests son el output. Lo valioso es el pensamiento que los precede.

Y la IA, por más espectacular que sea generando código, no puede generar pensamiento crítico sobre qué se puede romper.

Esa diferencia es donde vive la respuesta a la pregunta del título.

Lo que SÍ cambia para el QA

Cuando integras SDD en tu workflow, tu día a día se transforma en tres frentes claros:

1. De ejecutor de tests a arquitecto de specs

Antes pasabas el 60% de tu tiempo escribiendo tests automatizados, leyendo requisitos, peleándote con selectores frágiles y debuggeando flakys. Ahora pasas la mayor parte de ese tiempo leyendo, criticando y completando specs.

La spec es el nuevo lugar de trabajo. Si la spec es completa, consistente y sin ambigüedad, el código y los tests generados serán correctos. Si la spec tiene huecos, todo el ciclo está envenenado desde el origen.

2. El testing ocurre al nivel de la spec, no del código

Esto es lo más importante de todo el artículo, así que lo digo con mayúsculas: EL TESTING SE ADELANTA UN NIVEL. Ya no preguntas “¿este código hace lo que la spec dice?”. Eso lo hace la IA. Tu pregunta es:

Es shift-left llevado a su forma más pura. Ya no entras al final del sprint a romper la pantalla del checkout. Entras al principio, antes de que se escriba una sola línea de código, y demuestras que la spec del checkout no contempla qué pasa cuando el usuario tiene 3 cupones acumulados con un descuento de empleado.

3. Las 4 técnicas del Cap. 4 ISTQB ahora aplican a la spec

Esto te va a sonar conocido si seguiste la serie ISTQB con código que terminé de publicar la semana pasada. Las 4 técnicas clásicas de diseño de pruebas — partición de equivalencia, valores límite, tabla de decisión, transición de estados — siempre se enseñaron como técnicas para diseñar tests sobre el código.

En SDD, se aplican a la spec antes de que exista el código:

• Partición de equivalencia: ¿la spec cubre todas las clases de input? ¿O describe un caso “feliz” y deja todo lo demás implícito?
• Valores límite: ¿la spec menciona qué pasa exactamente en min, min-1, max, max+1?
• Tabla de decisión: si hay condiciones combinables, ¿la spec las cubre todas o solo las “obvias”?
• Transición de estados: ¿la spec define qué transiciones NO deberían existir? Porque la IA solo genera tests para lo que la spec dice. Lo que no está en la spec, no se testea.

El QA que aplica estas técnicas a la spec es el QA que produce specs sin huecos. El que no las aplica, produce specs que generan código y tests con huecos invisibles.

Lo que NO cambia: la mentalidad de “qué se rompe”

Esa es la habilidad que sigue siendo cara, irreemplazable y profundamente humana. Los 15 años que llevo en QA me enseñaron que el bug más caro casi nunca está en lo que el equipo “sabía que podía pasar”. Está en la combinación que nadie pensó.

Y la IA, por definición, no puede pensar en lo que nadie pensó.

El bug silencioso del SDD

Acá está el riesgo del que nadie habla en los hilos de LinkedIn:

Te doy un ejemplo concreto. Imagina una spec de un endpoint de transferencias bancarias:

endpoint: POST /transferencias
inputs:
  monto: number, > 0, < 10000
  cuenta_destino: string (IBAN válido)
output:
  success: 200 + transferencia_id
  errores:
    - 400 si monto inválido
    - 400 si cuenta_destino inválida
    - 402 si saldo insuficiente

La IA genera el código. Genera tests para cada caso listado. Todo verde. Deploy.

Tres semanas después, descubres que un usuario hizo 1.000 transferencias de 9.999 dólares en 30 segundos a la misma cuenta. Vació un fondo corporativo en medio minuto. ¿Por qué? Porque la spec no decía nada de rate limiting. La IA no inventó ese requisito. El dev no lo pensó. El QA no revisó la spec con la pregunta “¿qué pasa si esto se llama 1.000 veces seguidas?”.

Ese bug va a vivir en producción durante meses. Y cuando explote, el equipo va a culpar al sistema. La realidad es que el sistema cumplía la spec al pie de la letra. La spec era la incompleta.

Esos van a ser los bugs caros del 2026 al 2030. Y quien los va a detectar antes de que ocurran es el QA que entiende SDD desde la perspectiva correcta.

Cómo lo integro en mi workflow

Mi workflow actual ya combina Claude Code, MCP y agentes para tareas específicas (análisis de tickets de Jira, generación de casos de prueba, automatización de standups). SDD encaja como una extensión natural de eso, no como una revolución que rompe todo.

El ciclo que recomiendo, con el QA en el centro:

El QA está en dos puntos del ciclo: antes (validando la spec) y después (validando los tests). En ambos puntos lo que aporta es lo que la IA no puede: pensamiento crítico sobre lo no escrito.

Herramientas a conocer

No es una review, solo nombres para que sepas dónde mirar:

• GitHub Spec Kit — open source, integración natural con Copilot. La opción más estándar para arrancar.
• Anthropic con specifications — Claude tiene un modo de trabajo donde la spec es el contrato. Funciona bien con agentes y MCP.
• Cursor specs mode — el editor que muchos devs ya usan, con un modo donde la spec dirige la generación.

En los próximos días voy a publicar una guía paso a paso mostrando un ciclo completo de SDD con GitHub Spec Kit desde la mirada del QA: cómo escribir la spec, qué revisar antes de generar, cómo validar lo que la IA produjo, y dónde aplicar las 4 técnicas ISTQB en cada paso.

El cierre — SDD no te reemplaza, te eleva (o te entierra)

Vuelvo a la pregunta del título. La respuesta no es “no te preocupes, tu trabajo está seguro”. Sería un mensaje complaciente y poco honesto.

La respuesta real es:

El cambio ya empezó. Las herramientas existen, los equipos las están adoptando, los procesos se están reescribiendo. Los QA que se adapten a este nuevo modelo van a ser indispensables, porque van a operar al nivel donde se decide la calidad: la especificación. Los que se queden esperando que esto sea “una moda más” van a ser reemplazados — no por la IA, sino por una IA siguiendo una spec mal escrita por alguien que no sabía detectar sus huecos.

Yo elijo estar en el primer grupo. Si tú también lo eliges, próximamente sale la guía con el workflow completo.