¿Usar un modelo de IA distinto para revisar código mejora los resultados?

En un estudio controlado de 116 tareas reportado por Adventure Wave Labs, los cambios revisados por un modelo de otra familia pasaron 89.7% de las pruebas de aceptación contra 71.6% sin esa revisión — 18 puntos más — mientras la auto-revisión de la misma familia apenas ayudó. La dirección importa: debe revisar el modelo analista más fuerte, nunca un espejo del constructor.

~/turbo-flow — research/cross-model-review estudio · n=116

Revisión entre modelos: el constructor nunca debe ser su propio revisor

Q: ¿Qué es la revisión de código entre modelos?

Es la práctica de que un modelo de una familia distinta a la que escribió el cambio revise ese cambio — por ejemplo, código construido por ZCode (GLM) y revisado por Claude Code. El revisor inspecciona el diff en solo-lectura y debe devolver un veredicto interpretable APPROVED o REVISE. Existe porque un modelo que revisa la salida de su propia familia comparte los sesgos de falla de esa familia.

¿Qué es la revisión de código entre modelos? Es que un modelo de una familia distinta a la del constructor revise cada cambio — código construido por ZCode (GLM), revisado por Claude Code, por ejemplo. El revisor ve el diff en solo-lectura y debe devolver un veredicto interpretable APPROVED o REVISE. Es el mecanismo central de la compuerta de rig-lite y la razón de ser de Turbo Flow como capa de reglas.

Publicado 7 oct 2026 · Actualizado 9 oct 2026

71.6%

tasa de aprobación sin revisión entre familias — estudio controlado de 116 tareas, Adventure Wave Labs

89.7%

tasa con un revisor de otra familia de modelos (+18.1 puntos, mismo estudio)

≈ plano

la auto-revisión de la misma familia apenas ayudó

Por qué la revisión de la misma familia se queda corta

Un modelo que revisa la salida de su propia familia tiende a compartir sus sesgos de falla: los mismos puntos ciegos, los mismos errores preferidos, la misma confianza en los mismos supuestos incorrectos. La auto-revisión dentro de una familia casi siempre re-deriva el razonamiento del constructor en vez de auditarlo. El segundo hallazgo del estudio afina la regla: la dirección importa — debe revisar el modelo analista más fuerte, nunca un espejo del constructor.

Cómo la compuerta la aplica

# primero los checks deterministas — son gratis
lint · tests · higiene del diff · escaneo de secretos
        ↓
# luego el revisor de otra familia, solo-lectura, diff con nonce
revisor ≠ familia del constructor (detectado; la misma familia se rechaza)
el veredicto debe ser APPROVED o REVISE interpretable en la última línea
        ↓
# la ambigüedad es REVISE — falla cerrada, y la compuerta nunca fusiona
un humano mantiene el botón de fusión

El nonce impide que un diff inyecte su propio APPROVED. La salida del revisor se redacta de secretos. Un revisor silencioso o colgado es REVISE, no aprobación. Cada veredicto queda en un log JSONL local — lo que hace que los números de uso sean auditable después.

Los recibos públicos

La compuerta se revisó a sí misma hasta nacer: escrita por una familia, recibió REVISE diecisiete veces de otra antes de su primer APPROVED — y los hallazgos fueron exactamente la clase que existe para atrapar: un agujero de inyección de prompt, un camino que falla abierto, un bug de quoting.
Una semana de producción, contada desde el log de la compuerta: 868 veredictos sobre 141 PR fusionados — y el 79% fueron REVISE. La compuerta no es ceremonial; rechaza la mayoría de lo que ve.
Fallar cerrado es verificable: self-test.sh viene con el kit — cientos de checks en verde que prueban que los modos de falla fallan cerrados.

Estado de publicación

Transparencia honesta: el resultado principal es el estudio controlado reportado por Adventure Wave Labs. El dataset a nivel de tarea — prompts, rúbrica de calificación, versiones y configuraciones de los modelos — está en preparación para publicación pública; hasta que llegue, trata el 71.6% → 89.7% como el resultado reportado del laboratorio, y juzga el mecanismo por los recibos públicos: los conteos del log y la suite de self-tests que puedes ejecutar tú mismo en diez minutos.

Ejecútalo tú

# cualquier repo, cualquier CLI constructor:
bash /path/to/turbo-flow/rig-lite/init-repo.sh
bash /path/to/turbo-flow/rig-lite/self-test.sh
/path/to/turbo-flow/rig-lite/gate.sh --pr 1 --builder zcode

La historia amplia — la orquestación no podía comprar confianza, la gobernanza sí — está en por qué Turbo Flow se convirtió en Turbo Rig. Versión inglesa: /cross-model-code-review/.