Open Code Review: el revisor de código IA de Alibaba

Alibaba tenía una herramienta interna de revisión de código con IA. La usaban decenas de miles de programadores. Llevaba dos años detectando millones de defectos antes de que llegaran a producción.

En mayo de 2026 la publicaron entera en GitHub con licencia Apache-2.0.

Se llama Open Code Review, su comando es ocr y en cuatro meses ha pasado de cero a más de 26.000 estrellas (repositorio alibaba/open-code-review, consultado en septiembre de 2026). No es un wrapper de tres líneas alrededor de una llamada a la API. Es un binario en Go con una arquitectura que se parece más a un compilador que a un prompt.

Esto es lo que vas a encontrar aquí:

• Qué es exactamente y por qué su arquitectura híbrida no se parece a pedirle a Claude Code que te revise el diff
• Cómo se instala, se configura y se ejecuta en un repositorio real, con los comandos que vas a usar de verdad
• Qué te devuelve: estructura del resultado, niveles de severidad, categorías y formatos de salida
• Cómo enchufarlo a Claude Code, Codex, Cursor u OpenCode, y qué es el modo delegación
• Qué dice su benchmark, qué se calla, y en qué casos esta herramienta no es para ti

¿Qué es Open Code Review y qué problema resuelve? ¶

Open Code Review es una herramienta de línea de comandos que lee los diffs de Git de tu repositorio, se los pasa a un modelo de lenguaje a través de un agente con herramientas y te devuelve comentarios de revisión con precisión de línea.

Hasta aquí, nada que no hayas visto. La diferencia está en el origen y en el diseño.

El origen: no nació como proyecto open source buscando estrellas. Nació como el asistente oficial de revisión de código dentro de Alibaba Group. La documentación del repositorio lo cuenta sin adornos: dos años de uso interno, decenas de miles de programadores, millones de defectos identificados. Solo después de esa validación a escala lo sacaron a la comunidad.

El diseño es lo interesante, y lo vemos en la siguiente sección.

Dos datos para situar el proyecto. El paquete @alibaba-group/open-code-review se publicó por primera vez en npm el 21 de mayo de 2026 y acumula 114 versiones, la última de ellas la 1.12.1 del 14 de septiembre (registro de npm, consultado el 15 de septiembre de 2026). Eso es casi una versión al día. El proyecto luce además la insignia Gold de OpenSSF Best Practices, que no es un adorno: exige políticas de seguridad, firma de releases y pruebas automatizadas documentadas.

🔑 El punto clave: Open Code Review no compite con tu agente de código. Compite con la casilla que marcas en la pull request cuando nadie ha mirado el diff.

¿Por qué un agente genérico revisa mal el código? ¶

Porque la revisión de código tiene pasos que no pueden salir mal, y un agente puramente conversacional no te garantiza ninguno.

Si ya has intentado montar revisiones con Claude Code y una skill, reconocerás los tres problemas que la propia documentación del proyecto pone sobre la mesa:

Cobertura incompleta. En changesets grandes el agente recorta por lo sano. Revisa algunos archivos, se salta otros y te presenta el resultado con la misma confianza en ambos casos. Tú no sabes cuáles se ha saltado.

Deriva de posición. El problema que reporta es real, pero el número de línea no cuadra. O el archivo no es ese. Un comentario que apunta al sitio equivocado obliga al humano a buscar el sitio correcto, y ahí se va la ventaja.

Calidad inestable. Las skills escritas en lenguaje natural son difíciles de depurar. Cambias tres palabras del prompt y la calidad de la revisión se mueve sin que sepas por qué.

La causa de fondo, según el equipo de Alibaba, es que una arquitectura dirigida solo por lenguaje no tiene restricciones duras sobre el proceso. El modelo decide qué revisar, cómo agruparlo y dónde colocar el comentario. Tres decisiones que no deberían depender de la temperatura de un sampler.

Si este diagnóstico te suena, te interesa el enfoque más amplio sobre cómo revisar el código que genera la IA antes de meterte en herramientas concretas.

¿Qué hace distinta la arquitectura híbrida de OCR? ¶

Separa el problema en dos mitades y le da cada mitad a quien la hace mejor: la ingeniería determinista para lo que no puede fallar, el agente para lo que requiere criterio.

La capa determinista se encarga de cuatro cosas, y ninguna de ellas pasa por el modelo:

El ejemplo que da la documentación para la agrupación: message_en.properties y message_zh.properties van juntos al mismo grupo. Un agente genérico los trataría como dos archivos sin relación y perdería la única cosa que importa ahí, que es si las claves coinciden.

Cada grupo se ejecuta como un subagente aislado. Eso convierte un changeset de 200 archivos en un problema de divide y vencerás, con concurrencia natural, en lugar de una ventana de contexto reventada.

La capa del agente se reserva para lo que sí necesita inteligencia: decisiones dinámicas y recuperación de contexto. Puede leer el archivo entero, buscar en el código, mirar otros archivos modificados. El toolset no es genérico: lo destilaron analizando trazas reales de llamadas a herramientas en producción, mirando frecuencias de uso y tasas de repetición por herramienta.

💡 Si solo te llevas una idea de este artículo: lo que hace bueno a un revisor automático no es el modelo, es la ingeniería que rodea al modelo.

Curso gratis · paso a paso

Sacar decisiones del prompt no solo sirve para revisar código

El mismo principio que usa Alibaba en su revisor lo aplicas tú con Spec Driven Development: en este curso recorres el ciclo completo de OpenSpec sobre un proyecto real, de la propuesta al archivado, en modo asistido.

Entra en el curso gratis →

¿Cómo se instala y se configura? ¶

Con npm y dos comandos interactivos. Lo único que necesitas tener antes es Git en versión 2.41 o superior, porque la herramienta se apoya en Git para generar diffs, buscar en el código y operar sobre el repositorio.

npm install -g @alibaba-group/open-code-review

Después de eso, ocr está disponible en cualquier directorio. Hay más vías de instalación (script, binario de la GitHub Release, compilar desde el código fuente) si no quieres npm global.

Ahora el modelo:

ocr config provider    # elige proveedor y mete la API key
ocr config model       # elige el modelo del proveedor activo
ocr llm test           # comprueba que la conexión responde

La interfaz interactiva te guía por la selección de proveedor, la entrada de la clave y la configuración del modelo, y prueba la conectividad al terminar. Si prefieres dejarlo escrito sin pasar por el menú, también se puede:

ocr config set llm.url https://api.anthropic.com/v1/messages
ocr config set llm.auth_token <tu-api-key>
ocr config set llm.model claude-opus-4-6
ocr config set llm.use_anthropic true

Los protocolos soportados son Anthropic, OpenAI Chat Completions, OpenAI Responses y AWS Bedrock, además de proveedores personalizados. En la práctica, si tu endpoint habla alguno de esos cuatro dialectos, entra.

Un detalle que agradecerás si no trabajas en inglés: la clave language de la configuración controla el idioma de los comentarios de revisión. Por defecto es inglés y acepta cualquier nombre de idioma. Pon Español y los hallazgos te llegan en español.

¿Qué comandos necesitas de verdad? ¶

Cuatro. El resto son matices.

cd tu-proyecto

# Modo workspace: revisa staged, unstaged y archivos sin trackear
ocr review

# Rango de ramas: revisa lo que ha cambiado la rama desde que se separó de main
ocr review --from main --to feature-branch

# Un commit concreto contra su padre
ocr review --commit abc123

# Escaneo de archivos completos, sin necesidad de diff
ocr scan
ocr scan --path internal/agent

El primero es el que vas a ejecutar noventa veces de cada cien: antes de escribir el commit, sobre lo que tienes en el directorio de trabajo. Ojo con una cosa, porque muerde: en modo workspace se incluyen los archivos sin trackear. Si tienes un notas.md y un dump.sql tirados en la raíz, van a la revisión. Prepara el git add selectivo o usa --exclude.

El segundo es el que usarás en integración continua. Y es importante entender que --from main --to feature-branch no compara las puntas de las dos ramas: usa el merge-base, es decir, revisa lo que ha aportado tu rama desde que se bifurcó. Que es exactamente lo que quieres en una pull request.

ocr scan es la pieza que más me sorprendió. No necesita historia de Git ni diff: revisa archivos completos. Sirve para auditar un repositorio que acabas de heredar, para pasar el peine por un directorio concreto, o para esa carpeta que nadie ha tocado desde 2019 y por tanto nunca aparece en ningún diff.

Y luego está el cuarto, que tiene sección propia más abajo:

ocr delegate preview
ocr delegate rule src/main.go src/handler.go

Antes de ejecutar nada caro, dos banderas que valen su peso:

• --preview (o -p) te dice qué archivos entrarían en la revisión sin gastar una sola llamada al modelo
• --background "contexto de negocio" (o -b) le da al revisor la intención del cambio, y sube bastante la calidad de los hallazgos

La segunda cambia bastante el resultado. Un revisor que sabe que estás añadiendo rate limiting sin tocar la API pública revisa distinto que uno que solo ve líneas cambiadas. Hay también --background-file <ruta> para pasarle un Markdown entero cuando el contexto no cabe en una línea de comandos.

¿Qué resultado te da exactamente una revisión? ¶

Comentarios estructurados, uno por hallazgo, con severidad, categoría, rango de líneas y código de corrección sugerido.

Cada comentario del resultado trae estos campos:

Esos ocho campos son la razón de ser de la herramienta. Un agente genérico te devuelve prosa que tú tienes que interpretar. Esto te devuelve una estructura que puedes filtrar, ordenar, contar y publicar en la pull request de forma automática.

Sobre el formato hay tres opciones, y la tercera es la que abre puertas:

ocr review --format text            # por defecto, para leer en terminal
ocr review --format json --output result.json
ocr review --format sarif           # para GitHub Code Scanning y similares

SARIF significa que los hallazgos entran en la pestaña de Security de GitHub como cualquier otro escáner. No es un informe que alguien tiene que abrir: es una anotación en el código con su ciclo de vida.

Fíjate en el detalle del start_line: 0. La herramienta reconoce cuándo no ha sabido colocar el comentario en vez de inventarse una línea plausible, que es justo el problema de la deriva de posición del que hablábamos antes. Prefiero un comentario que admite no saber dónde va a uno que apunta con seguridad al sitio equivocado.

Para navegar los resultados sin vivir en la terminal hay un visor de sesiones en el navegador, donde puedes marcar comentarios como corregidos o ignorados y ocultarlos mientras trabajas en la lista.

⚠️ Cuidado con una cosa: la documentación insiste en no canalizar la salida por tail ni head, porque descarta comentarios de las secciones iniciales. Usa --output y lee el archivo entero.

¿Cómo lo conectas con Claude Code, Codex, Cursor u OpenCode? ¶

Con plugins oficiales para cada plataforma, publicados dentro del propio repositorio.

En Claude Code son dos líneas dentro de la sesión:

/plugin marketplace add alibaba/open-code-review
/plugin install open-code-review@open-code-review

Eso te instala los comandos /open-code-review:review y /open-code-review:delegate-review, que ya puedes invocar desde cualquier sesión.

En Codex se añade el repositorio como marketplace y luego lo activas desde /plugins:

codex plugin marketplace add alibaba/open-code-review
codex

A partir de ahí le hablas en lenguaje natural: “@Open Code Review review this branch against main” o “@Open Code Review review and fix high-confidence issues”.

En OpenCode la integración es más profunda porque registra herramientas nativas (ocr_review, ocr_health) además de los comandos /ocr-review y /ocr-health. Se instala copiando un único archivo TypeScript a ~/.config/opencode/plugins/ y añadiendo la dependencia @opencode-ai/plugin. El mismo archivo sirve para OpenCode 1.x y 2.x.

Para Cursor hay un manifiesto de plugin y la opción de copiar el directorio completo a ~/.cursor/plugins/local/. Y para cualquier agente compatible con el estándar de skills hay una skill portable en el repositorio.

En integración continua están cubiertos GitHub Actions, GitLab CI, GitFlic CI y Gerrit.

¿Qué es el modo delegación y por qué te puede interesar? ¶

Es el modo en el que OCR no llama a ningún modelo. Hace la parte determinista (selección de archivos y resolución de reglas) y deja que tu agente de código haga la revisión con su propio modelo.

Traducido a factura: no necesitas configurar ningún proveedor ni ninguna API key para OCR. Si ya pagas Claude Code, Codex o Cursor, la revisión la hace el modelo que ya tienes pagado.

El flujo tiene tres pasos:

# 1. Qué archivos entran, en qué modo, con qué merge_base
ocr delegate preview --format json --from main --to feature

# 2. Qué reglas aplican a esos archivos, agrupadas por regla
ocr delegate rule --format json src/main.go src/handler.go

# 3. Los diffs los saca el agente con git, según el modo del paso 1
git diff <merge_base>..<to> -- <path>

El contrato que debe cumplir el agente está escrito con una precisión que agradece cualquiera que haya visto a un agente decir “he revisado todo” tras mirar tres archivos: meter cada entrada de reviewable_files en una lista de comprobación explícita, usar (path, status) como identidad, marcar cada archivo como revisado o saltado con un motivo concreto, y reportar totales de revisados, saltados y cobertura.

Ese último punto es el que convierte la delegación en algo útil. No te dice solo qué ha encontrado: te dice cuántos archivos había y cuántos ha mirado. Si la cobertura no llega al cien por cien, lo ves.

🛡️ El modo delegación también desactiva Write y Edit en el agente. La revisión no toca tu código salvo que tú lo pidas después.

Tu IA puede mentirte

Un revisor automático no te dice si el agente te está mintiendo

Verás el ciclo anticaos completo para verificar lo que generan los agentes: pruebas en navegador con Playwright, casos Gherkin y revisión adversarial entre modelos.

Ver el método entero →

Masterclass en directo · Métodos prácticos y casos Gherkin

¿Cómo escribes tus propias reglas de revisión? ¶

Con un JSON en .opencodereview/rule.json dentro del repositorio, donde cada regla asocia un patrón de rutas con una instrucción.

{
  "rules": [
    {
      "path": "**/*.java",
      "rule": "All new methods must validate required parameters for null",
      "merge_system_rule": true
    },
    {
      "path": "**/*mapper*.xml",
      "rule": "Check SQL for injection risks and missing closing tags"
    }
  ]
}

El orden de resolución va de más específico a más general: la bandera --rule <ruta> gana a todo, después el rule.json del repositorio, después el de tu ~/.opencodereview/, y al final las reglas del sistema que vienen de serie (nulos, concurrencia, XSS, inyección SQL, según el lenguaje).

Aquí hay una decisión de diseño que conviene entender: por defecto, tu regla reemplaza la regla del sistema que casaría con ese archivo. Si quieres que se sumen en vez de sustituirse, pones merge_system_rule: true. Es fácil escribir una regla para **/*.java y cargarte sin querer todas las comprobaciones de nulos que venían incluidas.

Para comprobar qué regla acabará aplicándose a un archivo antes de gastar una revisión:

ocr rules check src/main/java/com/example/Foo.java

Escribir reglas de proyecto es el punto donde esta herramienta deja de ser genérica y empieza a conocer tu código. Las convenciones que nadie escribe en ningún sitio no existen para la máquina, y por eso se repiten en cada revisión.

¿Cuánto tarda y cuántos tokens gasta? ¶

Depende del tamaño del diff, pero la herramienta trae topes por defecto y palancas para bajarlos.

Los números que vienen de fábrica:

• Concurrencia: 8 workers de archivos en paralelo. Si tu proveedor te limita la tasa, --concurrency 4 o menos
• Timeout: 15 minutos por ronda, y el esfuerzo medium por defecto son 2 rondas, así que 30 minutos efectivos por grupo. Con low son 15, con high son 45
• Presupuesto de prompt: MAX_TOKENS a 200.000 en la plantilla de revisión, y 58.888 en ocr scan. La salida del modelo se topa aparte en 16.384
• Archivos descartados: si el diff de un archivo por sí solo supera el 80% del presupuesto de prompt, se salta antes de llamar al modelo

Hay además una fase de planificación que se activa sola: cuando el archivo más grande de un grupo llega a 50 líneas cambiadas, o cuando dos o más archivos suman 100 líneas cambiadas entre ellos, el sistema ejecuta un análisis de riesgo previo a la revisión principal. Añade latencia y mejora la calidad.

Para controlar el gasto de una ejecución completa está la bandera que importa:

ocr review --max-tokens-budget 500000

Cuando se supera ese tope, el despacho de trabajo se detiene, los resultados parciales se publican igualmente y los archivos que no llegaron a revisarse se reportan como failed(budget). No te quedas sin resultado y sin saber qué falta: te quedas con lo que dio tiempo y con la lista de lo que no.

Si el consumo de tokens es una preocupación en tu día a día, el enfoque general de cómo ahorrar tokens se aplica igual aquí.

Y si una revisión se te cae a mitad, no empieza de cero:

ocr session list
ocr review --from main --to feature --resume <session-id>

La reanudación funciona para revisiones de rango y de commit. Para el modo workspace no está soportada.

¿Qué dice el benchmark y qué se calla? ¶

Dice que con el mismo modelo por debajo, Open Code Review consigue bastante más precisión y mejor F1 que un agente genérico, consumiendo alrededor de un noveno de los tokens y tardando menos.

Y se calla menos de lo que esperarías, porque la propia documentación admite la contrapartida: el recall es más bajo que el de un agente genérico. Es decir, encuentra menos problemas del total que existen. Lo llaman una decisión deliberada, precisión a cambio de ruido.

Conviene entenderlo bien, porque cambia para qué sirve la herramienta:

El benchmark se llama AACR-Bench y también es open source. Son 200 pull requests reales de 50 proyectos open source activos, en 10 lenguajes: C++, Rust, Go, Java, C#, TypeScript, Python, JavaScript, Ruby y PHP. La anotación la hicieron más de 80 ingenieros de software con dos años de experiencia mínima, en tres rondas de validación cruzada, sobre 2.145 comentarios de revisión (repositorio alibaba/aacr-bench). El README de Open Code Review cifra en 1.505 los problemas anotados como verdad de referencia usados en la comparativa.

Las cifras exactas de precisión, recall, F1, tokens y tiempo están publicadas en el repositorio como gráfica y en el artículo académico asociado. No las reproduzco aquí porque no he podido verificarlas línea a línea, y prefiero que te fíes de lo que sí está escrito en texto: el intercambio de recall por precisión y el orden de magnitud del ahorro de tokens.

Un apunte metodológico que sí conviene señalar: el benchmark lo ha construido el mismo equipo que construye la herramienta. Eso no lo invalida (el dataset es público, el marco de evaluación soporta también Claude Code y Codex como revisores, y cualquiera puede reproducirlo), pero sí te dice que la comparativa está diseñada por alguien con una hipótesis previa.

¿En qué casos no deberías usarlo? ¶

En tres, y vale la pena decirlos antes de que instales nada.

Si tu problema es que nadie revisa nada. Una herramienta que te devuelve quince comentarios de severidad media en una pull request que nadie iba a mirar no arregla el proceso, lo decora. Primero decide quién responde de la calidad del código, después automatiza la parte aburrida.

Si esperas que sustituya a la revisión humana. El recall bajo por diseño significa que se le escapan cosas a propósito. Está pensado para quitarte de encima los defectos mecánicos (nulos, concurrencia, inyección, recursos sin cerrar) y dejarte tiempo para lo que ninguna máquina va a ver: si esta abstracción tiene sentido dentro de seis meses.

Si trabajas en solitario con cambios pequeños. El coste de configurar reglas de proyecto, ajustar exclusiones y calibrar severidades solo se amortiza cuando hay volumen o cuando hay varias personas con criterios distintos. Para tres archivos al día, tu agente de código ya te vale.

Para el resto de escenarios (equipo con pull requests frecuentes, monorepo, código en varios lenguajes, integración continua donde el coste por ejecución importa) es la propuesta más seria que he visto en open source. Si vienes de montar tus revisiones con skills sueltas, compara con las mejores Agent Skills de revisión de código y seguridad y decide cuál de los dos caminos te encaja.

TL;DR ¶

• 🚀 Open Code Review (ocr) es el revisor de código con IA interno de Alibaba, abierto con licencia Apache-2.0 tras dos años y millones de defectos detectados
• 🧩 Su arquitectura híbrida deja en manos de la ingeniería determinista lo que no puede fallar (qué archivos, cómo se agrupan, dónde va el comentario) y reserva el agente para el criterio
• ⚡ Consume alrededor de un noveno de los tokens que un agente genérico con el mismo modelo, a cambio de un recall más bajo de forma deliberada
• 🎯 El modo delegación te deja usar tu propia suscripción de Claude Code, Codex o Cursor sin configurar ninguna API key en OCR
• 📚 Salida estructurada con severidad, categoría y líneas, en texto, JSON o SARIF para GitHub Code Scanning

Preguntas frecuentes ¶

¿Qué es Open Code Review de Alibaba?
Es una herramienta de línea de comandos open source (licencia Apache-2.0) que revisa código con IA. Lee diffs de Git, los analiza mediante un agente con herramientas y devuelve comentarios estructurados con precisión de línea. Fue el revisor interno de Alibaba Group durante dos años antes de publicarse.

¿Cómo se instala el comando ocr?
Con npm install -g @alibaba-group/open-code-review. También hay script de instalación, binarios en las GitHub Releases y compilación desde el código fuente. El único requisito previo es Git 2.41 o superior.

¿Necesito una API key para usarlo?
Para el modo normal sí: configuras proveedor y modelo con ocr config provider y ocr config model. Para el modo delegación no, porque la revisión la ejecuta tu propio agente de código con su modelo, y OCR solo aporta la selección de archivos y las reglas.

¿Qué modelos y proveedores soporta?
Los protocolos soportados son Anthropic, OpenAI Chat Completions, OpenAI Responses y AWS Bedrock, además de proveedores personalizados. En la práctica, cualquier endpoint compatible con esos dialectos funciona, incluidos los self-hosted.

¿En qué se diferencia de pedirle a Claude Code que revise mi código?
En las restricciones duras. OCR decide con lógica de ingeniería qué archivos entran, cómo se agrupan y dónde se coloca cada comentario, en vez de dejar esas decisiones al modelo. El resultado es menos cobertura incompleta, menos deriva de posición y menos variabilidad entre ejecuciones.

¿Puedo usarlo dentro de Claude Code, Codex o Cursor?
Sí, hay plugins oficiales para los cuatro entornos principales. En Claude Code se instala con /plugin marketplace add alibaba/open-code-review seguido de /plugin install open-code-review@open-code-review. OpenCode registra además herramientas nativas ocr_review y ocr_health.

¿Sirve para revisar código que no tiene cambios recientes?
Para eso está ocr scan, que revisa archivos completos sin necesidad de diff ni de historia de Git. Puedes escanear el repositorio entero o limitarlo con --path a un directorio concreto. Es la vía para auditar código heredado.

¿Qué formatos de salida produce?
Tres: text para leer en terminal, json para procesar los hallazgos con tus propias herramientas y sarif para integrarlo con GitHub Code Scanning y otros sistemas de análisis. Cada comentario incluye severidad, categoría, rango de líneas y código de corrección sugerido.

¿Cómo controlo cuánto gasta en tokens?
Con --max-tokens-budget <n>, que limita el total de entrada más salida de la ejecución. Al superarlo se detiene el despacho, se publican los resultados parciales y los archivos sin revisar se marcan como failed(budget). También puedes bajar la concurrencia (8 por defecto) y excluir rutas con --exclude.

¿Puedo definir reglas propias para mi proyecto?
Sí, en un .opencodereview/rule.json dentro del repositorio, asociando patrones de rutas con instrucciones en lenguaje natural. Ten en cuenta que por defecto tu regla sustituye a la del sistema para esos archivos: usa merge_system_rule: true si quieres que se sumen. Con ocr rules check <archivo> compruebas qué regla acabará aplicándose.

Lo que esta herramienta te obliga a decidir ¶

Open Code Review no es la historia de un modelo más listo. Es la historia de alguien que miró dos años de trazas de producción, vio dónde fallaba el agente y decidió sacarle esas decisiones de las manos.

La lección va más allá de la revisión de código. Cada vez que le das a un modelo una tarea que tiene pasos que no pueden salir mal, tienes la misma elección delante: escribir un prompt mejor o sacar ese paso del prompt.

Instala el binario, ejecuta ocr review --preview en tu rama actual y mira la lista de archivos que te devuelve. No gastas un token y ya sabes una cosa que hoy no sabes: cuántos archivos de tu último cambio no ha mirado nadie.

Fuentes ¶

• alibaba/open-code-review en GitHub — repositorio, README y arquitectura
• Paquete @alibaba-group/open-code-review en npm — versiones y fechas de publicación
• SKILL.md de open-code-review — banderas avanzadas, formato de salida, reglas y solución de problemas
• SKILL.md del modo delegación — contrato de ejecución del agente anfitrión
• Plugins para Claude Code, Codex, Cursor y QCA Forward — instalación por plataforma
• alibaba/aacr-bench en GitHub — benchmark, metodología de anotación y métricas
• AACR-Bench: Evaluating Automatic Code Review with Holistic Repository-Level Context — artículo académico del benchmark
• Documentación oficial de Open Code Review — referencia completa de CLI, configuración, CI/CD y visor de sesiones

🧨 Última oprtunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter