← Volver al listado de tecnologías ← Índice de Organic Driven Development (ODD)

Qué es ODD y de dónde viene

5 de noviembre de 2026 Por: Artiko

oddgentle-aisddfundamentos

Qué es ODD y de dónde viene

Objetivos

Ubicar ODD dentro del ecosistema de Gentle AI™.
Explicar con precisión qué es ODD y qué no es.
Conocer por qué SDD y OpenSpec se retiraron como flujo de trabajo.
Identificar los dos problemas que ODD intenta resolver al mismo tiempo.

Gentle AI en una página

Gentle AI configura el agente de programación que ya tienes. No es un agente propio: la documentación lo describe como una capa de configuración y arnés que no te instala el agente. Después de instalarlo abres tu proyecto, describes el resultado que quieres y trabajas como siempre.

El proyecto soporta 17 agentes en su descripción general, entre ellos Claude Code, OpenCode, Codex, Cursor, Gemini CLI, Windsurf, Kiro y Pi. Lo que instala en cada uno incluye instrucciones gestionadas, skills, memoria y, en algunos, revisión nativa.

Su modelo mental, tomado del texto que se instala en el orquestador, es breve:

Pedido pequeño: se hace directamente.
Trabajo sustancial autorizado: se usa ODD y el progreso se registra de forma automática.
La sesión principal orquesta y escribe inline; un worker acotado toma una unidad solo por un motivo con nombre.

flowchart TD
    A["Tu agente<br/>Claude Code, Codex, OpenCode..."] --> B["Gentle AI instala y refresca<br/>guía, skills, memoria y revisión"]
    B --> C["ODD<br/>cómo se hace el trabajo"]
    B --> D["RDD<br/>revisión independiente opcional"]
    B --> E["Engram<br/>memoria entre sesiones"]
    C --> F["Tu código"]
    D --> F
    E --> C

Qué es ODD

ODD es el flujo de desarrollo predefinido del orquestador. El texto que se instala lo dice así: todo pedido entra en él, en todo runtime, sin que el usuario pida un flujo, un plan o seguimiento de tareas.

La definición corta de la guía de uso es: explorar, implementar y hacer comprobaciones proporcionales. A eso se suma un único artefacto, y solo cuando hace falta:

Para trabajo pequeño ya comprendido, no se crea ningún artefacto duradero.
Para trabajo grande y autorizado, el agente crea por su cuenta un documento de feature después de explorar.
Las solicitudes de explicación, investigación y propuesta se quedan en modo de solo lectura.

Qué no es

La documentación es explícita en esto, y conviene retenerlo porque evita expectativas equivocadas:

ODD no es	Lo que dice la fuente
Un componente que se instala aparte	”Shared routing guidance, not a separate component to install” (`docs/components.md`)
Una CLI nueva	ODD agrega guía compartida, no una CLI ni un motor de estado
Una fase obligatoria de planificación	El trabajo sustancial no necesita una fase de planificación separada
Una garantía de cumplimiento	Las pruebas de instrucciones establecen que el texto se entrega, no que el modelo cumpla autónomamente cada paso
Un sistema de revisión	La revisión nativa es RDD, tiene su propio interruptor y ODD nunca la activa

El cuarto punto merece atención. ODD vive en gran parte como instrucciones para un modelo. Hay pruebas que confirman que esas instrucciones llegan a cada agente, pero el propio proyecto aclara que eso no demuestra que un modelo en vivo las siga siempre.

El binario y la guía se reparten el trabajo

El README describe la frontera así: el binario gentle-ai es dueño de las transiciones de la revisión nativa (RDD), mientras que la guía de ODD mantiene el trabajo ordinario proporcional al pedido. Por eso en este curso verás dos tipos de regla:

Reglas de guía, que el modelo debe seguir, como la clasificación de una tarea.
Reglas de código, que el binario aplica, como el campo review_due de gentle-ai review assess.

De dónde viene: el retiro de SDD

Antes de la versión 4, Gentle AI ofrecía SDD (Spec-Driven Development) con OpenSpec junto a ODD. El issue público #4959 plantea el problema así: SDD y OpenSpec seguían siendo un segundo flujo activo, con comandos, contratos y recursos instalados que conservaban rutas de ejecución que ya no se querían ofrecer. También registra la alternativa descartada: mantener SDD como opción no cumplía la meta de que ODD fuera el único flujo.

Las notas de v4.0.0 lo resumen: ODD pasa a ser el único flujo de desarrollo, mientras la revisión nativa independiente (RDD) y el desarrollo test-first siguen disponibles. Como la guía test-first se instala por defecto, el TDD estricto dejó de ser una elección aparte.

timeline
    title Evolución de ODD según las notas de versión
    v3.7 : Último estable antes del cambio : SDD y ODD conviven
    v4.0.0 : ODD es el único flujo : Se retiran SDD y OpenSpec : Test-first por defecto
    v4.1.0 : Revisión proporcional : Delegación por motivo : Limpieza de instalaciones SDD
    v4.2.0 : El enrutamiento de Gentle Shell llega por el contrato de proveedor
    v4.3.1 : Última versión en la fecha de este curso

Una diferencia concreta con SDD

Una especificación del propio proyecto recoge una frase del mantenedor que resume la diferencia en cómo se manejan los cambios de requisitos:

“A diferencia de SDD, un cambio no re hace todo, solo re hace esa spec y la tarea asociada.”

odd/tasks/odd-spec-by-reference.md, S3

La idea se ve de nuevo en el texto canónico: los cambios aceptados actualizan la intención y las tareas afectadas, “a diferencia de un proceso que regenera todos los artefactos”.

Compatibilidad con instalaciones antiguas

El retiro cuidó lo que ya existía:

Una selección sdd guardada en el estado todavía se lee, pero install y sync ya no escriben sus recursos.
Una instalación o sincronización global elimina los subagentes sdd-* propiedad de Gentle AI.
La desinstalación heredada elimina solo los recursos cuya propiedad se puede demostrar, y conserva los archivos del usuario.
Las claves guardadas siguen legibles. Por ejemplo, en Codex los roles odd-explorer, odd-worker y odd-verify mapean a las claves heredadas sdd-cheap, sdd-mid y sdd-strong.

Por eso aún puedes encontrar el texto sdd en el código sin que signifique que el flujo sigue activo.

Los dos problemas que ataca

El README los plantea en una sola frase: los cambios pequeños no deberían necesitar un proceso de planificación, y el trabajo mayor no debería perder su contexto entre sesiones.

quadrantChart
    title Proceso frente a contexto (síntesis del curso)
    x-axis Poco contexto para reanudar --> Mucho contexto para reanudar
    y-axis Poco proceso --> Mucho proceso
    quadrant-1 Proceso justificado
    quadrant-2 Ceremonia innecesaria
    quadrant-3 Trabajo directo
    quadrant-4 Contexto perdido

Problema	Síntoma	Respuesta de ODD
Ceremonia en trabajo pequeño	Un bug de tres líneas consume decenas de turnos y varios subagentes	Una tarea pequeña corre inline, sin subagentes ni documento
Pérdida de contexto en trabajo grande	Otra sesión o un subagente recibe una paráfrasis y pierde requisitos	Un documento de feature recuperable, con la especificación textual

La tabla de mediciones del README aporta un ejemplo de cada uno, y el capítulo 22 la analiza con sus limitaciones. Según esas corridas, cada una de una sola ejecución, un bug de tres líneas pasó de 56 turnos a 10, y una especificación de 73 líneas que seguía fallando tras dos rondas de corrección dejó de hacerlo al pasarse por referencia.

Un tercer problema: las decisiones que no se sostienen

La crónica del mantenedor sobre RDD agrega otra motivación. Cuenta que escribió una auditoría, la entregó a un agente, y este dedujo necesidades empresariales que nadie había pedido, como soporte HTTP y ejecución remota, y las construyó de forma coherente y completa. Retirar todo eso consumió tres reinicios mensuales de cuota.

Su conclusión, que explica buena parte del diseño:

Las buenas decisiones humanas no sobreviven al contacto con un agente a menos que algo las haga cumplir.

docs/architecture/the-organic-rdd-story.md (traducción propia)

Actividad

Toma un proyecto tuyo y escribe tres pedidos reales que le harías a un agente: uno que sea una pregunta, uno que sea un arreglo pequeño y uno que probablemente te ocupe varias sesiones. Guárdalos: los clasificarás con el protocolo en los capítulos siguientes.

Autoevaluación

¿Qué describe mejor a ODD según la documentación?
- A. Un componente opcional que se selecciona en el instalador
- B. Un agente de programación propio de Gentle AI
- C. Guía de enrutamiento compartida que se instala en cada agente
- D. Un motor de estado que controla cada paso con el binario
¿Cuántos documentos de feature crea ODD para una tarea pequeña y comprendida?
- A. Uno, sin excepción
- B. Uno, si la tarea toca más de un archivo
- C. Dos: uno local y su copia en Engram
- D. Ninguno
¿Qué consideró insuficiente el issue #4959 respecto de SDD?
- A. Mantenerlo como opción, porque no cumplía la meta de un único flujo
- B. Su velocidad frente a ODD en los benchmarks
- C. Su compatibilidad con Windows
- D. El costo de sus modelos
¿Qué demuestran las pruebas de instrucciones de ODD, según la propia documentación?
- A. Que los modelos siguen cada paso de forma autónoma
- B. Que el texto llega a los agentes, no que se cumpla siempre
- C. Que el binario bloquea cualquier desvío
- D. Que RDD se activa de forma automática

Respuestas

C. docs/components.md la define como guía de enrutamiento compartida, no como un componente aparte.
D. El trabajo pequeño no crea artefactos duraderos. Esta regla no depende del número de archivos.
A. Las notas del issue descartan la opción de mantener SDD como alternativa opcional.
B. La guía de uso aclara que establecen la entrega, no el cumplimiento autónomo.

Lista de control

Puedo explicar la diferencia entre Gentle AI, ODD, RDD y Engram.
Sé qué queda en solo lectura y qué recibe un documento de feature.
Entiendo por qué aparecen claves sdd-* en el código aunque SDD esté retirado.
Distingo una regla de guía de una regla aplicada por el binario.

Fuentes

README.md, docs/usage.md, docs/intended-usage.md, docs/components.md, docs/architecture/the-organic-rdd-story.md, internal/assets/skills/_shared/odd-orchestrator-sections.md, internal/model/codex_model.go, odd/tasks/odd-spec-by-reference.md, issue #4959 y notas de v4.0.0 y v4.1.0.