SDD frente a ODD: especificar el trabajo o definir el resultado
Una prueba en verde no garantiza que una IA haya hecho el cambio correcto. Y una especificación detallada tampoco sirve de mucho si describe una versión del producto que ya no existe. Ahí está buena parte de la discusión entre SDD y ODD: qué conviene fijar antes de delegar trabajo y qué debe comprobarse al recibirlo.
Qué es SDD
SDD, Spec-Driven Development, usa una especificación como referencia para implementar y revisar un cambio. En un encargo a una IA, esa especificación puede recoger reglas de negocio, contratos, casos límite y decisiones que el agente no debe tomar por su cuenta.
Su punto fuerte es hacer explícito lo acordado. Si un endpoint debe mantener un formato de respuesta concreto, escribirlo permite detectar desviaciones. El coste está en mantener ese documento: si el requisito cambia pero la especificación no, el agente puede cumplirla al pie de la letra y entregar una solución equivocada.
SDD encaja especialmente cuando hay contratos estables o decisiones que no deben quedar abiertas. Aporta menos si redactar y actualizar la especificación lleva más trabajo que resolver y revisar el cambio.
Qué es ODD
ODD, Outcome-Driven Development, organiza el encargo alrededor del resultado esperado y de cómo comprobarlo. En vez de indicar todos los pasos de implementación, define el comportamiento que debe cambiar, las restricciones que deben respetarse y los criterios para aceptar la entrega. El agente conserva margen para inspeccionar el código y decidir dónde intervenir.
Ante un fallo en el proceso de compra, un encargo ODD podría pedir que una prueba reproduzca el fallo, que los pedidos ya confirmados no se modifiquen y que las validaciones existentes sigan pasando. No presupone qué componente contiene la causa. Ese margen ayuda cuando aún no se conoce el problema, pero obliga a revisar la solución: una prueba en verde puede cubrir solo el caso que el agente decidió probar.
ODD no sustituye los requisitos precisos. Si un campo de una API tiene un formato obligatorio, también hay que escribirlo en un encargo orientado al resultado.
Hay otra diferencia práctica: la evidencia de que se ha alcanzado el resultado debe poder examinarse. En el ejemplo del checkout, no bastaría con que el agente dijera que ha corregido el fallo. Habría que revisar qué caso reproduce la prueba, si fallaba antes del cambio y si la corrección respeta la restricción sobre los pedidos confirmados. Si esta última condición no puede comprobarse con una prueba, sigue necesitando una revisión explícita. Definir un resultado no equivale a delegar su aceptación.
Pros y contras frente a frente
| Enfoque | A favor | En contra |
|---|---|---|
| SDD | Deja constancia de las decisiones y permite comparar la implementación con lo acordado. | La especificación necesita mantenimiento; si queda obsoleta, desorienta al agente. |
| ODD | Deja margen para adaptar la implementación a lo que revela el código. | Un resultado vago admite soluciones incompatibles con lo que se necesitaba. |
La diferencia se ve en una petición como «arregla el fallo del checkout». En SDD habría que precisar el comportamiento esperado y los contratos afectados antes de implementar. En ODD habría que fijar, como mínimo, qué fallo debe reproducirse, qué comportamientos no pueden romperse y qué evidencia se espera para aceptar el cambio. Si ninguno de los dos encargos concreta eso, el problema no es el enfoque: faltan requisitos.
Por qué ODD está entrando en la conversación
El atractivo de ODD es comprensible: cuando un agente puede explorar un repositorio, resulta tentador definir la meta y dejar que encuentre el camino. Es una respuesta práctica a la fricción de mantener especificaciones detalladas para tareas cuyo alcance cambia al investigar el código.
También hay una objeción razonable. «Define el resultado» suena sencillo hasta que hay que decidir qué cuenta como prueba suficiente, qué efectos secundarios son aceptables o quién revisa una solución que pasa los tests pero altera otro comportamiento. ODD desplaza parte del esfuerzo desde la descripción previa hacia la verificación; no lo hace desaparecer.
A favor de SDD se argumenta que las instrucciones explícitas reducen la ambigüedad. En contra, que una especificación extensa puede convertirse en trabajo de mantenimiento. A favor de ODD se valora la libertad para corregir el rumbo; en contra, que esa libertad es difícil de controlar si los criterios de aceptación son débiles. Son argumentos sobre los enfoques, no posturas atribuibles a una comunidad concreta sin fuentes.
La comparación tampoco obliga a elegir un método para todo el proyecto. Un contrato de API puede necesitar una especificación que se mantenga junto al código, mientras que la investigación de un fallo puede empezar por el resultado observable y sus restricciones. Incluso dentro de la misma tarea se pueden combinar ambos: fijar el contrato que no debe cambiar y dejar abierto cómo corregir la implementación. La decisión útil no es qué etiqueta adoptar, sino qué incertidumbre conviene resolver antes de empezar y cuál puede resolver el agente sin asumir decisiones de producto.
Para probar cualquiera de los dos en una tarea real, empezaría por escribir el comportamiento esperado y una comprobación que pueda fallar. Después fijaría por escrito las decisiones que el agente no debe cambiar. Eso permite delegar la implementación sin delegar también el criterio de aceptación.
