Open Code Review: el CLI de Alibaba con Pipeline de Reglas + LLM

1. Qué Es Open Code Review

Open Code Review es un CLI en Go (ocr) que lee un diff de Git, envía los archivos modificados a un LLM configurable mediante un agente con uso de herramientas, y devuelve comentarios de revisión estructurados y anclados a números de línea. Según su README nació como el asistente interno de code review con IA de Alibaba Group y se liberó tras unos dos años de uso interno. Además de diffs, ocr scan revisa archivos completos en directorios que no tienen un diff significativo.

Las estrellas son atención, no prueba. 47K en menos de cinco meses dice que la propuesta pegó; no dice que la calidad de revisión se sostenga en tu stack. Las secciones siguientes separan lo que muestra la documentación de lo que deberías probar vos.

2. Pipeline de Reglas + LLM vs. Revisión Agéntica

La forma habitual de armar un revisor con IA es darle a un agente de código de propósito general un skill de review y dejar que decida todo: qué archivos abrir, qué chequear, dónde anclar cada comentario. El README nombra tres modos de falla que atribuye a ese enfoque:

La respuesta de OCR es sacar del prompt los pasos que no pueden fallar y llevarlos a código. La comparación siguiente es mi resumen de la sección de diseño del README:

3. La Arquitectura en 4 Pasos

La doc de arquitectura describe un pipeline lineal: bootstrap, proveedor de diff, filtro y reglas, agrupación, sub-agentes y salida. Cuatro ideas lo sostienen:

4. Qué Dice el Benchmark (y Qué No)

El README publica un gráfico sobre AACR-Bench: 50 repositorios open source, 200 pull requests reales, 10 lenguajes y 1.505 issues anotados, validados cruzadamente por más de 80 ingenieros senior según el proyecto. El benchmark sale de la misma organización de Alibaba que construyó la herramienta, así que leelo como un resultado del proveedor. Estos son los dos pares con el mismo modelo que leí en la imagen del gráfico el 2026-10-14 (OCR v1.3.1 vs. Claude Code v2.1.169):

Lo que se sostiene: en esos dos pares la precisión es entre 2,4x y 4,7x mayor y el consumo de tokens entre 5,9x y 14,7x menor, y OCR reporta muchos menos comentarios (889 contra 5.980 en el primer par), que es lo que significa “menos ruido” en la práctica. Lo que no: el recall no es mejor, y en términos absolutos todas las filas del gráfico encuentran una minoría de los issues anotados (lo mejor de OCR es 20,00%). Además el gráfico usa OCR v1.3.1 mientras que la versión actual es v1.13.0, y el texto del README no informa varianza entre corridas.

5. Quickstart: Tu Primera Revisión

Requisitos según la documentación: Git 2.41+ y Node.js 18+. Los comandos de abajo están copiados del README y de la doc de quickstart, verificados contra el README el 2026-10-14. Para este post no ejecuté el instalador ni ninguno de estos comandos.

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

Existen otras vías de instalación (Homebrew, un script con curl, binarios de release, compilar desde el código fuente) listadas en la doc de instalación. Un detalle importante: el wrapper de npm busca versiones nuevas en segundo plano y se actualiza solo por defecto; definir OCR_NO_UPDATE con cualquier valor no vacío lo desactiva.

ocr config provider          # Select a built-in provider or add a custom one
ocr config model             # Pick a model for the active provider
ocr llm test

La interfaz interactiva te guía por proveedor, API key y modelo, y prueba la conectividad por su cuenta. El modo delegación (sección 9) se saltea este paso por completo.

cd your-project

# Workspace mode — review all staged, unstaged, and untracked changes
ocr review

# Branch range — reviews feature-branch's changes since it diverged from main (merge-base mode)
ocr review --from main --to feature-branch

# Single commit
ocr review --commit abc123

Previsualizá qué se revisaría antes de gastar tokens, y escribí salida legible por máquinas para tus scripts:

# What would be reviewed, and why files were kept or dropped (no LLM cost)
ocr review --preview

# Save results to a file
ocr review --format json --output result.json

# Full-file scan of a directory instead of a diff
ocr scan --path internal/agent

6. Proveedores y Reglas

OCR habla los protocolos de Anthropic, compatible con OpenAI y OpenAI Responses, además de AWS Bedrock. La doc de configuración lista presets integrados, así que casi siempre elegís uno y pegás una key:

ocr config set provider                    anthropic
ocr config set model                       claude-opus-4-6
ocr config set providers.anthropic.api_key_cmd "op read op://dev/anthropic/api-key"

Todo lo que no esté en la lista de presets es un proveedor custom, que es como apuntás OCR a un gateway interno o a un modelo local. Este es el ejemplo de Ollama de la doc:

ocr config set provider                          ollama
ocr config set custom_providers.ollama.url       http://127.0.0.1:11434/v1
ocr config set custom_providers.ollama.protocol  openai
ocr config set custom_providers.ollama.model     qwen3:32b
ocr config set custom_providers.ollama.api_key   ollama

Las reglas son donde codificás los estándares de tu equipo. Son JSON, en capas y se asignan por archivo con globs; gana la primera entrada que coincide. Por defecto una entrada que coincide reemplaza la regla de lenguaje integrada para ese archivo, así que usá merge_system_rule cuando quieras sumar en vez de reemplazar:

{
  "rules": [
    {
      "path": "**/*",
      "rule": "Security review: flag hardcoded secrets, unvalidated redirects, and missing authz checks.",
      "merge_system_rule": true
    }
  ]
}

Las reglas embebidas cubren Java, Go, TypeScript y JavaScript, Rust, Python, Solidity, Vyper, Terraform, workflows de GitHub y más. Cuando una regla nunca se dispara, este comando imprime la capa y el patrón que ganó:

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

7. Dónde Encaja en CI

El repo trae ejemplos de CI para GitHub Actions, GitLab CI, Bitbucket Pipelines, GitFlic CI y Gerrit. El camino de GitHub es una action reutilizable: instala OCR, calcula el merge base, ejecuta ocr review --from <merge-base> --to <head> --format json y publica comentarios inline más un resumen en el PR. Los permisos son contents: read y pull-requests: write. El paso central del README del ejemplo:

- uses: alibaba/open-code-review@main
  with:
    llm_url: ${{ secrets.OCR_LLM_URL }}
    llm_auth_token: ${{ secrets.OCR_LLM_AUTH_TOKEN }}
    llm_model: ${{ vars.OCR_LLM_MODEL }}
    llm_use_anthropic: ${{ vars.OCR_LLM_USE_ANTHROPIC }}

El ejemplo espera OCR_LLM_URL y OCR_LLM_AUTH_TOKEN como secrets, y OCR_LLM_MODEL y OCR_LLM_USE_ANTHROPIC como variables. Tres cosas que cambiaría antes de copiarlo:

- uses: alibaba/open-code-review@<full-commit-sha> # vX.Y.Z
  with:
    ocr_version: 'X.Y.Z'
    llm_url: ${{ secrets.OCR_LLM_URL }}
    llm_auth_token: ${{ secrets.OCR_LLM_AUTH_TOKEN }}
    llm_model: ${{ vars.OCR_LLM_MODEL }}
    llm_use_anthropic: ${{ vars.OCR_LLM_USE_ANTHROPIC }}

- uses: alibaba/open-code-review@<full-commit-sha> # vX.Y.Z
  with:
    ocr_version: 'X.Y.Z'
    effort: low
    max_tokens_budget: '2000000'

8. Privacidad: Qué Sale Realmente de Tu Máquina

Mandar código a un modelo de terceros es la verdadera pregunta de adopción. Esto es lo que dicen la FAQ y la documentación:

Para código regulado la doc de configuración te da palancas: Bedrock con la cadena de credenciales de AWS, un gateway LiteLLM dentro de tu VPC vía providers.<name>.url, o un modelo local con Ollama. Algunos presets apuntan a hosts en cn-beijing (volcengine, dashscope-tokenplan), así que revisá la residencia de datos antes de elegir uno.

9. Dónde Brilla: Casos de Uso

OCR se gana su lugar donde querés comentarios de revisión consistentes y con poco ruido en cada cambio:

El hilo común: el pipeline vuelve repetibles las partes aburridas (qué revisar, con qué reglas, dónde comentar) y el modelo se gasta solo en criterio.

10. Cuándo NO Usarlo

Me gusta la ingeniería, pero esta es una herramienta de precisión, no una red de seguridad. Evitala cuando:

Conclusión

Open Code Review es una respuesta creíble a un problema real: agentes revisores que se saltean archivos, se corren de línea y cuestan una fortuna en tokens. Llevar a código la selección de archivos, la asignación de reglas y el posicionamiento de comentarios es el instinto correcto, y la documentación es inusualmente franca sobre el costo: menor recall, sin redacción de secretos integrada, fallas que salen con código 0.

Mi consejo es simple. Instalalo, corré ocr review --preview sobre una rama real, reproducí unos cuantos PRs mergeados y decidí con tus propios números. Si encuentra los bugs que te importan, fijá la versión y ponelo en CI como revisor consultivo.