c-CRAB, el benchmark de agentes de revisión de código: qué mide, qué encontró y qué significa realmente el 41,5%

Un agente de revisión de código y un revisor humano examinaron la misma pull request y plantearon la misma preocupación. Actuar sobre el comentario del agente corrige el error; la prueba pasa. Y todas las métricas de similitud de texto que los autores calcularon puntuaron la revisión del agente como esencialmente no relacionada con la del humano: BLEU-4 0.00, ROUGE-L 7.02, chrF 20.74, similitud de embeddings 54.59. La misma preocupación, diferentes palabras, y la forma estándar de puntuar una revisión no pudo ver que coincidían. Ese único ejemplo es el argumento detrás de c-CRAB (pronunciado “see-crab”), el Code Review Agent Benchmark publicado como arXiv:2603.23448.

c-CRAB evalúa agentes de revisión de código, no agentes de escritura de código. Dado un pull request — que puede provenir de un humano o de un agente de codificación — un agente de revisión produce una revisión, y c-CRAB puntúa esa revisión según si actuar sobre ella produce una corrección conductualmente correcta. El benchmark fue creado por los investigadores de ingeniería de software Yuntong Zhang, Zhiyuan Pan, Imam Nur Bani Yusuf, Haifeng Ruan, Ridwan Shariffdeen y Abhik Roychoudhury, y evalúa cuatro herramientas: PR-Agent, Devin, Claude Code y Codex. Uno de los autores está afiliado a SonarSource, y el artículo es explícito sobre lo que eso significa y no significa, en sus propias palabras: “Las opiniones y conclusiones expresadas en este artículo son exclusivamente de los autores y no representan las políticas oficiales ni los respaldos de SonarSource. Además, los hallazgos presentados aquí son independientes y no deben interpretarse como una evaluación de la calidad de los productos de SonarSource.”

Dos notas antes del detalle. Algunas publicaciones de terceros se refieren a este mismo trabajo como “{{1}}CR-bench{{/1}}”; es el mismo benchmark, y esta página utiliza c-CRAB en todo momento. Cada figura a continuación es el resultado que reporta el propio artículo, leído hoy del artículo y del paquete de replicación —no reejecutado de forma independiente—, y la interpretación es nuestra, junto con el debate profesional que el artículo ya ha suscitado. Nada de esto es orientación de los proveedores cuyas herramientas fueron evaluadas. Y si todavía estás decidiendo si poner en marcha un agente de revisión de código, nuestra guía del comprador sobre agentes de revisión de código es el mejor punto de partida; esta página trata sobre cómo se miden esos agentes.

Por qué c-CRAB califica las reseñas con tests, no con un juez LLM

La forma habitual de evaluar un agente de revisión de código es comparar su revisión con la de un humano, usando un LLM como juez o una métrica de similitud de texto. Los autores de c-CRAB rechazan ambos enfoques. Argumentan que el LLM como juez adolece de sesgo, inestabilidad y sensibilidad a las instrucciones, lo que dificulta una puntuación reproducible y consistente. Y el caso de estudio anterior muestra lo que las métricas de cadenas realmente miden: la redacción, no la eficacia. En esa solicitud de extracción de python-telegram-bot, la revisión de Codex dijo lo mismo que la del humano, y BLEU-4 y ROUGE-L no pudieron reconocerlo.

Entonces c-CRAB hace lo contrario. Cada comentario de revisión humana 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 — una que haga pasar la prueba. Cada instancia incluye un entorno Docker ejecutable, por lo que la decisión de aprobado/reprobado se toma ejecutando código, no preguntando a otro modelo qué tan similares son dos textos. Por eso es importante: el trabajo de una revisión es cambiar lo que hace un desarrollador, y una prueba es la única señal de puntuación que mide ese cambio directamente.

El artículo define dos tipos de pruebas, con sus propias palabras: “Las pruebas de comportamiento importan y ejecutan el código probado en tiempo de ejecución. Invocan las funciones probadas con entradas específicas, y comprueban salidas o verifican excepciones. Por otro lado, las pruebas estructurales inspeccionan el texto del código fuente, comparan patrones y revisan las superficies de las API para determinar si se han realizado los cambios de código deseados.” La división final es de 42 pruebas de comportamiento (17,9 %) y 192 estructurales (82,1 %). Vale la pena una frase de honestidad: la mayor parte del oráculo consiste en comparar patrones en el texto fuente, no en ejecutar el código. Ese sesgo es una limitación real que conviene tener en cuenta.

Cómo se construyó el benchmark, y cuánto costó el embudo

c-CRAB se construye sobre el conjunto de datos existente inclusionAI/SWE-CARE, que suministra instancias de pull-requests con metadatos de commits; la contribución propia de c-CRAB es el oráculo, no el corpus de PR. El pipeline de curado ejecuta cuatro filtros, y cada uno cuesta instancias. El artículo reporta el embudo de la siguiente manera:

• Conjunto de datos inicial — 671 PRs, 1,313 comentarios.

• Filtrado de revisiones — 410 PRs, 595 comentarios. Un clasificador de LLM, calibrado contra un conjunto de oro de 100 comentarios anotados manualmente, conserva solo los problemas objetivamente verificables y descarta la retroalimentación conversacional o subjetiva.

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

• Conversión de comentarios en lenguaje natural a pruebas — 339 PRs, 481 comentarios. Las pruebas se generan con GPT-5.2 mediante un bucle de refinamiento guiado por ejecución de hasta tres intentos; una prueba se conserva solo si falla en el código original y pasa después de la corrección.

• Validación con un agente de codificación — 184 PRs, 234 comentarios. Claude Code en un backend de Sonnet-4.6 intenta corregir el código teniendo solo el comentario de revisión humana; los casos en los que no puede hacer que la prueba pase se descartan. Este es el conjunto final.

Alrededor del 27% de las solicitudes de extracción iniciales sobreviven. Ese es el precio honesto de un oráculo basado en pruebas, y también es la razón por la que el benchmark es pequeño en lugar de extenso. El conjunto sobreviviente: 184 instancias de PR, 234 comentarios de revisión validados, 1.27 pruebas por instancia, 418.1 líneas modificadas por PR en promedio, 31.8 líneas por prueba. Dos anotadores juzgaron de forma independiente si una prueba generada capturaba fielmente la preocupación del revisor humano, en 50 instancias muestreadas, y coincidieron el 84% de las veces.

Una discrepancia que notará si lee con atención: la tabla del conjunto de datos lista 67 repositorios, mientras que la sección de amenazas a la validez dice “184 instancias de pull requests con 234 oráculos verificables en 56 repositorios.” El artículo presenta ambas cifras, en lugares distintos, y no vamos a promediarlas ni a elegir silenciosamente la más conveniente. Los lectores usan exactamente este tipo de detalle para juzgar si un benchmark merece su tiempo, por lo que ambas se reproducen aquí tal como se publicaron.

Los resultados, y cómo leerlos

La tasa de aprobación es la tasa agregada de aprobación de pruebas: por instancia, es la proporción de las pruebas de ese PR que se aprueban, y la cifra principal es el promedio entre las instancias. El artículo informa, por herramienta:

• Claude Code — 1.336 comentarios, 7,3 por PR — conductual 38,1%, estructural 30,7%, general 32,1%

• Devin — 1,344 comentarios, 7.3 por PR — comportamiento 31.0%, estructural 23.4%, general 24.8%

• PR-Agent — 524 comentarios, 2.8 por PR — conductual 38.1%, estructural 19.8%, global 23.1%

• Codex — 324 comentarios, 1.8 por PR — conductual 38.1%, estructural 16.1%, global 20.1%

• Humano — 234 comentarios, 1.3 por PR — 100% por construcción. Los humanos escribieron el oráculo, por lo que esta fila es un marcador de escala, no un competidor.

Lee esas filas con atención antes de citar cualquiera de ellas. El “solo alrededor del 40%” del resumen es una unión: el 41,5% de las 234 pruebas fueron superadas por al menos una de las cuatro herramientas. No es la puntuación de ningún agente individual — la mejor puntuación individual es la de Claude Code, con un 32,1% — y no significa que las cuatro herramientas juntas detectaran el 40% de los defectos reales. La sección a continuación explica por qué.

El número más interesante no es el ganador. Claude Code y Devin publicaron cada uno más de 1,300 comentarios —alrededor de 7.3 por PR— para alcanzar el 32.1% y el 24.8%. Codex publicó 324, alrededor de 1.8 por PR, para alcanzar el 20.1%. La línea base humana es de 1.3 comentarios por PR. Haz la aritmética: aproximadamente cuatro veces el volumen de comentarios compra mucho menos del doble de la tasa de aprobación. El volumen no es cobertura. Un revisor hablador no es lo mismo que uno útil, y c-CRAB es el primer punto de referencia creado para demostrar eso.

La utilidad va en sentido contrario

Las bajas tasas de aprobación se leen como una condena hasta que observas qué más midieron los autores. Inspeccionaron manualmente 92 comentarios en 6 PRs y consideraron que el 84% de ellos eran útiles (77 de 92) — PR-Agent 94%, Codex 88%, Devin 85%, Claude Code 78%. Entonces, la mayoría de los comentarios que no pasan una prueba c-CRAB no son ruido; se refieren a algo que el revisor humano no planteó. La muestra es pequeña — 92 comentarios, 6 PRs — y el artículo lo dice, y nosotros también deberíamos decirlo.

El mismo patrón aparece en lo que comentan los revisores. 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. Es también la mejor explicación disponible de por qué las puntuaciones parecen bajas: los agentes y los humanos a menudo no están mirando las mismas cosas, y el oráculo solo recompensa la lista del humano.

Lo que c-CRAB no puede ver

El benchmark es explícito sobre su punto ciego, y nosotros también. 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 la revisión humana: un agente que encuentra un error real que nadie mencionó obtiene cero por ello. El artículo lo dice directamente — las herramientas de revisión automatizadas pueden generar otros comentarios valiosos que los revisores humanos no identificaron, pero “al igual que otros benchmarks existentes, c-CRAB no evalúa directamente estos comentarios adicionales.”

Esa única frase es la corrección a la mayor parte de la cobertura de este resultado. Quien cite “los agentes de revisión solo resuelven el 40%” como si midiera cuántos defectos reales detectan los agentes está leyendo mal la cifra. Mide cuántas de las preocupaciones planteadas por humanos lograron resolver los agentes, de manera conjunta — una afirmación más acotada y mucho más honesta.

Ejecutarlo tú mismo

Si quieres reproducir los números o añadir tu propio revisor, el paquete de replicación es público en c-CRAB-Benchmark/dataset. El README es la documentación real, y es honesto sobre la forma del asunto. La configuración es code>uv sync/code>; necesitas Docker y una code>OPENAI_API_KEY/code> o code>ANTHROPIC_API_KEY/code>, y Claude Code además lee las credenciales de code>~/.claude/.credentials.json/code>. La organización también publica imágenes Docker preconstruidas para los entornos.

La estructura: code>pipeline//code> contiene la lógica del pipeline y los prompts, code>execution//code> los constructores de imágenes Docker y los ayudantes de ejecución, code>results_preprocessed//code> el subconjunto de benchmark publicado (410 instancias preprocesadas), code>results_pipeline_funnel//code> los archivos JSONL de stage0–stage4 y el resumen del embudo y code>raw_results_compressed//code> las salidas sin procesar de los experimentos.

Reproducir la ejecución completa consta de cinco pasos: construir los entornos Docker (code>execution.build_swe_care/code>), generar las pruebas (code>run_testgen_full.sh/code>), recopilar las revisiones de referencia (code>run_batch_baselines.py --tools pr-agent devin claude-code codex/code>), ejecutar la resolución de agentes (code>run_batch_agent_resolution.py/code>), y luego evaluar (code>run_batch_tool_eval.py --tool <name>/code>). Si quieres añadir un quinto revisor, ten en cuenta que el punto de extensión no es una interfaz de plugins: las indicaciones de revisión de referencia para cada herramienta están en code>run_batch_baselines.py/code>, y el README no documenta una forma más limpia — tienes que editar ese script.

Dos datos más antes de que lo clones. El artículo está licenciado bajo CC BY 4.0; la página del repositorio no declara una licencia para el código, así que no des por sentado que la tiene. Y el artículo no publica cifras de coste ni de uso de tokens para ejecutar el benchmark — eso no está publicado, así que no vamos a inventarlo. Lo que el pipeline sí implica: una imagen Docker por PR a lo largo de 184 instancias, más una pasada de resolución por agente, no es algo que se haga en una tarde con un portátil.

Lo que esto significa para cualquiera que lance un pipeline de revisión

El argumento central de c-CRAB es que un juez LLM es un oráculo poco fiable. Si no puedes construir oráculos ejecutables — y la mayoría de los equipos no pueden — la mejor mitigación disponible es no permitir nunca que el juez se ejecute en el modelo que produjo la revisión. Un juez que comparte el modelo del revisor está de acuerdo consigo mismo, y la pasada de verificación se convierte en un sello de goma que aun así devuelve un número.

Eso es exactamente el fallo contra el que protege la receta de enrutamiento tras el revisor que distribuimos — y es un paralelismo de diseño con la crítica de c-CRAB, no un resultado de benchmark. El harness ejecuta de todos modos un juez LLM como segunda pasada que agrupa los hallazgos, puntúa cada clúster de 0–1 según si es un defecto concreto en este cambio, y descarta todo lo que quede por debajo de un umbral. La receta que lo rige, code>recipes/orcacode-review.dsl.yaml/code>, es un archivo público. La Action nunca nombra un modelo: llama a un alias de enrutador, y la receta decide. Tal como está aprovisionada, la receta tiene cuatro líneas — el revisor predeterminado es code>deepseek/deepseek-v4-flash-0731/code>, y una regla que coincide con la cabecera code>x-cr-lens: judge/code> envía la pasada del juez a code>z-ai/glm-5.3/code>, un proveedor distinto. Las propias palabras de la receta exigen que el juez “MUST NOT NAME THE DEFAULT’S MODEL”, porque en el propio modelo del revisor “agrees with itself, so the pass goes inert while still reporting success”.

Un juez de otro proveedor reduce la autoconcordancia; no convierte a un juez LLM en una prueba. c-CRAB no probó nuestro revisor, y no vamos a insinuar lo contrario. 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 — así que puedes apuntarlo a un benchmark como este y obtener tu propio número en lugar del nuestro.

En resumen

c-CRAB es el primer benchmark de revisión de código cuya puntuación puedes confiar en gran medida en que significa lo que dice: una revisión solo pasa cuando actuar sobre ella corrige el código. Las cifras principales son genuinamente bajas — la mejor herramienta individual 32.1%, la unión 41.5% — pero miden la superposición con las preocupaciones planteadas por humanos, no la calidad de las revisiones, y los datos de utilidad muestran que la mayoría de los comentarios son señal real. Las conclusiones duraderas son las que el propio artículo defiende: el volumen no es cobertura, los agentes y los humanos observan cosas diferentes, y el despliegue correcto es la colaboración humano-agente. Y el benchmark es abierto, así que el siguiente paso honesto es ejecutar tu propio revisor en él y obtener tu propio número.