El ODD, u Organic Driven Development, es el flujo de trabajo con el que gentle-ai, el ecosistema de agentes de Gentleman Programming, ha sustituido su Spec-Driven Development (SDD): en vez de pasar siempre por especificación, plan y tareas antes de tocar el código, es el propio agente quien decide cuánta ceremonia merece cada tarea. Para ver qué cambia de verdad, he enfrentado los dos métodos con la misma feature, la misma spec, el mismo modelo (Sonnet 5.5) y la misma versión de Claude Code, y en este artículo te cuento qué es cada uno, cómo trabajaron, qué números salieron y el error que dejaron escondido los dos, con el código para arreglarlo.

Si prefieres verlo, lo tienes todo en el vídeo, con las dos sesiones en pantalla y capítulos para saltar a cada parte:

En resumen: los dos métodos cumplieron los 12 requisitos de la spec, pero ODD tardó 1,4 minutos y unos 0,38 dólares, frente a los 6,2 minutos y 1,44 dólares de Spec Kit, porque trató la feature como una tarea pequeña y no escribió ni una línea de documentación. Los dos dejaron el mismo error 500 con dos peticiones iguales a la vez: Spec Kit lo detectó en su análisis antes de escribir código y ODD cerró diciendo «Risk: none».

Qué es el ODD (Organic Driven Development)

El ODD parte de una idea sencilla: no todas las tareas merecen la misma ceremonia, y en vez de decidirlo tú, lo decide el agente. Su flujo tiene tres pasos que se ven mientras trabaja. Primero entiende el código antes de tocar nada, y solo te pregunta si hay una decisión de producto que no puede tomar él. Después clasifica la tarea: si la entiende, el riesgo está acotado y se podría retomar mañana mirando solo los cambios, es pequeña y la hace directamente, y si es grande abre un único documento en odd/tasks con tu spec tal cual y lo copia en Engram, su memoria persistente, para que los requisitos sobrevivan aunque la sesión se alargue y el contexto del modelo se resuma. Por último, implementa con pruebas.

[Imagen: el gráfico del flujo de ODD que sale en el vídeo. Texto alternativo: «Flujo del ODD: entender el código, clasificar la tarea como pequeña o grande e implementar con pruebas»]

gentle-ai convirtió el ODD en su flujo por defecto en la versión 3.0.0, donde explica que rehizo el SDD para quitarle la ceremonia que se había convertido en un control de paso más que en algo que aportara valor, y en la 4.0.0 retiró del todo el SDD y su integración con OpenSpec. Además, trae activada por defecto una capa de revisión aparte, que llama RDD, y que en mi prueba apagué para comparar los dos métodos a pelo.

Qué es el Spec-Driven Development y cómo lo aplica Spec Kit

El Spec-Driven Development nació para sustituir al vibe coding: antes de escribir código se escribe una especificación, un plan y una lista de tareas, y el agente trabaja contra ese contrato. Funciona mucho mejor que ir pidiéndole cosas sobre la marcha, pero tiene un precio, porque el flujo es siempre el mismo, sea un bug, un hotfix o una feature enorme. Spec Kit, el kit de GitHub, lo convierte en pasos que se lanzan uno detrás de otro: constitution para las normas del proyecto y, después, specify, clarify, plan, tasks, analyze e implement. Es el método que explico en mi libro «Del vibe coding al Spec-Driven Development», y si ya lo usas, SpecJudge lee esos mismos artefactos para recomendarte el modelo con mejor relación calidad/precio para tu proyecto.

Diferencias entre SDD y ODD

Aspecto	SDD con Spec Kit	ODD con gentle-ai
Quién decide cuánto proceso hay	Tú: el flujo es siempre el mismo	El agente, al clasificar la tarea
Documentación	Spec, plan, tareas y análisis en el repo	Ninguna si la tarea es pequeña; un documento en odd/tasks si es grande
Memoria entre sesiones	Los documentos de la spec	Engram, solo si la tarea es grande
Revisión de riesgos	El paso analyze, antes de implementar	La capa RDD, aparte y activada por defecto
Dónde quedan las decisiones	En la spec	En el mensaje del commit, si la tarea es pequeña

La prueba: la misma feature en TaskFlow con Claude Code

Para la prueba usé TaskFlow, una API de tareas en Flask que ya conoces si sigues el canal, y le pedí una feature de verdad: dependencias entre tareas, de forma que una tarea no se pueda cerrar mientras otra de la que depende siga pendiente. Le escribí una spec de 12 requisitos, con sus endpoints, sus códigos de error y la regla de que no puede haber ciclos, y los dos métodos recibieron exactamente la misma spec, el mismo modelo (claude-sonnet-5-5) y la misma versión de Claude Code (2.1.317), con Spec Kit 1.2.6 en un lado y gentle-ai 4.3.1 con Engram 3.6.0 en el otro. Para puntuar usé una batería de tests oculta que ningún agente llegó a ver.

En Spec Kit lancé una llamada por paso, de specify a implement, y en gentle-ai le pasé la spec con una frase delante dándole permiso para trabajar, y a partir de ahí mandó el agente. Si quieres repetir la prueba con tu proyecto, el kit completo, con la spec, los prompts, los tests ocultos y los scripts, está aquí: [ENLACE AL KIT].

Resultados: SDD contra ODD

Métrica	SDD (Spec Kit)	ODD (gentle-ai)
Requisitos cumplidos (tests ocultos)	12 de 12	12 de 12
Tiempo	6,2 min	1,4 min
Coste estimado por Claude Code	1,44 $	0,38 $
Tokens de salida	47.797	10.927
Documentación	8 ficheros, 605 líneas	Ninguna
Llamadas y turnos	6 llamadas, 50 turnos	1 llamada, 7 turnos

Los dos cumplen exactamente lo mismo, pero ODD lo hace unas cuatro veces más rápido y más barato, porque consideró la feature una tarea pequeña: no abrió ningún documento, no lanzó subagentes ni guardó nada en Engram, y lo dejó todo en un solo commit después de escribir primero los tests y verlos fallar («RED observado. Ahora la implementación», dice). Spec Kit, en cambio, dejó 605 líneas de documentación en 8 ficheros antes de tocar una sola línea de código, y su paso analyze encontró 8 avisos, ninguno grave.

Una lectura honesta: es una feature, un modelo, un proyecto y una toma medida por método, así que es una demostración y no un estudio. Los costes son la estimación que da Claude Code al terminar cada sesión, no lo facturado, y no incluyen la constitución de Spec Kit, que se escribe una vez por proyecto (0,10 $). Y en una toma anterior de ODD, que tuve que repetir por un fallo de mis scripts, sacó el mismo 12 de 12 en un tiempo parecido, pero escribió el código antes que los tests.

El error 500 que solo vio uno y cómo se arregla

Lo más interesante vino después. Si llegan dos peticiones iguales a la vez para crear la misma dependencia, las dos comprueban que no existe, las dos intentan guardarla y la segunda choca con la clave primaria compuesta de la tabla, así que la API devuelve un error 500 en vez del 409 que pide la spec para un duplicado. Spec Kit lo vio en su paso analyze antes de escribir código, lo marcó como menor y nadie lo corrigió, y ODD cerró su sesión diciendo «Risk: none» con exactamente el mismo hueco en su código. Los tests ocultos pasaron en verde con el fallo dentro, porque mandan las peticiones de una en una, y ahí está la trampa: unos tests en verde no te dicen que no haya riesgos.

El arreglo es pequeño. En TaskFlow las vistas no pueden tocar la sesión de la base de datos, que es una de las normas de la casa, así que va en el repositorio: capturar el IntegrityError al hacer el commit, deshacer la transacción y avisar a la vista para que responda 409.

# app/repositories/task_repository.py
from sqlalchemy.exc import IntegrityError

@staticmethod
def add_dependency(task: Task, depends_on: Task) -> bool:
    task.dependencies.append(depends_on)
    try:
        db.session.commit()
    except IntegrityError:  # otra petición la ha creado entre la comprobación y el commit
        db.session.rollback()
        return False
    return True

# app/views/tasks.py
if not TaskRepository.add_dependency(task, depends_on):
    return jsonify({"error": "Dependency already exists"}), 409

Los dos agentes eran el mismo modelo, así que la diferencia está en el proceso: el SDD tiene un paso que le obliga a buscar riesgos y dejarlos por escrito, y el ODD, tal como lo probé, deja ese juicio al mismo agente que acaba de escribir el código. Dejar el criterio de riesgo en manos del agente, sin un paso que lo obligue a buscarlo y sin que tú leas lo que encuentra, sigue siendo un peligro, y para ser justos, gentle-ai tiene para eso su capa RDD, la que apagué.

¿Ha muerto el Spec-Driven Development?

No. Lo que ha cambiado es el flujo SDD de gentle-ai, que según sus propias notas había acumulado tanta ceremonia que ya funcionaba más como un control de paso que como algo que aportara, pero Spec Kit sigue vivo y la spec no ha muerto en ninguno de los dos métodos, porque los dos trabajaron a partir de la misma. Lo que sí creo que ha venido para quedarse es la idea del ODD: cuando el trabajo cabe en una sesión, un pipeline de documentos sale caro y, en mi prueba, no mejoró el resultado. Lo que esta prueba no mide es qué pasa si la sesión se corta a mitad o si dentro de un mes alguien tiene que entender por qué se decidió algo, y ahí se nota que Spec Kit dejó sus decisiones en la spec y ODD, solo en el mensaje del commit.

Cuándo usar SDD y cuándo ODD

Yo no elegiría uno para todo. El flujo completo, al estilo Spec Kit, lo reservaría para los cambios que tocan varios módulos, contratos o datos, o que no caben en una sesión, sobre todo en proyectos legacy, porque ahí te interesa que las decisiones queden escritas en la spec y no solo en el commit, y el camino corto del ODD, para los arreglos y las features pequeñas. Lo que no quitaría en ningún caso es un paso obligatorio que busque riesgos y deje por escrito lo que encuentra, como el analyze de Spec Kit o la capa RDD de gentle-ai, ni unas normas de la casa que se puedan comprobar, porque el error de esta prueba no estaba en ninguna tarea concreta y solo aparecía al juntar dos peticiones a la vez.

Preguntas frecuentes

¿Qué significa ODD en programación con IA?

ODD son las siglas de Organic Driven Development, el flujo de trabajo de gentle-ai en el que el agente entiende el código, clasifica la tarea como pequeña o grande e implementa con pruebas, y solo escribe documentación cuando la tarea es grande.

¿Qué diferencia hay entre SDD y ODD?

En el SDD el proceso es siempre el mismo (spec, plan, tareas y código) y lo decides tú, mientras que en el ODD es el agente quien decide cuánta ceremonia merece cada tarea. En mi prueba, ODD fue unas cuatro veces más rápido y más barato con el mismo resultado, pero sin un paso que le obligara a buscar riesgos.

¿Engram es un RAG?

Por cómo funciona se parece más a un RAG que a ampliar el contexto, pero con dos diferencias: no usa embeddings, porque lo guarda todo en un SQLite local y busca por palabras con búsqueda de texto completo (FTS5), y lo que hay dentro lo escribe el propio agente con herramientas MCP como mem_save, en vez de indexar tus documentos. Si te interesa la parte de RAG, te la explico en qué es Open Knowledge Format y qué arregla de tu RAG.

¿ODD sustituye a Spec Kit?

No. Lo que gentle-ai ha retirado es su propio SDD, y Spec Kit es un proyecto aparte, de GitHub, que sigue vivo; los dos se pueden usar con Claude Code.

¿Cuánto cuesta implementar una feature con Claude Code?

Depende de la feature y del método. En esta prueba, con el mismo modelo, Claude Code estimó 1,44 dólares para el flujo completo de Spec Kit y 0,38 para ODD, y si te quedas sin tokens a menudo, aquí tienes las 11 cosas que hago para que no me pase.

Capítulos del vídeo

Para ir más allá

Escribir una spec que un agente no pueda malinterpretar, con requisitos que se puedan comprobar y normas para tu proyecto, es justo lo que enseño en «Del vibe coding al Spec-Driven Development», y te sirve igual si usas Spec Kit, ODD o lo que venga después. Y si quieres entender cómo funciona un modelo por dentro, desde las matemáticas más básicas hasta los tokens y el contexto, lo explico desde cero en «El motor de la Inteligencia Artificial». Subo pruebas como esta a mi canal de YouTube, así que si te ha servido, suscríbete para no perderte la siguiente. ¡Que la IA te acompañe!

Qué es el ODD (Organic Driven Development) y en qué se diferencia del SDD