Del Contrato de Código a la Experiencia de Negocio: Cómo el QA transforma el Spec-Driven Development (SDD) en valor real
No cabe duda alguna de que nos encontramos en una era donde crear soluciones de software es tal vez más fácil que nunca. Acompañados por Inteligencia Artificial, construir una aplicación completa —con su backend, su capa de lógica y su interfaz de usuario— se ha vuelto un ejercicio de prompts y confirmaciones rápidas. Esa magia de ver resultados instantáneos nos hace creer que la velocidad de escritura de código es igual a la madurez del producto. Pero no es así.
En este contexto de hiperproducción, ha ganado fuerza el Spec-Driven Development (SDD) o desarrollo guiado por especificaciones. A diferencia de lo que muchos creen al asociarlo únicamente con especificaciones técnicas de APIs (como OpenAPI), el SDD actual puede abarcar el diseño y la construcción de aplicaciones completas: se especifican flujos de usuario, pantallas, componentes de frontend, estructuras de datos y comportamientos del sistema antes de que se genere el código funcional, muchas veces apoyándose en especificaciones en lenguaje natural estructurado, archivos de esquema o contratos de interfaz complejos.
La idea es poderosa: antes de construir, definimos con mayor precisión qué queremos construir y bajo qué condiciones debe comportarse el sistema. Y cuando incorporamos agentes de IA al proceso, esa especificación adquiere todavía más importancia, porque se convierte en uno de los principales mecanismos mediante los cuales humanos, desarrolladores y agentes se comunican.
Sin embargo, aquí aparece una paradoja que creo que veremos cada vez con mayor frecuencia: la IA puede hacer que construir software sea muchísimo más rápido, pero eso no significa necesariamente que estemos construyendo el software correcto.
La realidad es algo más compleja que la narrativa de que la IA y el SDD generan por sí solos flujos de trabajo completamente autónomos donde "todo funciona mágicamente". Los agentes actuales ya pueden generar código, ejecutar pruebas, interactuar con navegadores y recorrer determinados flujos de usuario de manera autónoma. Pero existe una diferencia fundamental entre poder ejecutar una prueba y saber si estamos probando aquello que realmente importa para el negocio.
Un agente puede ejecutar perfectamente una prueba construida sobre una especificación incompleta, ambigua o directamente equivocada. Puede cumplir el contrato al 100% y, aun así, ayudarnos a construir el producto equivocado.
Y es justamente aquí donde el ecosistema tropieza, sobre todo cuando viene de una inercia donde se utilizaba BDD (Behavior-Driven Development). En los equipos que adoptan SDD, existe el riesgo de que el foco se desplace hacia esquemas, estructuras de componentes, estados de la aplicación y contratos de datos, perdiendo progresivamente la mirada sobre el comportamiento y el propósito de negocio.
Es exactamente en este punto donde el rol del QA deja de ser un simple validador técnico y se convierte en el puente crítico que transforma una especificación en valor real para la organización.
La trampa de una especificación perfecta para el producto equivocado
Cuando un equipo de ingeniería adopta SDD para construir una aplicación completa, la especificación se convierte en una pieza central del desarrollo. Esto es precisamente lo que hace tan poderoso al enfoque: una buena especificación reduce ambigüedades, establece contratos, facilita la automatización y permite que tanto humanos como agentes de IA puedan trabajar sobre una misma fuente de verdad. Pero aquí aparece una trampa.
Una especificación puede ser perfectamente consistente y, aun así, estar equivocada.
Podemos tener un contrato impecable, un esquema válido, una API correctamente definida, componentes que cumplen exactamente los estados esperados y pruebas automatizadas que pasan al 100%. Y aun así entregar una experiencia que el cliente no necesita, una regla de negocio incorrecta o un flujo que contradice el objetivo comercial. Porque existe una diferencia fundamental entre cumplir una especificación y construir el producto correcto.
Si la especificación dice que el checkout debe permitir pagar con tarjeta, un agente puede generar correctamente el frontend, el backend y las pruebas necesarias para comprobar ese comportamiento. Pero la especificación podría no haber contemplado que un cliente con una deuda vencida no debe poder realizar una nueva compra. El software podría funcionar exactamente como fue especificado. Y, sin embargo, estaría mal. Ese es el verdadero desafío.
La trampa hipertécnica del SDD y la pérdida de la perspectiva de negocio
El problema no está en el SDD. El problema aparece cuando confundimos especificación con especificación técnica. Cuando la conversación comienza a centrarse exclusivamente en esquemas, estructuras de componentes, estados, contratos de datos y comportamiento de APIs, existe el riesgo de que la especificación termine describiendo extraordinariamente bien cómo construir el sistema, pero no necesariamente por qué existe el sistema. Y ahí el código y la realidad del usuario final pueden comenzar a separarse. Viniendo de metodologías como BDD, donde el foco está puesto en el comportamiento del sistema desde una perspectiva comprensible para el negocio, existe una lección que no deberíamos perder. El famoso Given-When-Then no es valioso simplemente por su sintaxis, sino porque obliga a preguntarnos qué comportamiento estamos intentando conseguir, bajo qué condiciones y para quién.
El SDD puede llevar esa idea mucho más lejos, transformando ese comportamiento en una especificación suficientemente estructurada para que humanos, desarrolladores y agentes de IA puedan trabajar sobre ella. Pero alguien tiene que desafiar esa especificación.
Porque si todos aceptamos que el documento es correcto simplemente porque está bien estructurado, podemos terminar automatizando el problema. Y a una velocidad impresionante.
¿Qué sucede con la usabilidad real cuando el flujo de compra, perfectamente especificado paso a paso, resulta ser una pesadilla cognitiva para el cliente?
¿Quién valida si una regla de negocio crítica —aquella que no cabe naturalmente en un esquema de datos— fue interpretada correctamente?
¿Qué sucede cuando una nueva iteración optimiza el flujo técnicamente, pero elimina una condición necesaria para el negocio?
¿Quién detecta que una funcionalidad cumple todos sus criterios de aceptación, pero está resolviendo un problema que ya no es prioritario?
Estas preguntas no se responden simplemente ejecutando más tests. Y aquí es donde entra el QA.
Cómo el QA inyecta valor de negocio en el Spec-Driven Development
Para que el SDD aporte al ROI de la empresa y no se quede en un ejercicio de ingeniería abstracta, el QA debe redefinir su participación a lo largo de todo el ciclo de vida del desarrollo. No como un "filtro final" que aparece cuando el código ya está construido, sino como una disciplina que ayuda a cuestionar, validar y convertir la especificación en un contrato verificable.
1. Traducción y gobernanza de la especificación: del requerimiento ambiguo al contrato ejecutable
En el SDD, la especificación es uno de los principales insumos para la construcción. Por eso, el primer gran aporte de valor del QA ocurre antes de que la IA genere cualquier cantidad significativa de código.
Auditoría de ambigüedades comerciales: los equipos técnicos pueden escribir especificaciones perfectamente válidas desde el punto de vista estructural, pero eso no significa que hayan contemplado todas las situaciones que pueden ocurrir en la realidad. El QA actúa como el analista de fricción, revisando que los flujos de usuario definidos en la especificación contemplen las excepciones relevantes del negocio: qué pasa si el pago falla, si el inventario se agota a mitad de un checkout, si un usuario abandona la sesión o si los datos proporcionados son incompletos. No se trata simplemente de encontrar errores de redacción. Se trata de encontrar comportamientos que todavía no han sido especificados. Porque cada comportamiento no especificado es, potencialmente, una decisión que terminará tomando un desarrollador, un agente de IA o una combinación de ambos. Y esa decisión podría ser correcta. O podría no serlo.
Gobernanza de reglas de negocio: la IA es excelente generando código, conectando componentes y transformando especificaciones en implementaciones. Pero eficiencia de implementación no significa comprensión del contexto. Una organización puede tener restricciones legales, políticas internas, reglas comerciales, excepciones históricas o condiciones contractuales que difícilmente aparecen de forma completa en una especificación técnica. Por eso, el QA debe ayudar a asegurar que esas restricciones estén explícitamente representadas antes de que sean codificadas. No podemos esperar que un agente "adivine" una regla que nunca fue especificada. Si la organización requiere que determinados datos personales sean tratados de una determinada manera, eso debe formar parte del contrato que gobierna la solución. Si existe una política específica de reembolso, debe existir una representación verificable de esa política. Si existe una condición comercial crítica, debe poder convertirse en un comportamiento que pueda ser validado.
La IA no puede corregir una ambigüedad que el equipo ni siquiera reconoce como ambigüedad.
2. Validación cruzada de la interfaz y el comportamiento: frontend, backend y negocio
Cuando el SDD se utiliza para construir aplicaciones completas, el riesgo de desviación entre lo que el usuario ve y lo que el sistema procesa aumenta. Podemos tener un frontend perfectamente alineado con la especificación visual y un backend perfectamente alineado con el contrato de datos. Pero eso no significa necesariamente que el flujo completo tenga sentido. Aquí el QA aporta una visión transversal. No valida solamente componentes aislados, sino el comportamiento del sistema como experiencia.
Por ejemplo, el botón funciona, la API responde, la base de datos recibe correctamente la información y el test automatizado pasa. Pero ¿el usuario consigue realmente completar la tarea que vino a realizar?
Esa diferencia es fundamental.
La automatización puede verificar una enorme cantidad de condiciones. Pero las condiciones que decidimos automatizar siguen dependiendo de lo que creemos que vale la pena verificar. Por eso el QA no debe limitarse a aumentar la cantidad de pruebas. Debe aumentar la calidad de las preguntas que esas pruebas intentan responder. El objetivo no es simplemente demostrar que el sistema hace lo que dice la especificación. También debemos comprobar que esa especificación representa correctamente el comportamiento que el negocio espera.
3. Recuperando el alma del BDD dentro del SDD
Existe un falso debate sobre si BDD y SDD son excluyentes. No lo son; de hecho, se potencian si entendemos correctamente el rol de cada uno. BDD aporta una forma de expresar el comportamiento desde la perspectiva del negocio y del usuario. SDD permite convertir esa intención en una especificación más estructurada, consistente y utilizable por humanos y agentes. El QA puede actuar como mecanismo de conexión y validación entre ambas capas. Esto significa transformar los escenarios de negocio orientados al comportamiento en validaciones que gobiernen la especificación técnica. De este modo, el equipo no solo construye aplicaciones que compilan, cumplen con los esquemas y pasan sus pruebas automatizadas, sino soluciones que mantienen una conexión explícita con los dolores y objetivos reales del cliente final.
Podríamos resumirlo de una manera bastante simple:
BDD ayuda a expresar el comportamiento que importa.
SDD ayuda a convertir ese comportamiento en un contrato que puede ser construido.
La automatización ayuda a verificar que ese contrato se cumple.
QA ayuda a cuestionar si ese contrato realmente representa lo que el negocio necesita.
No se trata, entonces, de elegir entre BDD y SDD. Se trata de evitar que la especificación técnica pierda contacto con el comportamiento y con el propósito de negocio.
4. Mitigación del Product Drift y control del ROI
Existe otro riesgo que aparece cuando combinamos SDD con ciclos de desarrollo extremadamente rápidos y agentes de IA: la especificación también evoluciona. Un agente puede modificar un flujo. Un desarrollador puede simplificar una regla. Un equipo puede cambiar una condición para resolver un problema puntual. Una nueva iteración puede optimizar la implementación. Y después de diez, veinte o cincuenta modificaciones, el producto puede comenzar a alejarse de la intención original. No necesariamente porque alguien haya cometido un error evidente. Simplemente porque cada modificación local parecía razonable.
Podríamos llamar a esto Product Drift: la progresiva separación entre lo que el producto termina haciendo y el propósito que originalmente justificó su construcción.
Aquí el QA vuelve a tener un papel estratégico.
La trazabilidad no debería limitarse a:
requerimiento → código → test.
También debería permitir preguntarnos:
objetivo de negocio → comportamiento esperado → especificación → implementación → evidencia de que el comportamiento sigue generando valor.
Porque pasar todos los tests no demuestra que el producto siga resolviendo el problema correcto.
Y aquí aparece una diferencia importante entre calidad técnica y calidad de producto. Un sistema puede ser estable, rápido, seguro y estar completamente cubierto por pruebas automatizadas. Y aun así puede estar resolviendo el problema equivocado.
El nuevo QA no es el que encuentra más bugs
Creo que aquí está uno de los cambios más importantes que estamos viviendo. Durante mucho tiempo asociamos el valor del QA con encontrar defectos. Y, por supuesto, encontrar defectos sigue siendo importante. Pero en un mundo donde la IA puede generar código, pruebas y correcciones a una velocidad cada vez mayor, encontrar un bug después de que todo fue construido puede ser una parte relativamente pequeña del problema.
El verdadero valor está cada vez más arriba en la cadena: en cuestionar la especificación, detectar ambigüedades, identificar escenarios que nadie consideró, conectar comportamiento con reglas de negocio y verificar que la experiencia completa tenga sentido. Y, sobre todo, en hacer una pregunta incómoda cuando todos están celebrando que los tests están en verde:
¿Estamos seguros de que estamos validando lo correcto?
Porque un test en verde solo demuestra que el sistema cumplió la condición que nosotros decidimos probar. No demuestra que esa condición sea suficiente, y mucho menos demuestra que sea la condición que realmente importa para el negocio.
El factor humano como núcleo de la estrategia
En Hakalab tenemos la absoluta convicción de que la tecnología debe resolver problemas reales y no crear nuevas capas de complejidad vacía. Las metodologías modernas como el Spec-Driven Development son herramientas potentísimas para estructurar la construcción de aplicaciones complejas con apoyo de Inteligencia Artificial, pero ninguna metodología tiene por sí sola una brújula de negocio. La IA puede generar código, razonar sobre una especificación, ejecutar herramientas, navegar aplicaciones, crear pruebas y corregir errores. Y cada vez podrá hacer mucho más. Pero ninguna de esas capacidades elimina la necesidad de decidir qué significa que el producto sea correcto.
Porque existe una diferencia enorme entre:
“el sistema funciona como fue especificado”
y
“el sistema funciona como el negocio realmente necesita”.
El QA en el SDD no debería ser un cuello de botella burocrático ni un simple ejecutor de pruebas. Debe convertirse en una disciplina que desafía el contrato, conecta el comportamiento con el negocio y aporta evidencia de que estamos construyendo el producto correcto. La autonomía real tampoco consiste en soltarle el control a un agente para que genere aplicaciones a ciegas. Consiste en delegar progresivamente la carga operativa mientras mantenemos el criterio humano donde realmente importa. Y quizás esta sea una de las paradojas más interesantes de esta nueva era:
Mientras más rápido podamos construir software, más importante será saber exactamente qué software deberíamos construir.
Hoy, ante la avalancha de soluciones automatizadas y nuevas metodologías, la pregunta clave para cualquier organización que implemente Spec-Driven Development no debería ser qué tan rápido genera código tu IA, ni siquiera cuántas pruebas puede ejecutar.
La pregunta debería ser:
¿Tienes la certeza de que tus especificaciones están construyendo el producto correcto para tu negocio, o simplemente estás automatizando la creación de deuda técnica a una velocidad sin precedentes?