JetBrains publicó el 30 de agosto de 2026 un análisis de la metodología para evaluar los modelos de lenguaje grandes utilizados dentro del agente de programación Junie, y abogó por superar la dependencia de un único indicador: la «tasa de resolución» (resolve rate). La empresa considera importante saber si el agente superó las pruebas de la tarea, pero esto por sí solo no revela cómo llegó al resultado, cuánto costó ni si el parche de código es limitado y mantenible.
La idea se basa en una comparación realizada por JetBrains entre Claude Opus 4.7 y Gemini 3.5 Flash con un benchmark propio. Ambos modelos resolvieron el mismo número de tareas, pero Opus necesitó una media de 184 pasos y alcanzó un coste de ejecución de 2,79 dólares, frente a 271 pasos y 1,24 dólares de Gemini. El resultado final idéntico no reflejó una diferencia clara en la trayectoria de ejecución ni en la eficiencia del uso de las herramientas.
¿Qué oculta la tasa de resolución?
Junie trabaja en el contexto de un issue y un repositorio de software, y permite al modelo inspeccionar archivos, buscar símbolos, modificar código y ejecutar comandos y pruebas. Estas acciones forman una «trayectoria de ejecución» que puede supervisarse sin afirmar que revele el razonamiento interno del modelo. A través de esta trayectoria se puede saber si el agente localizó el origen del problema antes de modificarlo, si repitió búsquedas, si puso a prueba sus hipótesis o si terminó la tarea sin verificar el parche final.
Por ello, JetBrains propone una canalización que combine cuatro perspectivas de evaluación: resultado funcional, eficiencia de ejecución, calidad del parche y calidad del proceso. Las mediciones concretas incluyen los resultados de las pruebas, el tiempo de ejecución, el número de tokens y de llamadas al modelo y a las herramientas, el coste, el número de archivos y símbolos modificados, el cambio en la complejidad, las operaciones repetidas de lectura de archivos, la repetición de comandos cuyos resultados no cambiaron y los bucles de fallo de las herramientas.
Del resultado a la trayectoria para alcanzarlo
JetBrains probó la metodología con cuatro benchmarks que incluían 523 tareas al comparar Claude Opus 4.7 y Gemini 3.5 Flash. Opus resolvió 267 tareas, con una tasa del 51,1 %, mientras que Gemini resolvió 254, con una tasa del 48,6 %. El resultado coincidió en 430 tareas: ambos modelos tuvieron éxito en 214 tareas y ambos fallaron en 216. La diferencia efectiva apareció solo en 93 tareas, lo que hace que las diferencias de comportamiento sean más importantes que la diferencia bruta en la tabla de clasificación.
En un ejemplo de una tarea en la que ambos modelos tuvieron éxito, los dos comenzaron abriendo un archivo relevante en el paso 15, llegaron a la causa raíz y realizaron una verificación exhaustiva. Sin embargo, Opus utilizó una búsqueda más específica y comenzó la ejecución después de 13 pasos; terminó la tarea en 53 pasos, con seis transiciones entre exploración, ejecución y verificación. Gemini, en cambio, inspeccionó la unidad grande de forma más amplia, realizó la primera comprobación ejecutable en el paso 30 y no ejecutó la primera modificación del código de producción hasta el paso 88. Después necesitó 192 pasos y 34 transiciones entre las fases.
Ambos modelos superaron las pruebas y modificaron el mismo archivo y los mismos símbolos que modificaba el parche de referencia. Sin embargo, Opus no tocó otros archivos, mientras que el parche de Gemini se extendió a cuatro archivos adicionales; el proceso de evaluación lo describió como amplio, con una repetición notable y algunas alucinaciones. JetBrains confirma que este ejemplo es ilustrativo y no constituye un resultado estadístico independiente.
El fallo no es un estado único
El análisis de las 216 tareas en las que ambos modelos fallaron mostró que, según la evaluación, más del 85 % de los casos incluían una identificación completa o parcial de la causa raíz. En uno de los casos, ambos agentes entendieron que superar el límite de tokens del texto provocaba el error, pero propusieron truncar el texto en lugar de dividirlo en partes correctas. En otro caso, corrigieron un parámetro de descarga en una ruta y pasaron por alto el mismo problema en una ruta relacionada.
En la práctica, estos casos son distintos del fallo del agente a la hora de encontrar el componente responsable. La causa puede ser una implementación incompleta, la modificación de la capa equivocada, el incumplimiento del contrato exacto de la tarea o la detención antes de la verificación. Por tanto, la trayectoria de ejecución puede ayudar a determinar dónde intervenir: mejorar la navegación por el repositorio, ajustar la formulación de la tarea, reforzar la finalización de las modificaciones o imponer un paso de verificación final.
Perfiles de comportamiento en lugar de una única clasificación
JetBrains concluyó que Claude Opus 4.7 mostró una mayor tendencia a identificar la causa subyacente de los defectos ambiguos y resolvió 53 tareas en las que Gemini falló. Sin embargo, 123 de sus ejecuciones no incluyeron ninguna verificación ejecutable, de las cuales 68 tareas fueron consideradas resueltas. La empresa considera que este comportamiento puede dejar sin detectar riesgos relacionados con regresiones o casos límite.
Por su parte, Gemini 3.5 Flash mostró una mayor tendencia a ejecutar una comprobación ejecutable y utilizar su resultado para mejorar la solución cuando el comportamiento esperado era claro y el componente responsable estaba relativamente bien delimitado. No obstante, presentó problemas de convergencia hacia la solución y de anclaje al repositorio: repitió búsquedas o comandos equivalentes, dedicó muchos pasos a la estructura de compilación y dependió más de interfaces, dependencias, rutas o configuraciones de pruebas no documentadas. Se clasificaron 195 de sus ejecuciones, es decir, el 37,3 %, como casos con alucinaciones moderadas o graves, frente a 130 de Opus. Además, 80 de sus ejecuciones, o el 15,3 %, mostraron una repetición considerable o grave, frente al 6,5 % de Opus.
¿Qué significa esto en la práctica?
En una comparación más amplia que incluyó GPT-5.5, Claude Opus 4.7, Gemini 3.5 Flash y Qwen 3.6 27B FP8 sobre 522 tareas comunes, GPT-5.5 logró la tasa de resolución más alta, del 51,5 %, y fue el único modelo que ejecutó una comprobación ejecutable en todos los casos. Opus encabezó los indicadores de calidad del parche, mientras que Qwen 3.6 27B FP8 resolvió el 38,9 % de las tareas con un coste de ejecución equivalente al 3 % del coste de GPT-5.5.
Estas cifras muestran que la elección del modelo depende de dónde se concentren los costes y los riesgos. El modelo más potente en el diagnóstico puede ser adecuado para un repositorio desconocido o un defecto ambiguo, mientras que un modelo más disciplinado en la verificación puede ser mejor cuando hay pruebas y retroalimentación disponibles. Un modelo de bajo coste también puede convertirse en una opción práctica cuando el coste de un intento fallido es limitado, incluso con una tasa de resolución menor. Sin embargo, esta interpretación no significa que un modelo mantenga el mismo comportamiento en todos los entornos.
JetBrains advierte contra la generalización de los perfiles de comportamiento a los propios modelos, ya que los resultados dependieron de la arquitectura específica de Junie. Además, los juicios de los evaluadores basados en modelos de lenguaje grandes no son una «verdad de referencia» y se ven muy afectados por un único parche dorado, aunque las soluciones correctas puedan utilizar archivos o capas arquitectónicas diferentes. Por ello, la tasa de resolución sigue siendo una base necesaria, pero su valor aumenta cuando se acompaña de pruebas sobre la eficiencia, la calidad de la modificación y el flujo de trabajo, en lugar de reducirse a una única clasificación general.