ODD vs SDD: qué es Organic Driven Development y por qué reemplaza al Spec-Driven Development en Gentle-AI

ODD (*Organic Driven Development*) es la forma de trabajar con agentes de programación que Gentle-AI usa por defecto desde su versión 4: el agente entiende primero lo que le pides, decide cuánta estructura necesita la tarea y solo escribe documentos de planificación cuando el trabajo es grande. SDD (*Spec-Driven Development*) es lo contrario: cada feature pasa por fases fijas (especificación, plan, tareas, implementación) antes de tocar el código.

En este artículo explicamos qué es cada uno con datos comprobados en sus repositorios, de dónde sale ODD, qué críticas tiene SDD, una tabla para elegir y cómo aplicar la idea de ODD en Claude Code aunque no instales nada.

Primero, una aclaración: qué significa ODD

Si has visto ODD explicado como *Objective-Driven Development*, no es el nombre que usa su autor. En el repositorio y la documentación de Gentle-AI, ODD es Organic Driven Development. "Orgánico" porque el proceso crece con la tarea: una corrección de tres líneas no genera ningún documento y una feature de varias sesiones genera uno solo.

Las siglas ODD también se usan para otras cosas que no tienen relación con esto: *Observability-Driven Development* (diseñar pensando en métricas y trazas), *Outcome-Driven Development* (hay skills de Claude con ese nombre orientadas a personas no técnicas) u *Outline-Driven Development* (un plugin de Claude Code centrado en diagramas). Cuando alguien hable de "ODD contra SDD" en el contexto de agentes de IA, casi siempre se refiere al de Gentle-AI.

Qué es SDD (Spec-Driven Development)

SDD propone que la especificación sea el centro del trabajo con un agente: antes de pedir código, escribes (o haces que el agente escriba) qué se construye, por qué y con qué criterios de aceptación. Luego el agente deriva de ahí un plan técnico, una lista de tareas y la implementación. La idea es reducir el *vibe coding*, donde el agente decide por ti en cada mensaje.

Las tres herramientas más conocidas:

En Spec Kit (comprobado en su README, versión 1.2.x de octubre de 2026) el flujo mínimo son seis comandos en el chat del agente: /speckit-constitution una vez por proyecto y después, por cada feature, /speckit-specify, /speckit-plan, /speckit-tasks, /speckit-implement y /speckit-converge, repitiendo los dos últimos hasta que el informe diga *Converged*. Kiro escribe los requisitos con el patrón EARS: "WHEN [evento] THE SYSTEM SHALL [comportamiento]".

Birgitta Böckeler (Thoughtworks) distingue tres niveles de SDD en su análisis publicado en martinfowler.com en octubre de 2025:

• Spec-first: la especificación se escribe antes de la tarea y la guía. Todas las herramientas lo hacen.
• Spec-anchored: la especificación se mantiene después y sirve para evolucionar la feature.
• Spec-as-source: la especificación es el único archivo que editas; el código se regenera. Es la apuesta de Tessl.

Los problemas de SDD en el día a día

SDD resuelve un problema real, pero tiene un coste que se nota en cuanto lo usas en tareas normales. Böckeler probó Kiro y Spec Kit y describió tres problemas:

1. Desproporción. Para un bug pequeño, Kiro convirtió la corrección en cuatro historias de usuario con 16 criterios de aceptación.
2. Demasiado Markdown que revisar. Spec Kit generó muchos archivos repetitivos entre sí y con el código existente. Su conclusión: "I'd rather review code than all these markdown files" (prefiere revisar código antes que tantos archivos Markdown).
3. El agente no siempre sigue la especificación. Aun con documentos extensos y checklists, vio al agente ignorar notas sobre clases existentes y volver a crearlas, con duplicados.

Las propias herramientas lo han ido reconociendo. El README actual de Spec Kit añade un flujo aparte para corregir bugs (specify extension add bug, con /speckit-bug-assess, /speckit-bug-fix y /speckit-bug-test) y aclara que no hace falta pasar antes por el flujo completo de SDD. OpenSpec resume su filosofía en "fluido, no rígido" e "iterativo, no cascada".

De dónde sale ODD: Gentle-AI

Gentle-AI es un proyecto de Gentleman Programming (la comunidad de Alan Buscaglia) con licencia MIT. No es un agente propio: es un instalador y un conjunto de instrucciones, skills, memoria (Engram) y revisión que se inyectan en el agente que ya usas. Según su README da soporte a 18 agentes, entre ellos Claude Code, Codex, Cursor, Gemini CLI, OpenCode y Kiro.

Su historia con SDD explica el cambio:

Hemos comprobado las fechas en las etiquetas del repositorio y el documento de la retirada en odd/tasks/remove-sdd-odd-only-main.md: su objetivo literal era dejar ODD como "el único flujo de desarrollo". Ese documento es, además, un ejemplo real del formato que ODD usa para el trabajo grande. En el repositorio hay 53 documentos así en odd/tasks/.

Cómo funciona ODD: el protocolo de 7 pasos

ODD se aplica en cada petición, sin que tengas que pedir un plan ni elegir un modo. La documentación (docs/usage.md) lo define en siete pasos:

1. Autorizar. ¿La petición pide un cambio? Si solo es una pregunta, una revisión o una propuesta, el agente no toca nada.
2. Explorar el código y los requisitos existentes, en proporción a la petición.
3. Resolver la incertidumbre. Investigación opcional para una duda concreta, una sola pregunta si hay una decisión de producto real y, como mucho, un cuestionamiento de una premisa arriesgada.
4. Clasificar. Una tarea es pequeña si se entiende, su riesgo está acotado y se podría retomar solo con la petición y git diff. Es grande solo si esa prueba falla: varias sesiones, esperas externas o requisitos que no sobrevivirían a una compactación del contexto. El número de archivos o de líneas no decide.
5. Registrar antes de escribir. Si es grande, crea un documento de feature antes del primer cambio y te dice en una línea cuál es y cuántas tareas tiene.
6. Implementar tarea a tarea, con test primero cuando hay un test ejecutable que tenga sentido, commits revisables de unas 400 líneas (orientativo, no un límite) y cada tarea marcada solo con una prueba observada.
7. Cerrar informando del resultado verificado, de cada comprobación fallida o pendiente y del siguiente paso.

El documento de feature: SDD solo cuando hace falta

Para el trabajo grande, ODD usa un único archivo, odd/tasks/<feature>.md, con un orden fijo:

# Nombre de la feature

## Specs
S1. Requisito con tus textos, mensajes de error y ejemplos copiados literalmente.
    Criterio de aceptación y cómo se comprueba.

## Tasks
- [ ] T1 (S1) · ruta: en línea · commit: pendiente

## Log
L1. Tu petición original, literal.
L2. Correcciones, evidencias y decisiones que se van añadiendo.

Los subagentes reciben una referencia a ese documento y a su S#, nunca un resumen de tu petición. Es la diferencia práctica con muchos flujos de SDD, donde cada fase reescribe lo que dijiste con otras palabras. Gentle-AI cuenta en su README que, con una especificación de 73 líneas y 26 comprobaciones ocultas, los traspasos parafraseados dejaron 13 fallos y seguían en 23 de 26 tras dos rondas de correcciones; el cambio que lo resolvió fue pasar la especificación por referencia (gentle-shell#1718).

Lo que dicen sus mediciones (con cautela)

El README publica pruebas con su propio entorno, Gentle Shell. Cada celda es una sola ejecución (n=1) y el coste es el equivalente en API, así que tómalo como indicio, no como estudio:

El patrón es el que cabría esperar: en lo pequeño ODD ahorra mucho; en lo arriesgado no ahorra dinero, pero acierta antes. El mismo README admite que en la tarea grande tardó unas tres veces más que Codex CLI con el mismo modelo.

SDD vs ODD: diferencias clave

La lectura honesta: ODD no elimina las especificaciones, elimina la obligación de escribirlas para todo. Para una feature grande sigue habiendo una spec con criterios de aceptación; la diferencia es que vive en un solo archivo y conserva tus palabras exactas.

Cuándo usar SDD, cuándo ODD

• ODD encaja en el trabajo diario: bugs, ajustes, features de una o varias sesiones en un proyecto que ya existe, y equipos pequeños o personas solas con un agente.
• SDD sigue teniendo sentido cuando la especificación es un entregable en sí: un proyecto nuevo que hay que acordar con un cliente, equipos grandes donde varias personas o agentes implementan contra el mismo contrato, o sectores donde necesitas trazabilidad formal de requisitos.
• Mezclar es razonable: un PRD y una arquitectura al empezar un proyecto (eso es SDD ligero) y ODD para cada ticket después.

Cómo aplicar ODD en Claude Code

Opción 1: instalar Gentle-AI

Gentle-AI instala las instrucciones de ODD (y su memoria y revisión) en tu agente. En macOS o Linux, según su README:

brew install gentleman-programming/tap/gentle-ai
gentle-ai install --agent claude-code --dry-run

--dry-run muestra el plan sin aplicar cambios. En Windows se instala con Go 1.25.10 o superior (go install github.com/gentleman-programming/gentle-ai/v4/cmd/gentle-ai@latest). Ten en cuenta que no es solo ODD: también activa Engram, una persona, permisos y RDD (su revisión de código, activada por defecto; se desactiva con gentle-ai review mode disable). Revisa el plan antes de aplicarlo, sobre todo si ya tienes un CLAUDE.md trabajado; el instalador hace copia de seguridad antes de tocar archivos gestionados.

No lo hemos instalado en esta prueba: el binario necesita Go 1.25.10 y nuestro entorno tenía 1.24. Lo que sí hemos revisado es el texto que inyecta en Claude Code (internal/assets/claude/orchestrator.md, unas 2.700 palabras), cuya primera sección obligatoria declara ODD como flujo por defecto.

Opción 2: la idea de ODD en tu CLAUDE.md

Si no quieres instalar un ecosistema entero, puedes copiar el principio. Este bloque es nuestro, inspirado en el protocolo de Gentle-AI:

## Cómo trabajar (proporcional al tamaño)

- Si la petición es una pregunta, una revisión o una propuesta, no modifiques archivos.
- Antes de cambiar código, lee el código afectado. Pregunta solo si queda una decisión de producto real, y una vez.
- Tarea pequeña (se entiende y se podría retomar con git diff): hazla directamente, test primero si hay un test útil, sin documentos de plan.
- Tarea grande (varias sesiones o requisitos largos): antes del primer cambio crea docs/tareas/<feature>.md con
  ## Specs (mis textos literales y criterios de aceptación), ## Tasks y ## Log (L1 = mi petición literal).
- Marca una tarea como hecha solo con una prueba ejecutada. Al terminar, di qué se verificó y qué queda pendiente.

Si buscas más disciplina que esto, Superpowers impone diseño, plan y tests antes de programar, y para llevar los tickets fuera del repositorio tienes It's a Plan. Si las skills son nuevas para ti, empieza por la guía de skills de Claude Code.

Errores frecuentes al pasar de SDD a ODD

• Creer que ODD es "sin plan". El plan existe para el trabajo grande. Si el agente empieza una feature de tres días sin documento, no está haciendo ODD.
• Clasificar por número de archivos. Un renombrado en 40 archivos puede ser pequeño; un cambio de 20 líneas en la autenticación puede no serlo. La pregunta es si se puede retomar con el diff y si el riesgo está acotado.
• Dejar que el agente resuma tu petición. La ventaja de ODD es guardar tus textos literales. Si en ## Specs aparecen tus requisitos reescritos, pide que copie los originales.
• Marcar tareas sin pruebas. Una casilla marcada sin un test o una comprobación ejecutada es una promesa, no una evidencia.
• Mantener SDD y ODD a la vez sin decirlo. Si tienes Spec Kit instalado y además instrucciones de ODD, indica en CLAUDE.md cuál manda, o el agente mezclará ambos flujos.

Preguntas frecuentes

¿ODD significa Objective-Driven Development?

No en Gentle-AI, que es donde nace este enfoque. Su nombre oficial es Organic Driven Development. Otras siglas ODD (Observability, Outcome u Outline-Driven Development) son metodologías distintas.

¿ODD sustituye a SDD en general?

Sustituye a SDD dentro de Gentle-AI desde la v4.0.0. Fuera de ahí, Spec Kit, Kiro y OpenSpec siguen activos y actualizándose. ODD es una postura sobre cuánta especificación hace falta, no el final de las especificaciones.

¿Qué herramientas de SDD hay?

Las más usadas son GitHub Spec Kit (MIT), Kiro de AWS y OpenSpec (MIT). Tessl apuesta por el nivel más extremo, donde la especificación es el código fuente.

¿Funciona ODD con Claude Code, Codex o Cursor?

Sí. Gentle-AI configura Claude Code, Codex, Cursor, Gemini CLI, OpenCode, Kiro y otros agentes. Y la idea se puede aplicar sin instalar nada con un bloque en CLAUDE.md o AGENTS.md.

¿ODD obliga a usar TDD?

Aplica test primero por defecto cuando existe un test ejecutable útil y un resultado esperado claro: un test que falla por cada regla pedida y uno que protege cada comando existente que se toca. Si no hay un test con sentido, el agente lo explica y hace comprobaciones funcionales.

Conclusión

SDD puso orden en el trabajo con agentes, pero aplicado a todo convierte un bug de tres líneas en un expediente. ODD conserva lo útil (explorar antes de tocar, especificación literal y criterios de aceptación para lo grande, tests y evidencias) y lo quita donde no aporta. Para empezar, copia el bloque de CLAUDE.md de este artículo y observa en tu próximo ticket si el agente deja de generar documentos que nadie lee.

Fuentes: Gentle-AI (README y docs/usage.md, v4.2.0) · GitHub Spec Kit y su anuncio en el blog de GitHub · Kiro: conceptos de specs · OpenSpec · Birgitta Böckeler, "Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl".