Medí dev-orchestra: el tiempo por petición y los hallazgos según el número de revisores

Introducción

La vez anterior dividí un plan en unidades de trabajo de dev-orchestra y las implementé en paralelo.

dev-orchestra es un plugin para Claude Code / Codex / Antigravity que, a partir de una petición de una sola frase, se encarga del diseño, la implementación, las pruebas, las revisiones de varias IA y las correcciones.

En la serie dije que “cuesta más tiempo y más tokens”, pero nunca di cifras medidas. Así que esta vez medí dos cosas:

• Cuánto tarda una petición
• Cómo cambian el número de hallazgos, y cuántos de ellos pude aceptar, con 1, 2 y 4 revisores

Lo aviso de entrada: la muestra es muy pequeña (una petición de principio a fin y dos revisiones por cada número de revisores), sobre un único paquete pequeño de Python. Léelo como un registro para hacerse una idea de las tendencias.

dev-orchestra es de código abierto y está en GitHub (licencia MIT). Si te parece útil, una estrella me haría mucha ilusión.

→ github.com/istb16/dev-orchestra

Condiciones de la medición

Elemento	Detalles
dev-orchestra	1.2.1, preset standard, optimization.level con el valor por defecto balanced
Anfitrión	Claude Code 2.1.309 (modelo: Opus 5.5). Envié la petición con claude -p y di la aprobación del plan en un segundo claude -p --resume
Modelos por rol	architect: Claude Fable; implementer y review_fixer: Claude Opus
Revisores	claude-general (Opus), codex-general (Codex CLI 0.163.0, gpt-6.1-sol), claude-security (Sonnet), claude-test (Sonnet)
Objeto	textkit, un pequeño paquete de Python que hice para la prueba (una función y tres pruebas)
Entorno	Windows 11, Python 3.14.7. La configuración estaba en una carpeta aparte (DEV_ORCHESTRA_HOME)

La petición, que escribí en japonés, dice:

Añade truncate(text, width, suffix="…") a textkit. Trunca por ancho de visualización, contando los caracteres de ancho completo (East Asian Width W o F) como 2 y todos los demás como 1. Al truncar, el resultado, sufijo incluido, debe caber en width. Actualiza también el README y las pruebas.

El tiempo de una petición

Desde la petición hasta el informe final pasaron 6 minutos y 12 segundos, sin contar el tiempo que el plan esperó mi aprobación.

Tramo	Tiempo
Petición → plan listo y aprobación solicitada	2 min 19 s
Aprobación → informe final	3 min 53 s
Total	6 min 12 s

El registro de dev-orchestra (state.json) tenía el desglose por etapa. Cada ejecución de un rol tardó:

Etapa	Rol	Tiempo
Diseño	architect (Fable)	75 s
Implementación	implementer (Opus)	45 s
Revisión	claude-general (Opus), un solo revisor	19 s
Corrección (1.ª)	review_fixer (Opus)	27 s
Corrección (2.ª)	review_fixer (Opus)	45 s

Las cinco ejecuciones suman 3 min 31 s. Los ~2 min 40 s restantes los usó el Claude Code anfitrión (el orquestador) para elegir etapas, ejecutar las pruebas, clasificar los hallazgos y escribir el informe.

La revisión del diseño se saltó automáticamente, porque el cambio era pequeño y no tocaba rutas de alto riesgo.

Un revisor, no cuatro

standard tiene cuatro revisores, pero en esta petición el panel se redujo a uno. El registro de la revisión dice:

note: low-risk change (4 file(s), 76 line(s)): 1 reviewer instead of the full panel (claude-general). Cross-model disagreement is what a second reviewer buys; raise optimization.level or the low_risk thresholds to keep it.

Con balanced, un cambio de hasta 5 archivos y 150 líneas que no toca ninguna ruta de alto riesgo recibe un solo revisor (optimization.low_risk_max_files y optimization.low_risk_max_lines). Por eso las peticiones pequeñas salen ligeras. Si quieres los ojos de otro proveedor incluso en cambios pequeños, sube optimization.level o baja esos dos valores.

Por qué la corrección se ejecutó dos veces

La revisión dio dos hallazgos; el orquestador aceptó uno y rechazó otro. El rechazado decía que los caracteres combinables y los de ancho cero deberían tener ancho 0, lo que contradice el “todos los demás como 1” de la petición.

El aceptado era sobre las pruebas, pero también proponía añadir pruebas para los caracteres combinables. El orquestador anotó “aceptado con un alcance más reducido”, pero las instrucciones que se pasaron al corrector (fix-brief.md) llevaban la propuesta del revisor tal cual, así que la primera corrección añadió justo las pruebas que se habían rechazado. El orquestador se dio cuenta y volvió a ejecutar al corrector con unas instrucciones que dejaban claro el alcance.

En la 1.2.1, las notas de la clasificación no llegan a las instrucciones del corrector. Cuando aceptes un hallazgo solo en parte, revisa tú también el diff final.

Tokens y coste

tokens show muestra las cinco ejecuciones que hizo dev-orchestra:

  stage              meas.     input    output     total    billed      cost   tools  tool out
  architect            1/1        34     5,890         -    14,703   $0.4737       5     2,368
  implementer          1/1        14     4,103         -    27,614   $0.3380      14    10,107
  review               1/1         2     1,517         -     7,364   $0.0778       0         0
  review_fixer         2/2        26     5,495         -    43,959   $0.5371      14     6,369
  ALL                  5/5        76    17,005         -    93,640   $1.4265      33    18,844

Aparte, el Claude Code anfitrión informó de 1,74 $ por sus dos llamadas a claude -p, lo que da unos 3,2 $ en total. Ambas cantidades son equivalentes al precio de la API que informan las CLI; con una suscripción indican cuánto de tu cuota se consumió, no lo que se te cobra.

Número de revisores frente a hallazgos y hallazgos aceptados

Después tomé la revisión por separado y fui cambiando el panel. Cogí el diff de la ejecución anterior en el momento en que terminó la implementación (4 archivos, 75 líneas añadidas y 1 eliminada), lo apliqué cada vez a un repositorio limpio e hice que 1, 2 o 4 revisores revisaran el mismo diff. Dos ejecuciones por cada número, seis en total.

dev-orchestra review snapshot
dev-orchestra review run --only claude-general codex-general --json
dev-orchestra review show --json

Nombrar a los revisores con --only anula la reducción a un solo revisor descrita arriba. Los paneles fueron:

Número	Revisores
1	claude-general
2	claude-general, codex-general
4	claude-general, codex-general, claude-security, claude-test

Cómo los clasifiqué

Clasifiqué los hallazgos con el mismo criterio que usó el orquestador en la ejecución de principio a fin:

• Aceptado: algo que de verdad falta dentro de la petición y del plan aprobado. Si solo una parte estaba dentro del alcance, aceptado con un alcance más reducido
• Rechazado: lo que contradice el “todos los demás como 1” de la petición (dar ancho 0 a los caracteres combinables o de ancho cero, no cortar nunca dentro de un grafema, etc.) o lo que no hace falta corregir
• Duplicado: lo que tiene el mismo punto principal que otro hallazgo aceptado

dev-orchestra fusiona los duplicados de forma conservadora; en estas seis ejecuciones no fusionó ninguno automáticamente. Sí lista las parejas de “posibles duplicados”, que usé al clasificar.

Resultados

Revisores	Ejecución	Hallazgos	Aceptados	Rechazados	Duplicados	Tiempo	Tokens
1	1	2	1	1	0	25 s	6.992
1	2	2	1	1	0	23 s	6.751
2	1	4	2	2	0	53 s	16.529
2	2	4	1	3	0	48 s	14.837
4	1	8	4	3	1	25 s	27.795
4	2	9	4	4	1	38 s	27.964

El tiempo va del inicio al final de review run; los tokens son la suma de los tokens facturados (billed) de los revisores (incluido Codex).

Lo que vi

El número de hallazgos creció más o menos en proporción al número de revisores: 2 con uno, 4 con dos, 8–9 con cuatro.

Los hallazgos aceptados también aumentaron, pero los que se sumaron eran sobre las pruebas. Casi todo lo que añadieron los cuatro revisores vino de claude-test: “no hay prueba para cuando el ancho del sufijo es exactamente igual a width (truncate("abc", 1) da "…")”, “nada comprueba que el sufijo por defecto … cuente como ancho 1”, etc. Todos eran huecos reales en las pruebas. En cambio, con ningún número de revisores salió un hallazgo que fuera un fallo del código.

El hallazgo más frecuente contradecía la petición. “Cuenta los caracteres combinables y los de ancho cero como ancho 1” salió en las seis ejecuciones. Claude (claude-general) y Codex (codex-general) lo dijeron por separado, y con cuatro revisores claude-test planteó lo mismo como una prueba que faltaba. En general es un punto válido, pero la petición había fijado “todos los demás como 1”, así que lo rechacé. El mismo hallazgo salió también en la ejecución de principio a fin. Algo que decidiste a propósito puede parecer un fallo a los revisores.

Codex dio exactamente un hallazgo cada vez, y siempre era este punto del cálculo del ancho. En este diff, añadir otro proveedor no destapó nada nuevo. La ejecución en la que dos revisores dieron un hallazgo aceptado de más (la 1.ª) se debió a Claude: “el docstring no coincide con el comportamiento”.

El tiempo de la revisión lo marca el revisor más lento. Los revisores se ejecutan en paralelo, así que cuatro no tardan cuatro veces más. Con dos revisores se tardó más que con cuatro porque en esas ejecuciones Codex o Claude tardó más de 45 segundos. Los tokens, en cambio, crecen con el número de revisores (unos 7.000 con uno, unos 28.000 con cuatro).

claude-security no dio ningún hallazgo en ninguna de las dos ejecuciones, lo esperable en un diff que no maneja entradas externas ni secretos.

Los límites de estas cifras

• Un solo objeto y una sola petición. El diff era pequeño (76 líneas) y la especificación estaba clara. Con cambios más grandes o peticiones más vagas, los resultados probablemente serán otros
• Solo dos ejecuciones por número de revisores. Incluso con el mismo número, la cantidad y el contenido de los hallazgos variaron un poco entre ejecuciones
• Las decisiones de aceptar o rechazar las tomé yo. El criterio está escrito arriba, pero otra persona podría clasificarlos de otra forma
• No se dio el caso en el que el revisor de otro proveedor (Codex) encuentra un fallo real que Claude pasó por alto. Eso no demuestra que “no sirva”, solo que “esta vez no pude medirlo”

Las desventajas

• Cuesta tiempo y tokens. Esta petición tardó unos 6 minutos sin contar mi aprobación, y unos 3,2 $ a precios de la API. No lo comparé con pedírselo directamente a una sola IA, pero llamó a una IA cinco veces, y ese tiempo y esos tokens se acumulan
• Más revisores significa más hallazgos que rechazar. Con cuatro, 4–5 de los 8–9 hallazgos fueron rechazados o duplicados. El orquestador los clasifica, pero la comprobación final te toca a ti
• Tu código se envía al proveedor de cada revisor. Con dos o más revisores, el diff fue tanto a Anthropic como a OpenAI. Los revisores también pueden leer archivos alrededor del diff, así que puede que no se envíe solo el diff. Cómo tratar el código que no puede salir de tu máquina lo conté en el artículo de presentación

Resumen

• Una petición para añadir una pequeña funcionalidad con dev-orchestra 1.2.1 tardó 6 min 12 s sin contar la aprobación, unos 3,2 $ a precios de la API
• 3 min 31 s de eso fueron las ejecuciones de los roles; el resto, las decisiones, las pruebas y el informe del orquestador
• En cambios pequeños, balanced reduce el panel de cuatro revisores a uno
• Sobre el mismo diff, los hallazgos fueron 2 con un revisor, 4 con dos y 8–9 con cuatro; los aceptados, 1, 1–2 y 4
• Los hallazgos aceptados de más que aportaron más revisores eran sobre las pruebas; con ningún número salió un hallazgo de fallo del código
• El hallazgo más frecuente contradecía una especificación fijada en la petición; a los revisores les parece un fallo
• Una medición pequeña sobre un solo objeto: un registro para hacerse una idea de las tendencias

La próxima vez (publicación prevista el 7 de noviembre de 2026) pruebo la función de la 1.3.0 que revisa otra vez el cambio completo al final.

GitHub: istb16/dev-orchestra (una estrella me animaría mucho)

Todas las entregas de esta serie están en la lista de entregas de «dev-orchestra».