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

Antipatrones y evaluación final

5 de noviembre de 2026 Por: Artiko

oddantipatronesevaluacionadopcion

Antipatrones y evaluación final

Objetivos

Reconocer los antipatrones que las reglas de ODD nombran.
Aplicar una lista de control a cada pedido.
Planificar la adopción en un equipo.
Comprobar lo aprendido con un examen final.

Antipatrones

Cada fila corresponde a algo que las fuentes prohíben o describen como defecto.

Enrutamiento

Antipatrón	Regla que lo descarta
Delegar porque toca muchos archivos	El número de archivos nunca decide
Un writer para el código, otro para pruebas y otro para docs	Una unidad lleva todo eso junto
Explorar y luego releer los mismos archivos para escribir	Nunca explorar lo que se va a leer de todas formas
Ignorar un disparador porque “igual salió bien”	Es un defecto de enrutamiento aunque tenga éxito
Tratar “no está claro” como alto riesgo de entrada	Solo si una mirada acotada no puede determinarlo
Lanzar un verificador por tamaño o por el modelo	Solo por un punto de alto riesgo nombrado

Documento y traspaso

Antipatrón	Regla que lo descarta
Crear un documento para una tarea reanudable desde el diff	El documento solo surge de una prueba de reanudación fallida
Mejorar la redacción de lo que pidió el usuario	Citas textuales, sin resumir ni reformular
Agregar requisitos razonables que nadie pidió	”Do not add requirements the user never asked for”
Pasar un resumen al worker	Referencia al documento, nunca paráfrasis
Regenerar todo al cambiar un requisito	Solo la `S#` y su tarea
Tener un archivo de plan aparte	Un solo documento
Marcar una casilla sin observar el resultado	Solo con el resultado y la prueba aplicable

Pruebas y comprobaciones

Antipatrón	Regla que lo descarta
Inventar una ejecución RED o GREEN	Nunca se inventa evidencia
Inventar un ejecutor de pruebas	Si falta, se informa
Rellenar con casos extra	Una por regla, una por opción afectada, ninguna más
Declarar `Risk: none` sin revisar el código compartido	Hay una comprobación específica antes
Editar una prueba existente que falla para que pase	Se detiene y se informa
Formatear después de verificar	Cualquier cambio de bytes obliga a repetir
Repetir correcciones hasta que quede limpio	Un lote, una recomprobación
Usar una evaluación fallida como riesgo bajo	Nunca se deduce riesgo bajo

Control y entrega

Antipatrón	Regla que lo descarta
Corregir lo que se encontró durante una revisión pedida	La revisión es de solo lectura
Hacer push porque “ya está aprobado”	La aprobación no autoriza la entrega
Terminar con “¿continúo?” sobre un paso autorizado	Se ejecuta en lugar de anunciarlo
Detenerse porque el usuario dijo que quizá pare	Una redacción tentativa no es una parada
Discutir cuando el usuario pide apagar RDD	Se ejecuta `disable` sin discutir
Borrar comentarios para llegar a 400 líneas	El presupuesto nunca altera el código
Dar por válida una comprobación tras cambiar los bytes	Solo certifica lo que comprobó

La lista de control de cada pedido

flowchart TD
    A["1. ¿Autoriza un cambio?"] --> B["2. ¿Qué existe ya?"]
    B --> C["3. ¿Queda una decisión real?"]
    C --> D["4. ¿Pequeña o grande?"]
    D --> E["5. ¿Documento antes de escribir?"]
    E --> F["6. ¿Hay motivo para delegar?"]
    F --> G["7. ¿Test-first aplica?"]
    G --> H["8. ¿Qué comparte este código?"]
    H --> I["9. ¿Qué punto de riesgo toca?"]
    I --> J["10. ¿Qué no se comprobó?"]

Adoptar estas ideas

Con Gentle AI

Las reglas se instalan por ti. El trabajo del equipo consiste en:

Decidir si odd/tasks/ se versiona.
Acordar el uso de RDD, recordando que es del usuario y es opt-out.
Definir la política de ramas y PR, porque la entrega sigue la política ordinaria de tu repositorio.
Establecer cómo se revisan los documentos de feature en los PR.

Sin Gentle AI

Las reglas son texto, y muchas se pueden trasladar a tu propio CLAUDE.md o AGENTS.md. Esta es una sugerencia del curso, no del proyecto. Por ejemplo:

## Tamaño de tarea
Una tarea es pequeña si se comprende, su riesgo está contenido y se podría retomar
desde el pedido original y `git diff`. Las tareas pequeñas se hacen inline, sin
documentos. Una tarea es grande solo si falla esa prueba, y no por su tamaño.

## Traspasos
Nunca parafrasees mi pedido a un subagente. Pásale una referencia al documento o el
pedido textual. Cita mis frases exactas, sin mejorarlas ni agregar requisitos.

## Cierre
Cierra con el resultado observado, lo fallido, lo omitido y lo pendiente, y una línea
`Risk: item N (motivo)` o `Risk: none`. No afirmes nada que no hayas observado.

Recuerda que trasladar el texto no da las garantías del binario: lo que review assess aplica por código sería una sugerencia para el modelo.

Medir antes de ajustar

Dado que el proyecto obtiene sus reglas de mediciones, conviene hacer lo mismo con un conjunto pequeño de tareas repetibles, registrando turnos, tiempo, costo y si fue aceptada en la primera ronda. Sin olvidar la lección del capítulo anterior: una sola corrida no mide varianza.

Proyecto de cierre

Aplica ODD a un cambio real, con o sin Gentle AI, y entrega:

La clasificación de tres pedidos, con justificación.
Un documento de feature con el orden fijo, con citas textuales.
Al menos un traspaso por referencia.
Una prueba RED observada y una PRESERVE.
Una comprobación diferencial sobre código compartido.
Commits por unidad de trabajo, con mensaje en formato de Conventional Commit.
Un cambio de requisito aplicado solo a lo afectado.
Una reanudación desde una sesión nueva.
Un cierre con línea Risk y lo no comprobado.

Examen final

¿Cuál es el orden correcto del protocolo?
- A. Explore, Authorize, Classify, Implement, Track, Resolve, Close
- B. Authorize, Classify, Explore, Track, Implement, Resolve, Close
- C. Authorize, Explore, Resolve uncertainty, Classify, Track, Implement, Close
- D. Classify, Authorize, Explore, Resolve, Track, Implement, Close
Pides “explícame este módulo y propón cómo mejorarlo”. ¿Qué puede hacer el agente?
- A. Crear un documento de feature con la propuesta
- B. Aplicar las mejoras de bajo riesgo
- C. Delegar la propuesta a un writer
- D. Inspeccionar, explicar y recomendar, sin escribir
Renombrar un campo interno en 40 archivos con un patrón claro y reanudable desde el diff es:
- A. Pequeña
- B. Grande por el número de archivos
- C. Automáticamente delegada
- D. Alto riesgo por su tamaño
¿Cuál de estos es un motivo válido para un writer?
- A. Dos unidades independientes de varios minutos, con superficies disjuntas, lanzadas juntas
- B. Una sola tarea de 900 líneas
- C. Usar un modelo más barato
- D. Separar las pruebas del código
¿Qué lee un worker del documento de feature?
- A. Solo su línea de tarea
- B. Desde el inicio hasta ## Log
- C. Solo ## Log
- D. Nada, recibe un resumen
Cambia un requisito en mitad de la feature. ¿Qué se hace?
- A. Regenerar el documento
- B. Abrir otro documento
- C. Agregar la entrada textual a ## Log, reescribir la S# y reabrir su tarea
- D. Terminar la feature antes de atenderlo
Tres reglas pedidas afectan a dos opciones existentes. ¿Cuántas pruebas nuevas pide la política?
- A. Tres
- B. Dos
- C. Tantas como permita el tiempo
- D. Tres RED y dos de preservación
Agregar un flag opcional nuevo sin romper nada existente:
- A. Es punto 3, siempre
- B. No es punto 3, salvo que cause una rotura no pedida en código compartido
- C. Siempre requiere verificador
- D. Es punto 5
La verificación de un cambio medium de 3000 líneas consiste en:
- A. Autoverificación del writer y la comprobación del parent
- B. Dos verificadores
- C. Una revisión RDD automática
- D. Una lectura estructural
Tras la recomprobación, un verificador encuentra un defecto nuevo. ¿Qué ocurre?
- A. Una segunda corrección automática
- B. Otro barrido completo
- C. Se ignora
- D. No da derecho a una segunda corrección
review assess devuelve review_due: false con under_budget. ¿Qué significa?
- A. La evaluación falló
- B. Hay que ejecutar la revisión de inmediato
- C. Es riesgo medium y queda pendiente en la porción
- D. El cambio es pasivo
Con RDD aprobado y los commits hechos, ¿quién decide el push?
- A. El binario
- B. El usuario, bajo la política ordinaria
- C. El verificador
- D. Se hace automáticamente
¿Qué hay que hacer después de gentle-ai upgrade?
- A. Nada
- B. Reinstalar el agente
- C. Borrar odd/tasks/
- D. Ejecutar gentle-ai sync
¿Cuál es el orden para retomar una feature?
- A. mem_context, mem_search, mem_get_observation, leer el archivo, conciliar
- B. Leer el archivo y continuar
- C. mem_search y usar la vista previa
- D. mem_save y luego mem_context
¿Qué queda sin demostrar con las pruebas de instrucciones?
- A. Que el texto llegue al agente
- B. Que el binario compile
- C. Que un modelo en vivo cumpla cada paso de forma autónoma
- D. Que los archivos existan
El usuario escribe “quizá te pare más tarde”. ¿Qué corresponde?
- A. Parar
- B. Pedir confirmación antes de seguir
- C. Cerrar con Needs your decision
- D. Dejar notas y commits separados, y continuar

Respuestas

C. Es el orden de routing.go.
D. Es solo lectura hasta que pidas implementar.
A. Los archivos no deciden el tamaño.
A. Es el motivo de paralelismo.
B. El verificador es quien lee todo.
C. Solo se rehace lo afectado.
D. Una RED por regla y una de preservación por opción.
B. Agregar está excluido del punto 3.
A. Sin punto nombrado no hay verificador. La comprobación del parent siempre está.
D. Una segunda corrección es solo para el mismo bloqueo.
C. Es el caso medium del código.
B. La revisión no autoriza la entrega.
D. sync refresca la guía instalada.
A. Es el orden del protocolo.
C. La documentación lo aclara.
D. Una redacción tentativa no es una parada.

Siguientes pasos

Lee el bloque ## Implementation Routing completo en tu agente o en routing.go.
Lee la crónica de RDD completa.
Explora los documentos reales de odd/tasks/.
Continúa con el curso de Engram o de Harness Engineering.

Lista de control final

Puedo clasificar cualquier pedido con el protocolo.
Escribo documentos de feature con citas textuales.
Delego solo con un motivo que puedo nombrar.
Mis cierres dicen qué no se comprobó.
Sé qué decide el binario, qué decide el modelo y qué decido yo.

Fuentes

README.md, docs/usage.md, docs/trigger-rules.md, docs/intended-usage.md, internal/components/agentguidance/routing.go, internal/assets/skills/_shared/odd-orchestrator-sections.md, internal/assets/skills/chained-pr/SKILL.md, docs/architecture/the-organic-rdd-story.md.