Code Review Agent Benchmark: Cómo evaluar a un revisor, y ejecutar c-CRAB en tu propio código

¿Cómo saber si un agente de revisión de código es bueno? Durante la mayor parte de la corta historia de este campo, la respuesta era {{1}}medir cuánto se acercan sus comentarios a los de un revisor humano{{/1}} — lo cual suena razonable hasta que realmente lo intentas, porque dos revisores pueden plantear el mismo problema con palabras completamente distintas. El Code Review Agent Benchmark — {{3}}el artículo es arXiv:2603.23448, su conjunto de datos es c-CRAB{{/3}} — es el primer intento serio de puntuar una revisión por lo que se obtiene al actuar sobre ella, y no por su redacción. Convirtió 234 comentarios de revisores humanos en pruebas ejecutables, ejecutó contra ellas cuatro revisores ampliamente utilizados — {{6}}PR-Agent, Devin, Claude Code y Codex{{/6}} — y descubrió que los cuatro en conjunto aprueban el 41,5 % de esas pruebas, {{7}}"solo alrededor del 40 %"{{/7}} en palabras del propio artículo. Esta página es una guía práctica: {{8}}cómo leer ese resultado sin tergiversarlo, cómo ejecutar c-CRAB por tu cuenta y qué hacer cuando tu base de código no aparece en absoluto en el benchmark{{/8}}.

La cifra principal es lo menos útil de esta página. Lo útil son el método y los modos de fallo: por qué todos los esquemas de puntuación anteriores medían la variable equivocada, cuánto cuesta puntuar una revisión con pruebas ejecutables en su lugar, y por qué «los agentes de revisión solo detectan el 40% de los errores» es una triple mala lectura del resultado real. Todo esto es una lectura comunitaria del benchmark publicado y de la experiencia de los profesionales al ejecutarlo — no orientación de proveedores por parte de los fabricantes de las herramientas implicadas.

Por qué las métricas obvias no funcionan

Antes de c-CRAB, las evaluaciones de los agentes de revisión de código se agrupaban en un pequeño número de familias, y la propia tabla comparativa del artículo (Tabla 1) expone ese linaje. La más antigua es la superposición de texto: BLEU, ROUGE, chrF y similares, utilizados por benchmarks como CodeReviewer y ContextCRBench. La idea es que el comentario de un agente es bueno cuando sus n-gramas coinciden con los de un humano. La idea falla en el tipo de caso que aparece por todas partes en la revisión de código: el mismo defecto descrito con palabras diferentes.

El estudio de caso del artículo es el ejemplo más claro. En una pull request en python-telegram-bot (PR #3514), el revisor humano y Codex señalaron el mismo error de robustez en el indexado anidado. La revisión de Codex fue conductualmente correcta: un agente de codificación que actuó sobre ella produjo una corrección que pasó la prueba ejecutable. Sin embargo, las métricas de texto la puntuaron con BLEU-4 0.00, ROUGE-L 7.02, chrF 20.74 y similitud de embeddings 54.59. Cero solapamiento de n-gramas, y la revisión tenía razón. Misma preocupación, diferentes palabras: las métricas de cadenas no pudieron verla. La similitud de embeddings es una mejora parcial — 54.59 frente a un aprobado confirmado sigue estando lejos de un umbral utilizable — y hereda el mismo problema en forma más suave.

LLM-as-judge, donde un modelo compara la reseña del agente con la humana y vota, soluciona el problema de vocabulario pero introduce tres nuevos, que el artículo nombra directamente: sesgo, inestabilidad y sensibilidad al diseño del prompt. Ejecuta la misma comparación dos veces y un juez puede darte veredictos diferentes; reformula el prompt de evaluación y las clasificaciones cambian. Cuando eliges entre dos revisores que están a tres puntos de distancia en el mismo benchmark, un juez con esa varianza no puede respaldar una decisión — y una puntuación que no puedes reproducir no es una puntuación.

Lo que compra un oráculo ejecutable — y lo que cuesta

La idea sobre la que se basa c-CRAB es simple y radical a la vez: en lugar de preguntar “¿la revisión suena como la del humano?”, pregunta “si actúas según la revisión, ¿se arregla el código?”. Cada comentario de revisión humana retenido se convierte en una prueba ejecutable que captura el problema subyacente. Un comentario de revisión se considera correcto si actuar sobre él produce una corrección conductualmente correcta que hace pasar la prueba — y cada instancia incluye un entorno Docker ejecutable, por lo que “hacer pasar la prueba” es un hecho, no un juicio.

El artículo define dos tipos de pruebas. Las pruebas de comportamiento «importan y ejecutan el código probado en tiempo de ejecución», invocan funciones «con entradas específicas» y comprueban «salidas o verifican excepciones». Las pruebas estructurales «inspeccionan el texto del código fuente, comparan patrones y comprueban las superficies de API para determinar si se han realizado los cambios de código deseados». La división final es de 42 conductuales (17,9 %) y 192 estructurales (82,1 %) — y esa desproporción merece una frase honesta: la mayor parte de este oráculo consiste en comparar patrones en el texto fuente, no en ejecutar el código. El estándar de oro es la prueba de comportamiento; la mayor parte del conjunto de datos es su versión pragmática.

Construir el oráculo es un embudo de cuatro etapas, y cada etapa descarta cosas:

• Conjunto de datos inicial: 671 PR, 1,313 comentarios de revisión.

• Filtrado de revisiones: 410 PR, 595 comentarios. Un clasificador LLM, calibrado contra un conjunto de referencia de 100 comentarios anotados manualmente, conserva solo problemas objetivamente verificables y descarta comentarios conversacionales o subjetivos.

• Construcción de entorno ejecutable — 410 PRs, 595 comentarios. Una imagen Docker por PR, con resolución de dependencias que recurre a un agente de codificación como respaldo cuando la automatización falla.

• Conversión de comentarios NL a pruebas — 339 PRs, 481 comentarios. Generado con GPT-5.2 bajo un bucle de refinamiento guiado por ejecución (hasta tres intentos); una prueba solo se conserva si falla en la versión anterior y pasa en la versión posterior.

• Validación con un agente de codificación: 184 PRs, 234 comentarios (final). Claude Code en un backend de Sonnet-4.6 intenta corregir el código basándose únicamente en el comentario de revisión humana; los casos en los que no consigue que la prueba pase se descartan.

Alrededor del 27% de las solicitudes de extracción iniciales sobreviven. Enúnciese claramente, porque es el precio honesto de un oráculo basado en pruebas: si un comentario no es lo suficientemente procesable como para convertirse en una prueba que falla, o el entorno no se puede construir, o un agente de codificación competente no puede corregir el código a partir del comentario solo, la instancia se descarta. También es por eso que el benchmark es pequeño. 184 instancias de PR y 234 comentarios validados son un conjunto de datos que se puede leer, no un corpus en el que uno pueda ahogarse — y para un oráculo que debe ejecutar entornos Docker reales, la pequeñez es una ventaja.

Para escala: una instancia promedio toca 418.1 líneas modificadas, las pruebas promedian 31.8 líneas, y hay 1.27 pruebas por instancia. Dos anotadores coincidieron el 84% de las veces — en más de 50 instancias muestreadas — sobre si una prueba generada capturaba fielmente la preocupación del revisor humano.

Una verruga bibliográfica con la que te toparás si vas a leer el artículo tú mismo: la tabla del conjunto de datos (Tabla 4) enumera 67 repositorios, mientras que la sección de Amenazas a la validez dice «184 instancias de pull request con 234 oráculos verificables en 56 repositorios». El artículo presenta ambas cifras en lugares distintos y no las concilia. No elijas una favorita ni hagas un promedio: cita cada una donde aparezca. Discrepancias como esta son precisamente el detalle que los lectores usan para decidir si un benchmark merece su tiempo.

Para la debida diligencia sobre la independencia: el documento revela que uno de los autores está afiliado a SonarSource, y afirma que los hallazgos no deben interpretarse como «una evaluación de la calidad de los productos de SonarSource». Esa es su exención de responsabilidad, citada en lugar de parafraseada.

Cómo leer una puntuación de c-CRAB sin citarla mal

La métrica principal es la tasa de aprobación: por instancia, la proporción de pruebas de ese PR que pasan, promediada entre las 184 instancias. Aquí está la tabla completa de resultados del artículo, una línea por revisor. La fila de humanos es un marcador de escala más que un competidor: los humanos escribieron el oráculo, por lo que obtienen un 100% por construcción.

• Claude Code — 1,336 comentarios, 7.3 por PR, en general 32.1% (comportamental 38.1%, estructural 30.7%).

• Devin — 1,344 comentarios, 7.3 por PR, en general 24.8% (comportamental 31.0%, estructural 23.4%).

• PR-Agent — 524 comentarios, 2,8 por PR, global 23,1% (conductual 38,1%, estructural 19,8%).

• Codex — 324 comentarios, 1.8 por PR, total 20.1% (comportamental 38.1%, estructural 16.1%).

• Humano — 234 comentarios, 1.3 por PR, 100% por construcción.

Tres correcciones, porque el "solo alrededor del 40%" del resumen es el número más mal citado en este rincón de la conversación sobre IA para programadores ahora mismo. Primero, la cifra del 41.5% — 97 de las 234 pruebas superadas por al menos una herramienta — es una unión entre los cuatro revisores: una prueba cuenta una vez si cualquier agente la superó. Ningún agente individual obtuvo un 41.5%; la mejor puntuación individual es el 32.1% de Claude Code. Segundo, la fila de humano es el oráculo, no un concursante; repetirla como "los humanos vencen a los bots" es un error de categoría. Tercero, y más importante: c-CRAB no da crédito por un problema válido que el revisor humano nunca planteó. El oráculo es la intención de revisión humana. Un agente que encuentra un error real que nadie mencionó obtiene un cero por ello. Así que "los agentes de revisión de IA solo detectan el 40% de los errores" está mal tres veces — es una unión, no es una tasa de detección de errores, y mide la concordancia con los revisores humanos, no la corrección total.

El volumen de comentarios es la trampa.

El número más interesante de los resultados no es el ganador. Claude Code y Devin publicaron cada uno más de 1300 comentarios — aproximadamente 7,3 por PR — para alcanzar el 32,1% y el 24,8%. Codex publicó 324 comentarios, aproximadamente 1,8 por PR, y alcanzó el 20,1%. La línea base humana es de 1,3 comentarios por PR. El volumen no es cobertura: aproximadamente cinco veces más comentarios apenas compran menos del doble de la tasa de aprobación. Si estás eligiendo un revisor, el costo real de todos esos comentarios adicionales es la fatiga de revisión humana — cada comentario que publica un agente es un juicio que una persona tiene que evaluar y priorizar.

El hallazgo sobre la utilidad va en la otra dirección, y es la pieza que evita que esto sea una historia barata de "los bots son ruidosos". Los autores inspeccionaron manualmente 92 comentarios en 6 PRs y juzgaron que el 84% (77/92) eran útiles: PR-Agent 94%, Codex 88%, Devin 85%, Claude Code 78%. Así que la mayoría de los comentarios que no pasan la prueba no son ruido; se refieren a algo que el revisor humano no planteó. La muestra es pequeña — 92 comentarios, 6 PRs — y conviene decirlo junto con los porcentajes.

Lo que realmente discuten ambas partes explica la forma de los resultados. Los revisores humanos se inclinaron hacia la mantenibilidad, el diseño y la documentación; las herramientas se inclinaron hacia la robustez, las pruebas y el manejo de errores. El artículo lo interpreta como un argumento a favor de la colaboración humano-agente en lugar del reemplazo — y también es la mejor explicación disponible de por qué las puntuaciones parecen bajas. Un revisor que es agudo en los casos límite pero callado en el diseño omitirá sistemáticamente las categorías que los humanos señalan, y el oráculo está construido enteramente a partir de las señales humanas.

Los profesionales que han trabajado en esto llegan al mismo punto. Un análisis detallado de Daniel Vaughan que llama al trabajo CR-bench llega a la misma conclusión y lo convierte en un flujo de trabajo: deja que el agente haga el barrido de robustez y corrección, mantén a los humanos en el diseño, las convenciones y la arquitectura — las categorías donde los agentes obtienen peores resultados — y guía al agente con instrucciones de revisión que nombren las categorías débiles. Su advertencia más útil para cualquiera que lea el leaderboard: «la utilidad no es lo mismo que la tasa de aprobación», porque el conjunto de pruebas requiere que coincida con la corrección prevista por el humano, y una alternativa válida falla la prueba. El camino del 20% a una puntuación significativamente más alta, según su lectura, no es una actualización del modelo — es trabajo de configuración.

Ejecutar c-CRAB tú mismo

Todo lo anterior es leer los resultados de otras personas. El paquete de replicación hace que el benchmark sea ejecutable — está en c-CRAB-Benchmark/dataset en GitHub — y el README es honesto sobre lo que implica.

Requisitos: code>uv sync/code>; Docker; y ya sea code>OPENAI_API_KEY/code> o code>ANTHROPIC_API_KEY/code> (Claude Code además lee las credenciales de code>~/.claude/.credentials.json/code>, montado en los contenedores por defecto). La estructura es de cinco directorios: code>pipeline//code> (lógica del pipeline y prompts), code>execution//code> (constructores de imágenes Docker y utilidades de ejecución), code>results_preprocessed//code> (el subconjunto del benchmark publicado), code>results_pipeline_funnel//code> (los archivos JSONL de stage0 a stage4 y el resumen del embudo), y code>raw_results_compressed//code> (salidas sin procesar de los experimentos). Los cinco pasos, en orden:

1. Construir los entornos Docker — code>uv run python -m execution.build_swe_care --split test --instance results_preprocessed/instance-ids.txt --max-workers 4/code>. Las imágenes precompiladas también se publican en la organización de paquetes de GitHub c-CRAB-Benchmark si prefiere omitir la compilación.

2. Generar las pruebas — code>./run_testgen_full.sh --instances-file results_preprocessed/instance-ids.txt --workers 4 --output-dir results_testgen/code>.

3. Recopile las revisiones de referencia — code>uv run python run_batch_baselines.py --split test --instances-file results_preprocessed/instance-ids.txt --tools pr-agent devin claude-code codex --output-dir baselines_output --workers 4/code>. Configure las credenciales de la herramienta externa correspondiente antes de este paso.

4. Ejecutar la resolución de agentes — code>uv run python run_batch_agent_resolution.py --stage3-file results_pipeline_funnel/stage3_testgen_verified.jsonl --testgen-dir results_testgen --output-dir results_agent_resolution --workers 4/code>.

5. Evaluar — repetir una vez por herramienta: code>uv run python run_batch_tool_eval.py --tool pr-agent --stage3-file results_pipeline_funnel/stage3_testgen_verified.jsonl --testgen-dir results_testgen --tool-results-dir baselines_output --output-dir results_eval_pr-agent --workers 4/code>.

El README no anuncia dos cosas. Añadir un quinto revisor implica editar code>run_batch_baselines.py/code> — que es donde se encuentran las indicaciones de revisión de referencia por herramienta, y no hay interfaz de plugin; el README no documenta ningún punto de extensión más limpio. Además, el repositorio no incluye ningún archivo de licencia explícito, así que no asumas que el código es MIT o Apache: el artículo es CC BY 4.0 y los términos del propio código no están declarados.

El costo es el otro elemento no anunciado. El artículo no publica cifras de tokens ni de dólares para ejecutar el pipeline, así que trate cualquier cifra de costo que vea citada en línea como no verificada. Lo que implica la estructura es bastante claro: una imagen de Docker por PR en 184 instancias, más una pasada de resolución del agente de codificación y una pasada de evaluación por herramienta. Eso no es una tarde a escala de portátil: presupueste cómputo real.

Cuando no puedes permitirte oráculos ejecutables

La posición honesta de la mayoría de los equipos es: el benchmark tiene razón en que un juez LLM no puede puntuar las revisiones, pero construir un oráculo basado en pruebas para tus propios PRs es un gran esfuerzo. La distinción que vale la pena hacer es entre un juez LLM como puntuador y un juez LLM como filtro. El rechazo de c-CRAB del juez como oráculo no hace que un juez sea inútil dentro de un revisor: un juez que agrupa hallazgos duplicados y descarta los débiles aún puede aumentar la precisión. El modo de fallo contra el que hay que diseñar es la independencia.

Un juez que se ejecuta en el propio modelo del revisor está de acuerdo consigo mismo: lee la reseña, la considera plausible e informa de éxito sin cambiar nada. Un juez de otro proveedor reduce esa autoconformidad: no convierte al juez en una prueba, pero detiene el sello de goma. Podemos mostrarte un caso concreto y verificable de exactamente esta salvaguarda porque nuestro propio arnés es abierto: Orca-Code-Review en GitHub está bajo licencia MIT, y su receta de enrutamiento establece la regla con las palabras del propio repositorio: el juez "NO DEBE NOMBRAR EL MODELO DEL PREDETERMINADO", porque "en el propio modelo del revisor está de acuerdo consigo mismo, así que el pase se vuelve inerte mientras sigue informando de éxito". La acción nunca nombra un modelo; la receta decide. Tal como está aprovisionado, el revisor predeterminado es deepseek/deepseek-v4-flash-0731, y una regla que coincide con el encabezado code>x-cr-lens: judge/code> envía el pase del juez a z-ai/glm-5.3 — un proveedor diferente. Eso es un paralelismo de diseño con el argumento de c-CRAB, no un resultado: no estamos en el benchmark y no hay ninguna puntuación de c-CRAB para nuestro revisor. Pero es la mitigación práctica disponible para cualquiera que no pueda construir oráculos ejecutables, y es barata cuando el juez y el revisor pueden alojarse en proveedores distintos detrás de una sola clave — que es para lo que sirve un enrutador. En OrcaRouter el revisor y su juez son dos líneas en un DSL de enrutamiento, y pagas el precio de lista del proveedor sin margen adicional.

Cuando tu código no está en el benchmark

184 PRs en 56 o 67 repositorios públicos no son tu código base, y nunca lo iban a ser. La parte transferible es el método, y puedes ejecutarlo sobre tu propio historial a una escala mucho menor. Toma PRs fusionados que tuvieron comentarios de revisión humana. Para una muestra de esos comentarios, escribe un test que falle antes de que la revisión se aplicara y pase después — la propiedad de falla-y-luego-pasa es todo el juego. Ejecuta tu revisor candidato sobre el diff previo a la revisión. Luego comprueba si actuar según sus comentarios hace que el test pase. Lo que obtienes es un número calculado sobre el código que realmente publicas, que vale más que una posición en un leaderboard. Lo que cuesta es exactamente el muro contra el que chocó el artículo: necesitas entornos reproducibles por PR, porque un test que solo pasa en tu portátil no es un oráculo.

No necesitas 234 pruebas. Una docena bien elegidas de PRs sobre los que tu equipo realmente discutió te dirán más sobre tu revisor que una puntuación de benchmark. Y un análisis práctico paralelo de esta familia de benchmarks es directo sobre el filtro: la precisión del clasificador LLM sobre si un comentario es un problema válido y verificable se sitúa entre el 66% y el 85%, así que trata el filtrado automático como una lista corta y mantén un paso de adjudicación humana antes de que cualquier cosa se convierta en una prueba. El mismo informe señala que ReviewBench de LangChain, construido independientemente sobre la misma idea de convertir comentarios en pruebas, recupera como máximo alrededor del 30% de sus problemas de referencia — el mismo rango que el 20–32% de c-CRAB, y un recordatorio de que las diferencias de un solo dígito en los rankings entre herramientas suelen ser menores que el ruido en tu propia configuración.

Si estás decidiendo si comprar alguna herramienta de revisión, esa es una pregunta diferente: nuestra guía del comprador de agentes de revisión de código cubre bot frente a agente, precios por asiento frente a por token y cuándo gana el autoalojamiento; y una vez que tienes una, el costo de ejecutar una infraestructura de revisión en cada push se cubre en nuestro explicador de revisión de código automatizada. Esta página trata solo sobre la medición, y el artículo complementario a este recorre la anatomía del benchmark: el embudo de construcción, las estadísticas del conjunto de datos y la tabla de resultados completa.

Preguntas frecuentes

¿Es 41.5% la mejor puntuación de un agente? No. 41.5% es la unión entre las cuatro herramientas: una prueba cuenta una vez si alguna de ellas la superó. La mejor puntuación individual es la de Claude Code, con 32.1%.

¿Mide c-CRAB cuántos errores detecta un revisor? No. Mide qué tan bien coincide una revisión con lo que un revisor humano señaló, convertido en pruebas ejecutables. Un defecto real que el humano nunca mencionó obtiene cero puntos, por muy válido que sea.

¿Los revisores humanos "vencieron" a los bots? La fila 100% humana es el oráculo en sí mismo — los humanos escribieron las pruebas — por lo que es un marcador de escala, no un competidor.

¿Es c-CRAB lo mismo que CR-bench? Sí. El conjunto de datos es c-CRAB; alguna cobertura de terceros lo llama CR-bench, pero aquí solo hay un benchmark.

¿Cuánto cuesta ejecutarlo? El artículo no publica cifras de costos. Una imagen de Docker por PR en 184 instancias, más una pasada de resolución de agentes, implica un cómputo real — no algo que se pueda hacer en una laptop en una tarde.

En resumen

La contribución de c-CRAB no es el leaderboard — es {{1}}la demostración de que una revisión puede puntuarse ejecutando sus recomendaciones, y de que los esquemas de similitud de texto y de juez-LLM que vinieron antes estaban puntuando lo incorrecto{{/1}}. Si hay algo que debas quedarte, que sea la corrección en tres partes: {{2}}el 41.5% es una unión, la fila humana es el oráculo, y el benchmark no da crédito por defectos que los humanos nunca señalaron{{/2}}. Y si quieres un número sobre el que puedas actuar, el método se transfiere — {{3}}pruebas que fallan y luego pasan en tus propios PRs fusionados, un paso de arbitraje humano y, si no puedes construir oráculos ejecutables, al menos un juez cuyo modelo sea independiente del del revisor{{/3}}.

Si prefiere medir a un revisor en lugar de discutir sobre uno, comience con un arnés de pruebas que pueda leer. OrcaCode Review ejecuta una pasada de revisión más un juez de verificación independiente, por token en lugar de por asiento, y cada prompt en él es público — para que pueda apuntarlo a un benchmark como este y obtener su propio número en lugar del nuestro.