Organic Driven Development (ODD): una nueva forma de desarrollar software con agentes de IA
La inteligencia artificial está cambiando la forma en la que desarrollamos aplicaciones, pero también está poniendo de manifiesto un problema que hasta hace poco apenas nos planteábamos: ¿cómo debemos organizar el trabajo cuando quien escribe buena parte del código es un agente de IA?
Herramientas como Claude Code, Codex, Cursor u OpenCode permiten delegar tareas que antes realizábamos manualmente. Pueden analizar proyectos, modificar archivos, ejecutar pruebas y proponer implementaciones completas.
Sin embargo, disponer de un agente capaz de generar código no garantiza que el proceso sea eficiente. Puede modificar archivos sin comprender el proyecto, generar documentación innecesaria, perder el contexto de una implementación o introducir cambios que nadie había solicitado.
Para abordar estos problemas están apareciendo metodologías orientadas específicamente al desarrollo asistido por inteligencia artificial. Una de ellas es Organic Driven Development (ODD), un enfoque incorporado al ecosistema Gentle-AI de Gentleman Programming.
Su propuesta es sencilla: adaptar el proceso de desarrollo a las necesidades reales de cada tarea, utilizando únicamente el nivel de planificación, documentación y verificación necesario. Pero detrás de esa idea hay decisiones interesantes desde el punto de vista de la ingeniería de software.
¿Qué es Organic Driven Development?
Organic Driven Development, o simplemente ODD, es un flujo de trabajo para desarrollar software con agentes de IA que ajusta la organización y la ejecución según la complejidad, el riesgo y el grado de comprensión de la tarea.
Su objetivo es evitar dos extremos habituales. El primero consiste en pedir directamente a un agente que implemente una funcionalidad sin análisis suficiente. El segundo impone un proceso de planificación excesivamente complejo incluso para cambios triviales.
ODD busca un equilibrio: una modificación sencilla puede resolverse después de examinar el código relevante; una funcionalidad importante puede necesitar investigación, documentación persistente, división en tareas, pruebas y revisiones. El flujo es común, pero su ejecución se adapta al trabajo.
Conviene aclarar que ODD no es una arquitectura de aplicación. No define cómo organizar controladores, servicios, entidades o módulos. Es una metodología operativa: establece cómo debe comportarse un agente durante el desarrollo.
El problema que intenta solucionar ODD
Los primeros asistentes de programación devolvían código y el desarrollador decidía si incorporarlo. Los agentes actuales pueden asumir operaciones mucho más amplias:
Utiliza el sistema de autenticación existente.
Añade los endpoints necesarios.
Crea las pruebas.
Actualiza la documentación.
Un agente puede intentar completar todo el proceso. El problema aparece cuando la petición es ambigua o desconoce decisiones importantes del proyecto: quizá existe un servicio de correo reutilizable, se deben registrar las operaciones de seguridad o los tokens tienen restricciones concretas.
Si empieza a programar inmediatamente puede entregar una solución funcional, pero incompatible con la arquitectura existente. Obligarle a planificar primero parece la respuesta, aunque plantea otra pregunta: ¿tiene sentido exigir una especificación y un plan completos para corregir una errata? Probablemente no. Precisamente ahí aparece ODD.
De Spec-Driven Development a Organic Driven Development
Una metodología relevante para los agentes es Spec-Driven Development (SDD). Su planteamiento usa especificaciones estructuradas para dirigir la implementación.
Planificación de tareas → Implementación → Verificación → Cierre
Este procedimiento es útil para funcionalidades complejas o decisiones importantes, pero generar y mantener documentos requiere tiempo, contexto y recursos del modelo. Si una tarea solo cambia un mensaje de error, recorrer todas las etapas aporta poco valor.
ODD cambia el criterio: en lugar de exigir siempre la misma documentación, determina qué necesita cada cambio.
| Situación | Enfoque ODD |
|---|---|
| Corregir un texto | Explorar y modificar directamente |
| Resolver un error localizado | Investigar, reproducir, corregir y verificar |
| Añadir una funcionalidad importante | Crear documentación recuperable y dividir el trabajo |
| Modificar autenticación | Evaluar riesgos, aplicar controles y verificar |
| Investigar una mejora | Analizar sin modificar código |
SDD no desaparece: dentro de Gentle-AI puede seguir utilizándose cuando se solicita un proceso formal de especificación. ODD se convierte en el flujo habitual.
Las siete etapas de Organic Driven Development
La implementación documentada de ODD en Gentle-AI se organiza en siete etapas. No deben entenderse como siete documentos obligatorios, sino como reglas de comportamiento para el agente.
1. Authorize: comprobar qué está autorizado
El primer paso es determinar si el usuario ha pedido realmente modificar el proyecto. La diferencia entre «analiza cómo funciona el módulo de autenticación» y «modifica el módulo para añadir tokens de actualización» es fundamental: la primera instrucción autoriza una investigación y la segunda una implementación.
ODD establece que las solicitudes de investigación, explicación o análisis se mantienen en modo de solo lectura salvo que exista autorización para cambiar archivos. Esto reduce el riesgo de modificaciones inesperadas.
2. Explore: comprender antes de implementar
Una vez identificada la intención, el agente examina el contexto relevante. No necesita leer todo el repositorio: necesita entender lo suficiente para decidir bien. En una aplicación NestJS que va a incorporar un endpoint debería revisar cómo se organizan módulos, servicios, autorización y convenciones.
auth/
auth.controller.ts
auth.service.ts
auth.module.ts
users/
users.controller.ts
users.service.ts
users.module.ts
Si la funcionalidad ya dispone de servicios reutilizables, el agente debería identificarlos. ODD intenta evitar que la generación de código preceda a la comprensión del sistema.
3. Resolve uncertainty: resolver incertidumbres reales
Los agentes pueden tomar decisiones por su cuenta, pero no todas las decisiones deberían delegarse. Ante «añade la posibilidad de eliminar usuarios», ¿eliminar significa borrar físicamente el registro o desactivarlo? La respuesta afecta al modelo de datos, las relaciones, el histórico y quizá a requisitos legales.
ODD contempla investigar las incertidumbres relevantes y solicitar aclaraciones cuando exista una decisión real de producto. La clave es evitar tanto las suposiciones arriesgadas como las preguntas innecesarias.
4. Classify: determinar el tamaño real del trabajo
La complejidad no se calcula contando archivos o líneas. Una modificación de tres archivos puede ser sencilla; una línea que afecte a autenticación puede ser delicada. ODD considera si la tarea está comprendida, si existen riesgos, si puede completarse y revisarse de manera localizada y si sería posible retomarla después de una interrupción con la petición original y el diff.
Una tarea pequeña y comprendida puede ejecutarse sin documentación persistente. Una tarea sustancial que debe conservar contexto requiere otro tratamiento.
5. Track: registrar el trabajo cuando sea necesario
Cuando una implementación es suficientemente importante, ODD introduce un documento de seguimiento. En Gentle-AI puede utilizarse una estructura como esta:
tasks/
password-recovery.md
El documento recoge alcance, requisitos, tareas, estado y evidencias. Una versión simplificada podría incluir requisitos para solicitar un enlace, caducidad de 30 minutos y uso único del token; además de una lista de tareas para implementar generación, validación, endpoint, pruebas y documentación.
Lo importante no es el formato exacto, sino que funciona como una referencia persistente. Si el agente pierde el contexto o el trabajo se interrumpe, puede retomarlo sin reconstruir todo el proceso desde cero.
6. Implement: implementar y verificar proporcionalmente
Tras comprender y organizar la tarea comienza la implementación. ODD propone usar el mecanismo de ejecución más pequeño que aporte valor: trabajar directamente en un cambio sencillo o delegar partes independientes a agentes especializados cuando esté justificado.
También contempla pruebas antes de implementar cuando hay un comportamiento verificable y un mecanismo de testing adecuado.
↓
Implementación de la corrección
↓
Prueba superada
↓
Refactorización
El enfoque se relaciona con TDD, aunque ODD no es otra denominación para él. La diferencia clave es exigir evidencias reales: que un agente afirme que algo funciona no equivale a demostrarlo.
7. Close: cerrar con resultados verificables
La última etapa informa del resultado distinguiendo claramente qué se ha implementado, qué se ha verificado y qué queda pendiente.
• Nuevo endpoint
• Validación de tokens
• Pruebas unitarias
Verificado:
• Compilación correcta
• Pruebas ejecutadas
Pendiente:
• Prueba E2E con servicio de correo real
Esta distinción evita presentar una implementación como terminada cuando todavía hay verificaciones pendientes.
El papel de la memoria persistente
Los agentes trabajan con ventanas de contexto limitadas. Incluso cuando son grandes, los proyectos reales pueden requerir sesiones largas o múltiples intervenciones. Un agente puede descubrir una restricción arquitectónica y perderla antes de terminar la funcionalidad.
Gentle-AI utiliza Engram como sistema de memoria persistente para conservar decisiones, descubrimientos y contexto entre sesiones. ODD combina esa memoria con documentos de trabajo para retomar tareas relevantes. No es la memoria temporal del modelo: es información recuperable fuera de la conversación activa.
Un ejemplo práctico: ODD en React y NestJS
Supongamos una aplicación con React, NestJS, PostgreSQL y TypeORM. La petición es permitir que un usuario solicite modificar un registro, guarde el motivo y un administrador pueda aprobar o rechazar la solicitud. La aprobación debe mantener el estado anterior, aplicar el cambio en una transacción e incluir pruebas de ambos resultados.
El agente empezaría investigando registros, entidades de usuarios y permisos, además de comprobar si ya existen auditorías o transacciones reutilizables. No es un cambio de texto: hay estados, persistencia, permisos y operaciones que afectan a varios registros. Por tanto, es razonable crear odd/tasks/record-modification.md con requisitos y tareas.
La implementación puede avanzar desde el modelo de datos a servicios y transacciones, endpoints y permisos, interfaz y pruebas. No siempre conviene lanzar varios agentes: si modifican entidades o servicios simultáneamente, aumentan los conflictos.
La validación debería confirmar que una solicitud no aprobada no cambia el registro, un usuario sin permiso no puede aprobar, el histórico conserva los datos anteriores y un fallo de transacción no deja datos parcialmente modificados.
¿Qué diferencia ODD de Agile, TDD y Clean Architecture?
| Enfoque | Problema principal que aborda |
|---|---|
| Agile | Organización del trabajo y adaptación al cambio |
| TDD | Desarrollo dirigido por pruebas |
| Clean Architecture | Organización de dependencias y responsabilidades |
| SDD | Desarrollo guiado por especificaciones |
| ODD | Organización proporcional del trabajo ejecutado por agentes |
ODD no sustituye necesariamente a los demás. Podemos aplicar Clean Architecture a la aplicación, TDD a la lógica de negocio y ODD a la forma de organizar el trabajo del agente: son niveles distintos.
Ventajas de Organic Driven Development
La principal ventaja es reducir burocracia sin eliminar controles. Ajusta la organización al trabajo real y puede aportar:
- Menos documentación innecesaria: los cambios sencillos no requieren una colección de documentos.
- Mayor continuidad entre sesiones: las tareas importantes conservan requisitos, decisiones y estado recuperables.
- Mejor control de modificaciones: diferenciar investigación e implementación limita cambios no solicitados.
- Verificación basada en evidencias: se reconocen explícitamente las comprobaciones pendientes.
- Menor dependencia de instrucciones manuales: el flujo habitual no exige pedir cada etapa por separado.
Limitaciones de ODD
La metodología tiene ideas razonables, pero no todas sus decisiones están validadas empíricamente para cualquier proyecto.
La clasificación puede fallar
Determinar qué es sencillo y qué es sustancial requiere juicio. «Modifica la duración de los tokens de sesión» quizá sea una línea, pero puede tener consecuencias de seguridad importantes.
No elimina los errores de los modelos
ODD proporciona reglas de trabajo; no garantiza que la IA comprenda requisitos ni produzca código seguro.
La memoria puede quedar desactualizada
La información persistente solo ayuda si refleja el estado real del proyecto. Una memoria incorrecta introduce errores difíciles de detectar.
La implementación importa tanto como la metodología
Hay una diferencia entre describir un protocolo en instrucciones y disponer de un sistema que compruebe su cumplimiento. Un modelo puede ignorar una regla o afirmar que verificó algo sin hacerlo. Por eso los controles ejecutables, los tests y la revisión humana siguen siendo necesarios.
¿Tiene sentido utilizar ODD en cualquier proyecto?
No necesariamente. Para un script pequeño o una aplicación de prueba, incorporar memoria y seguimiento puede ser innecesario. Puede resultar más útil en repositorios grandes, desarrollo continuado, módulos relacionados, uso frecuente de agentes, requisitos de trazabilidad, riesgo de regresión o tareas que deben retomarse entre sesiones.
También es útil para equipos que usan agentes pero aún no tienen criterios comunes sobre cuándo investigar, documentar, implementar o verificar. ODD no debería convertirse en otra fuente de complejidad: si aplicarlo cuesta más que resolver el problema, contradice su propósito.
El verdadero cambio está en cómo organizamos el desarrollo
Las metodologías se diseñaron durante mucho tiempo alrededor del trabajo humano. Los agentes introducen un participante que puede ejecutar partes relevantes del proceso y obligan a replantear preguntas: ¿cuándo puede actuar autónomamente?, ¿cuándo requiere autorización?, ¿qué información debe conservar?, ¿qué cambios requieren pruebas?, ¿cuándo merece la pena delegar y cómo demostramos que el resultado es correcto?
ODD propone respuestas operativas sin imponer un procedimiento pesado a todas las tareas. Su planteamiento es utilizar el nivel de proceso adecuado para cada situación.
Conclusión
Organic Driven Development reúne prácticas conocidas —investigar antes de programar, trabajar en tareas pequeñas, conservar decisiones y verificar resultados— en un flujo que adapta su aplicación al trabajo de un agente.
Frente a metodologías rígidas, propone una organización proporcional: poca ceremonia para un cambio sencillo y mayor trazabilidad para un trabajo complejo. Conviene mantener una mirada crítica: ODD es una propuesta reciente vinculada a Gentle-AI, no un estándar consolidado ni una garantía de calidad. Su utilidad dependerá de la implementación, la fiabilidad de los agentes y los mecanismos de verificación.
La cuestión ya no es solo si un agente puede escribir código. También debemos decidir bajo qué condiciones puede modificar nuestro software y cómo comprobaremos que su trabajo es correcto. Ese es el problema que Organic Driven Development intenta resolver.