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

Evidencia y lecciones

5 de noviembre de 2026 Por: Artiko

oddbenchmarksevidencialeccionespruebas

Evidencia y lecciones

Objetivos

Leer los datos publicados por el proyecto con sus limitaciones.
Entender qué prueban y qué no prueban las pruebas de agentes.
Extraer lecciones aplicables de la historia del proyecto.
Conocer las diferencias actuales en la documentación.

Las mediciones publicadas

El README afirma que las reglas de enrutamiento surgieron de benchmarks. Esta es su tabla:

Escenario	Antes	Después
Bug de 3 líneas en una función	335 s · 56 turnos · $0.339	77 s · 10 turnos · $0.105, inline y sin subagentes
Bug en lógica compartida	479 s · $0.361	276 s · $0.207, con un explorador
Migración de datos, alto riesgo	559 s · $0.403 · requirió una ronda de corrección	539 s · $0.555 · aceptada en la primera ronda, con un verificador independiente
Especificación de 73 líneas y 26 comprobaciones ocultas	Traspasos parafraseados: 13 fallan, y aún 23/26 tras dos rondas	Especificación por referencia

xychart-beta
    title "Tiempo por escenario según el README (segundos, n=1 por celda)"
    x-axis ["Bug de 3 líneas", "Lógica compartida", "Migración"]
    y-axis "Segundos" 0 --> 600
    bar [335, 479, 559]
    bar [77, 276, 539]

En el gráfico, la barra clara es el tiempo de antes y la barra oscura superpuesta es el de después. La cuarta fila de la tabla no aparece porque no publica tiempos.

Cómo leer estos datos

El propio README enumera las condiciones, que son esenciales para interpretarlos:

Condición	Consecuencia al leerlos
Cada celda es una sola corrida, n=1	Sin varianza medida. Una diferencia concreta puede no repetirse
Corridas de Gentle Shell en un benchmark local	No se miden todos los runtimes ni se generalizan a otros
Costo equivalente en API	No es lo que paga quien tiene una suscripción
Suites de aceptación ocultas	El agente no ve qué se le evaluará
Antes y después son del mismo proyecto	No es una comparación contra otros métodos

La fila de la migración merece atención: el “después” cuesta más ($0.555 frente a $0.403) y tarda casi lo mismo. Lo que mejora es la aceptación en la primera ronda. Por eso el texto instalado dice que el verificador corre lo menos posible, y solo cuando hay un punto de riesgo.

La comparación con Codex CLI

El README también informa una comparación con el mismo modelo en Codex CLI, con revisión ciega de cada solución:

Gentle Shell fue aceptado en la primera ronda en cada celda.
Se ubicó más alto en la tarea mediana, en las 3 de 3 corridas, y en la grande.
Quedó cerca en la pequeña.
La tarea grande tardó unas tres veces más, de 17.5 a 17.9 minutos frente a 6.1. El README lo registra como trabajo abierto.

Las fuentes citadas son PR e issues del repositorio gentle-shell. Es una evaluación publicada por el propio proyecto, y este curso no la ha reproducido.

Qué prueban las pruebas

docs/testing-agents-deterministically.md describe el enfoque, y su parte más útil es una separación honesta.

La prueba TestRealAgentOrganicJourneys ejecuta un agente real de OpenCode con el binario real, y lo único simulado es el razonamiento del modelo. Un proveedor falso escribe llamadas a herramientas predeterminadas.

Prueba	No prueba
Dado un comportamiento conocido del agente, la CLI clasifica la ruta correctamente	Que un modelo en vivo produzca esas mismas llamadas con el prompt instalado
No se crea estado de flujos retirados cuando no debe
Se congela el candidato y corre la verificación aplicable
El interruptor se detiene en la frontera de entrega

El salto al modelo en vivo se califica de no determinista por naturaleza y queda fuera de una puerta de merge. Lo cubren el uso real y los fixtures de paridad entre adaptadores.

Medir fricción, no velocidad

El directorio bench/ mide cuánto te quedas atascado y sobre todo cómo, en vez de medir velocidad. Se ejecuta contra tu propio binario:

cd bench && go run . run --binary $(command -v gentle-ai)

Categoría	Qué ocurre
In band	Te detiene y te dice qué ejecutar
Out of band	Te detiene y no te dice nada
Dead end	Te detiene y no hay nada que puedas hacer

La crónica informa que la primera medición dio seis bloqueos fuera de banda, y la última sobre 36 recorridos dio cero callejones sin salida, quince en banda, tres fuera de banda y dos correctos por diseño. Este benchmark se refiere sobre todo a RDD, pero el razonamiento se aplica a cualquier arnés.

Lecciones de la crónica

docs/architecture/the-organic-rdd-story.md relata en primera persona cómo se construyó RDD. Estas son las lecciones que el mantenedor saca, traducidas y resumidas:

Lección	Qué ocurrió
Las decisiones humanas no sobreviven sin algo que las haga cumplir	Un agente dedujo requisitos empresariales de una auditoría y construyó todo eso. Costó tres reinicios mensuales de cuota
Una prueba que verifica que algo se emitió no verifica que sea usable	Un mensaje nombraba un comando con pruebas en verde. Nadie había ejecutado ese comando, y no funcionaba
Una guarda que nadie llama no es una guarda	El interruptor tenía una guarda escrita y comentada que no estaba conectada. Se aprobó una revisión con RDD apagado
Primero apunta el instrumento hacia ti	El benchmark contó el interruptor funcionando como fricción, y midió un binario que no se había compilado
El código muerto documentado es una mentira	La documentación decía que se instalaban dependencias, y nada llamaba a esa función
El exceso de ingeniería cuesta más de quitar que un bug	Una arquitectura no pedida, bien hecha y coherente, se defiende sola
La comunidad encuentra lo que las auditorías no	Los hallazgos más valiosos vinieron de personas usando la herramienta

Los errores que admite

También lista errores propios, y cada uno se convirtió en una regla:

Escribió pasos de una guía sin ejecutarlos. De ahí salió: antes de nombrar una continuación, se ejecuta.
Convirtió un hallazgo en un parche de documentación, lo que destruyó la medición y ocultó el defecto.
Hizo staging de un archivo sin leer su diff mientras un agente escribía en él.
Persiguió un defecto que era su propio error de medición, al escribir la salida de un comando en el repositorio que estaba midiendo.

Una señal de alerta útil

Dos veces, una medición dio números idénticos tras cambios reales: el build había fallado en silencio y se midió el binario anterior. Su observación: los números que no se mueven después de cambios reales son un síntoma, no un consuelo.

Diferencias detectadas en la documentación

Al revisar main en el commit f1c35b4 se encontraron estas diferencias. Son normales en un proyecto de este ritmo, y la nota inicial de sus documentos advierte que siguen a main.

Tema	Una fuente dice	Otra fuente dice	Este curso sigue
Motivo de revisión debida	`docs/usage.md`: `high_risk` o `slice_budget_reached`	`review_assess.go` y `review-integration.md`: solo `high_risk`	El código
`under_budget`	`routing.go`: pendiente hasta alcanzar el presupuesto	`review_assess.go`: `medium` nunca queda debido por tamaño	El código, avisando del texto
Strict TDD	`docs/agents.md`: modo configurable	Notas de `v4.0.0`, `usage.md`, `sync.go`: retirado	Retirado
Copia para el diferencial	`docs/usage.md`: `git stash` o copia	`routing.go`: copia en `mktemp -d`	`routing.go`
Selección de lentes	Tarea B1 prevé rechazar START sin lentes	`review-integration.md`: valores por defecto. B1 sin marcar	Valores por defecto
Preflight de revisión	`organic-rdd.md` y `review-integration.md`: se entra tras cada candidato	Notas de `v4.1.0`, `review_assess.go`: automático solo con `high`	`review_due`
Versión en instalación	`quickstart.md`: `v4.0.0`, `README`: `v4.1.1`	Releases: `v4.3.1`	Consultar releases
Delegación por archivos	Tareas antiguas: 4 archivos o 2 no triviales	`routing.go`: motivo con nombre	`routing.go`

Si quieres contribuir, algunas de estas diferencias podrían servir de punto de partida para un issue en el repositorio. El proyecto exige un issue aprobado antes de un PR, según su plantilla.

Limitaciones de este curso

Se basa en la lectura del código, la documentación y los documentos de tareas en una fecha concreta.
No se ejecutó Gentle AI para este curso ni se reprodujeron los benchmarks.
No se revisó el repositorio gentle-shell, salvo por sus referencias desde gentle-ai.
Las secciones marcadas como síntesis o lectura del curso son interpretación, no afirmaciones del proyecto.

Actividad

Elige una afirmación del README y comprueba su fuente: localiza el PR o el issue que cita, revisa cuántas corridas hubo y qué condiciones tuvo. Escribe en una línea qué concluirías y qué no.

Autoevaluación

¿Cuántas corridas tiene cada celda de la tabla del README?
- A. Una
- B. Tres
- C. Diez
- D. No se indica
En el escenario de migración, ¿qué mejoró con el verificador?
- A. Costo
- B. Tiempo, a menos de la mitad
- C. Número de archivos
- D. Aceptación en la primera ronda
¿Qué no prueba la suite de runtime orgánico?
- A. Que la CLI clasifique la ruta
- B. Que un modelo en vivo genere las mismas llamadas con el prompt instalado
- C. Que se congele el candidato
- D. Que el interruptor detenga la entrega
¿Qué mide bench/?
- A. Velocidad por proveedor
- B. Costo por token
- C. Cuánto y cómo te quedas atascado
- D. Calidad del código generado

Respuestas

A. “Each cell is a single run (n=1).”
D. El costo subió y el tiempo fue casi igual.
B. Se describe como no determinista por naturaleza.
C. La crónica aclara que no mide velocidad, porque esta depende del proveedor y del día.

Lista de control

Sé qué condiciones limitan los datos publicados.
Distingo lo que prueban las pruebas de agentes de lo que no.
Puedo aplicar al menos una lección a mi propio arnés.
Consulto el código cuando la documentación se contradice.

Fuentes

README.md, docs/testing-agents-deterministically.md, docs/architecture/the-organic-rdd-story.md, docs/usage.md, docs/agents.md, docs/quickstart.md, docs/review-integration.md, docs/architecture/organic-rdd.md, internal/cli/review_assess.go, internal/components/agentguidance/routing.go, odd/tasks/verify-always-rdd-high.md.