Home
Blog
La revisión del código de IA mejora cuando los modelos debaten: Claude vs Gemini vs Codex vs Qwen vs MiniMax

La revisión del código de IA mejora cuando los modelos debaten: Claude vs Gemini vs Codex vs Qwen vs MiniMax

Engineering

February 26, 2026

Li Liu

Hace poco utilicé modelos de IA para revisar un pull request, y los resultados fueron contradictorios: Claude marcó una carrera de datos, mientras que Gemini dijo que el código estaba limpio. Eso me despertó la curiosidad por saber cómo se comportarían otros modelos de IA, así que pasé los últimos modelos insignia de Claude, Gemini, Codex, Qwen y MiniMax por una prueba comparativa estructurada de revisión de código. ¿Los resultados? El modelo con mejor rendimiento sólo detectó el 53% de los errores conocidos.

Sin embargo, mi curiosidad no acababa ahí: ¿y si estos modelos de IA trabajaran juntos? Probé a ponerlos a debatir entre ellos y, tras cinco rondas de debate, la detección de errores aumentó hasta el 80%. Los errores más difíciles, los que requerían una comprensión del sistema, se detectaron al 100% en el modo de debate.

Este artículo analiza el diseño del experimento, los resultados por modelo y lo que el mecanismo de debate revela sobre cómo utilizar realmente la IA para la revisión de código.

Evaluación comparativa de Claude, Gemini, Codex, Qwen y MiniMax para la revisión de código

Si has estado utilizando modelos para la revisión de código, probablemente te habrás dado cuenta de que no sólo difieren en precisión, sino también en cómo leen el código. Por ejemplo, Claude

Claude suele recorrer la cadena de llamadas de arriba abajo y dedicará tiempo a las rutas "aburridas" (gestión de errores, reintentos, limpieza). A menudo es ahí donde se esconden los verdaderos errores, así que no odio esa minuciosidad.

Géminis tiende a empezar con un veredicto contundente ("esto está mal" / "parece que está bien") y luego trabaja hacia atrás para justificarlo desde un ángulo de diseño/estructura. A veces es útil. A veces da la impresión de que se ha escaqueado y luego se ha comprometido a tomar una decisión.

Codex es más silencioso. Pero cuando señala algo, suele ser concreto y aplicable: menos comentarios y más "esta línea está mal porque X".

Pero se trata de impresiones, no de mediciones. Para obtener cifras reales, establecí un punto de referencia.

Configuración

Se probaron cinco modelos emblemáticos:

Claude Opus 4.6
Gemini 3 Pro
GPT-5.2-Codex
Qwen-3.5-Plus
MiniMax-M2.5

Herramientas (Magpie)

Utilicé Magpie, una herramienta de evaluación comparativa de código abierto creada por mí. Su trabajo consiste en hacer la "preparación de la revisión del código" que normalmente se haría manualmente: extraer el contexto circundante (cadenas de llamadas, módulos relacionados y código adyacente relevante) e introducirlo en el modelo antes de que revise el PR.

Casos de prueba (Milvus PRs con errores conocidos)

El conjunto de datos se compone de 15 pull requests de Milvus (una base de datos vectorial de código abierto creada y mantenida por Zilliz). Estos PRs son útiles como punto de referencia porque cada uno fue fusionado, sólo para requerir más tarde una reversión o hotfix después de que un error apareciera en producción. Por tanto, cada caso tiene un fallo conocido que podemos comparar.

Niveles de dificultad de los fallos

No todos estos errores son igual de difíciles de encontrar, así que los clasifiqué en tres niveles de dificultad:

L1: Visibles sólo a partir del diff (use-after-free, off-by-one).
L2 (10 casos): Requiere entender el código circundante para detectar cosas como cambios semánticos en la interfaz o carreras de concurrencia. Son los errores más comunes en la revisión diaria del código.
L3 (5 casos): Requiere comprensión a nivel de sistema para detectar problemas como incoherencias de estado entre módulos o problemas de compatibilidad con actualizaciones. Estas son las pruebas más duras de la profundidad con la que un modelo puede razonar sobre una base de código.

Nota: Todos los modelos detectaron todos los errores L1, por lo que los excluí de la puntuación.

Dos modos de evaluación

Cada modelo se ejecutó en dos modos:

Raw: el modelo sólo ve el PR (diff + lo que haya en el contenido del PR).
R1: Magpie extrae el contexto circundante (archivos relevantes / sitios de llamada / código relacionado) antes de que el modelo lo revise. Esto simula un flujo de trabajo en el que se prepara el contexto por adelantado en lugar de pedir al modelo que adivine lo que necesita.

Resultados (sólo L2 + L3)

Modo	Claude	Géminis	Codex	MiniMax	Qwen
En bruto	53% (1º)	13% (último)	33%	27%	33%
R1 (con contexto de Magpie)	47% ⬇️	33%⬆️	27%	33%	40%⬆️

Cuatro conclusiones:

1. Claude domina la revisión en bruto. Obtuvo un 53% de detección global y un perfecto 5/5 en errores L3, sin ninguna ayuda de contexto. Si utilizas un único modelo y no quieres dedicar tiempo a preparar el contexto, Claude es la mejor opción.

2. Gemini necesita que le den contexto. Su puntuación bruta del 13% fue la más baja del grupo, pero con Magpie proporcionando código de contexto, subió al 33%. Géminis no reúne bien su propio contexto, pero su rendimiento es respetable cuando se hace ese trabajo por adelantado.

3. Qwen es el que mejor funciona con ayuda del contexto. Obtuvo un 40% en el modo R1, con 5/10 en errores L2, que fue la puntuación más alta en ese nivel de dificultad. Para revisiones diarias rutinarias en las que estés dispuesto a preparar el contexto, Qwen es una elección práctica.

4. Más contexto no siempre ayuda. Elevó a Gemini (13% → 33%) y MiniMax (27% → 33%), pero en realidad perjudicó a Claude (53% → 47%). Claude ya destaca en la organización del contexto por sí solo, por lo que la información adicional probablemente introdujo ruido en lugar de claridad. La lección: adapte el flujo de trabajo al modelo, en lugar de asumir que más contexto es universalmente mejor.

Estos resultados coinciden con mi experiencia cotidiana. Que Claude ocupe el primer puesto no es sorprendente. La puntuación de Géminis, más baja de lo que esperaba, tiene sentido en retrospectiva: normalmente utilizo Géminis en conversaciones de varios turnos en las que estoy iterando sobre un diseño o persiguiendo un problema juntos, y funciona bien en ese entorno interactivo. Este benchmark es un pipeline fijo de una sola pasada, que es exactamente el formato en el que Gemini es más débil. La sección de debate mostrará más adelante que cuando se le da a Géminis un formato adversario de varias rondas, su rendimiento mejora notablemente.

Dejar que los modelos de IA debatan entre sí

Cada modelo mostró diferentes puntos fuertes y débiles en las pruebas comparativas individuales. Así que quise probar: ¿qué ocurre si los modelos revisan el trabajo de los demás en lugar de sólo el código?

Así que añadí una capa de debate sobre el mismo punto de referencia. Los cinco modelos participan en cinco rondas:

En la ronda 1, cada modelo revisa el mismo RP de forma independiente.
Después, transmito las cinco revisiones a todos los participantes.
En la ronda 2, cada modelo actualiza su posición basándose en las otras cuatro.
Se repite hasta la quinta ronda.

Al final, cada modelo no sólo reacciona al código, sino a argumentos que ya han sido criticados y revisados varias veces.

Para evitar que esto se convierta en un "LLM de acuerdo en voz alta", impuse una regla estricta: cada afirmación tiene que apuntar a un código específico como prueba, y un modelo no puede limitarse a decir "buena observación", sino que tiene que explicar por qué ha cambiado de opinión.

Resultados: Mejor Solo vs Modo Debate

Modo	L2 (10 casos)	L3 (5 casos)	Detección total
Mejor individual (Raw Claude)	3/10	5/5	53%
Debate (los cinco modelos)	7/10 (doblado)	5/5 (todos atrapados)	80%

Cómo es el debate en la práctica

Las cifras anteriores demuestran que el debate funciona, pero un ejemplo concreto muestra por qué funciona. He aquí un resumen de cómo los cinco modelos trataron el PR #44474, que introdujo la carga perezosa de claves primarias durante la búsqueda.

PR #44474: Una optimización de la carga perezosa que cambió la búsqueda para obtener claves primarias bajo demanda en lugar de cargarlas todas por adelantado.

Primer asalto

Géminis abrió agresivamente:

"Este PR es un campo minado de malas prácticas, potenciales comportamientos indefinidos y regresiones de rendimiento disfrazadas de 'optimización'".

Claude y Qwen se centraron en el comportamiento indefinido y el rendimiento, convergiendo en la misma preocupación:

"El modelo de memoria de C++ no garantiza la seguridad de las escrituras concurrentes en diferentes índices del mismo vector sin la sincronización adecuada".

Los tres encontraron problemas reales, pero ninguno de ellos detectó el fallo más profundo. Entonces Codex, que apenas había hablado, señaló algo que los otros pasaron por alto: el vector primary_keys_ se redimensiona, pero sólo se rellenan las posiciones que pasan por la fase de reducción. Todas las demás posiciones quedan con valor cero.

Segundo asalto

Claude recogió el hallazgo de Codex y rastreó las consecuencias:

"Lo he encontrado: SortEqualScoresByPks se ejecuta antes que ReduceResultData. Así que cuando se ejecuta SortEqualScoresByPks, todavía no se ha obtenido ningún PK. Todo el vector primary_keys_ está lleno de valores PkType construidos por defecto".

En términos sencillos, la función de ordenación se ejecuta antes de que se hayan cargado las claves, por lo que está ordenando ceros. Claude reconoció abiertamente el fallo:

"codex-cli identificó un auténtico error crítico de corrección. Lo pasé por alto en mi primera ronda".

¿Qué combinación de modelos puede encontrar más errores?

El salto del 53% al 80% se produjo porque cinco modelos cubrieron mutuamente sus puntos ciegos. Pero no todo el mundo puede permitirse configurar y ejecutar cinco modelos a través de cinco rondas de debate para cada revisión de código.

Así que probé la versión más sencilla: si sólo puedes ejecutar dos modelos, ¿qué par te acerca más al techo multimodelo?

Utilicé las ejecuciones asistidas por contexto (R1) y conté cuántos de los 15 errores conocidos encontró cada modelo:

Claude: 7/15 (47%)
Qwen: 6/15 (40%)
Géminis: 5/15 (33%)
MiniMax: 5/15 (33%)
Codex 4/15 (27%)

Lo que importa, por tanto, no es sólo cuántos fallos encuentra cada modelo, sino qué fallos pasa por alto. De los 8 errores que Claude pasó por alto, Gemini detectó 3: una condición de carrera de concurrencia, un problema de compatibilidad con la API de almacenamiento en la nube y una falta de comprobación de permisos. En la otra dirección, Gemini no detectó la mayoría de los errores de estructuras de datos y lógica profunda, mientras que Claude detectó casi todos. Sus puntos débiles apenas se solapan, lo que les convierte en una pareja fuerte.

Emparejamiento de dos modelos	Cobertura combinada
Claude + Géminis	10/15
Claude + Qwen	9/15
Claude + Codex	8/15
Claude + MiniMax	8/15

Los cinco modelos juntos cubrieron 11 de 15, dejando 4 fallos que cada modelo pasó por alto.

Claude + Gemini, como pareja de dos modelos, ya alcanza el 91% de ese techo de cinco modelos. Para este punto de referencia, es la combinación más eficaz.

Dicho esto, Claude + Géminis no es la mejor pareja para cada tipo de fallo. Cuando desglosé los resultados por categoría de fallo, surgió una imagen más matizada:

Tipo de error	Total	Claude	Géminis	Códice	MiniMax	Qwen
Lagunas de validación	4	3	2	1	1	3
Ciclo de vida de la estructura de datos	4	3	1	1	3	1
Carreras de concurrencia	2	0	1	0	0	0
Compatibilidad	2	0	1	1	0	1
Lógica profunda	3	1	0	1	1	1
Total	15	7	5	4	5	6

El desglose por tipo de fallo revela por qué ningún emparejamiento es universalmente el mejor.

Para los fallos del ciclo de vida de las estructuras de datos, Claude y MiniMax empataron a 3/4.
En cuanto a los fallos de validación, Claude y Qwen empataron a 3/4.
En cuanto a problemas de concurrencia y compatibilidad, Claude obtuvo una puntuación de cero en ambos, y Gemini es el que cubre esas lagunas.
Ningún modelo lo cubre todo, pero Claude es el que más abarca y el que más se acerca a ser generalista.

Todos los modelos pasaron por alto cuatro errores. Uno tenía que ver con la prioridad de las reglas gramaticales ANTLR. Otro era un desajuste semántico de bloqueo de lectura/escritura entre funciones. Otro requería entender las diferencias de lógica de negocio entre los tipos de compactación. Y otro era un error de comparación silencioso en el que una variable utilizaba megabytes y otra bytes.

Lo que estos cuatro errores tienen en común es que el código es sintácticamente correcto. Los errores viven en suposiciones que el desarrollador llevaba en la cabeza, no en el diff, y ni siquiera en el código circundante. Aquí es más o menos donde la revisión de código de IA toca techo hoy en día.

Después de encontrar errores, ¿qué modelo es el mejor para corregirlos?

En la revisión de código, encontrar errores es la mitad del trabajo. La otra mitad es corregirlos. Así que después de las rondas de debate, añadí una evaluación por pares para medir la utilidad real de las sugerencias de corrección de cada modelo.

Para medir esto, añadí una ronda de evaluación por pares después del debate. Cada modelo abrió una nueva sesión y actuó como juez anónimo, puntuando las revisiones de los otros modelos. Los cinco modelos se asignaron aleatoriamente al revisor A/B/C/D/E, de modo que ningún juez sabía qué modelo había producido qué revisión. Cada juez puntuó en cuatro dimensiones, calificadas de 1 a 10: precisión, capacidad de acción, profundidad y claridad.

Modelo	Precisión	Accionabilidad	Profundidad	Claridad	En general
Qwen	8.6	8.6	8.5	8.7	8,6 (empatado 1º)
Claude	8.4	8.2	8.8	8.8	8,6 (empatado 1º)
Códice	7.7	7.6	7.1	7.8	7.5
Géminis	7.4	7.2	6.7	7.6	7.2
MiniMax	7.1	6.7	6.9	7.4	7.0

Qwen y Claude empataron en el primer puesto por un claro margen. Ambos obtuvieron sistemáticamente puntuaciones altas en las cuatro dimensiones, mientras que Codex, Géminis y MiniMax se situaron un punto o más por debajo. Cabe destacar que Géminis, que demostró ser un valioso compañero de Claude en la búsqueda de errores en el análisis por parejas, se sitúa cerca de los últimos puestos en calidad de revisión. Ser bueno detectando problemas y ser bueno explicando cómo solucionarlos son habilidades evidentemente diferentes.

Conclusión

Claude es a quien confiarías las revisiones más difíciles. Trabaja a través de cadenas de llamadas enteras, sigue rutas lógicas profundas y extrae su propio contexto sin necesidad de que le eches una cuchara. En bugs a nivel de sistema L3, nada se le acerca. A veces se muestra demasiado confiado con las matemáticas, pero cuando otro modelo demuestra que está equivocado, lo asume y explica dónde falló su razonamiento. Utilícelo para el código central y los errores que no puede permitirse pasar por alto.

Géminis viene pisando fuerte. Tiene opiniones firmes sobre el estilo del código y las normas de ingeniería, y es rápido para enmarcar los problemas estructuralmente. El inconveniente es que a menudo se queda en la superficie y no profundiza lo suficiente, por lo que obtuvo una puntuación baja en la evaluación por pares. Donde Géminis se gana realmente su puesto es como retador: su reacción obliga a otros modelos a revisar su trabajo. Combínalo con Claude para obtener la perspectiva estructural que Claude a veces se salta.

Codex apenas dice una palabra. Pero cuando lo hace, cuenta. Su porcentaje de aciertos en errores reales es alto, y tiene un don para detectar lo que todos los demás pasan por alto. En el ejemplo del PR #44474, Codex fue el modelo que detectó el problema de las claves primarias de valor cero que desencadenó toda la cadena. Piensa en él como el revisor suplementario que detecta lo que tu modelo principal pasó por alto.

Qwen es el más completo de los cinco. Su calidad de revisión igualó a la de Claude, y es especialmente bueno a la hora de reunir diferentes perspectivas en sugerencias de arreglos sobre las que realmente se puede actuar. También tuvo la tasa más alta de detección de L2 en el modo de contexto asistido, lo que lo convierte en un sólido predeterminado para las revisiones diarias de relaciones públicas. El único punto débil: en los debates largos de varias rondas, a veces pierde de vista el contexto anterior y empieza a dar respuestas incoherentes en rondas posteriores.

MiniMax fue el más flojo a la hora de encontrar errores por sí solo. Es mejor utilizarlo para completar un grupo multimodelo que como revisor independiente.

Limitaciones de este experimento

Algunas advertencias para mantener este experimento en perspectiva:

El tamaño de la muestra es pequeño. Sólo hay 15 PRs, todos del mismo proyecto Go/C++ (Milvus). Estos resultados no son generalizables a todos los lenguajes o bases de código. Considérelos orientativos, no definitivos.

Los modelos son inherentemente aleatorios. Ejecutar la misma consulta dos veces puede producir resultados diferentes. Las cifras de este artículo son una instantánea, no un valor esperado estable. Las clasificaciones de los modelos individuales deben tomarse a la ligera, aunque las tendencias generales (el debate supera a los individuos, los diferentes modelos destacan en diferentes tipos de errores) son coherentes.

Se ha modificado el orden de intervención. En el debate se utilizó el mismo orden en todas las rondas, lo que puede haber influido en la respuesta de los modelos que hablaron más tarde. En un experimento futuro se podría aleatorizar el orden en cada ronda para controlar este aspecto.

Pruébelo usted mismo

Todas las herramientas y datos de este experimento son de código abierto:

Magpie: Una herramienta de código abierto que recopila el contexto del código (cadenas de llamadas, PRs relacionados, módulos afectados) y orquesta el debate adversarial multimodelo para la revisión de código.
AI-CodeReview-Arena: El proceso de evaluación completo, configuraciones y secuencias de comandos.
Casos de prueba: Los 15 RP con errores conocidos anotados.

Todos los errores de este experimento proceden de solicitudes reales de Milvus, una base de datos vectorial de código abierto creada para aplicaciones de IA. Tenemos una comunidad bastante activa en Discord y Slack, y nos encantaría que más gente hurgara en el código. Y si acabas ejecutando esta prueba en tu propio código, ¡comparte los resultados! Tengo mucha curiosidad por saber si las tendencias se mantienen en diferentes lenguajes y proyectos.