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 llamó a 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 tuvo 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ó diferencias claras en la trayectoria de ejecución ni en la eficiencia del uso de 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. Entre las mediciones concretas se 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 habían cambiado y los bucles de fallos 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ó únicamente en 93 tareas, lo que hace que las diferencias de comportamiento sean más importantes que la diferencia bruta en la tabla de posiciones.
En un ejemplo de una tarea que ambos modelos resolvieron, los dos empezaron abriendo un archivo relacionado 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, examinó 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 fases.
Ambos modelos superaron las pruebas y modificaron el mismo archivo y los mismos símbolos que había modificado el parche de referencia. Sin embargo, Opus no tocó otros archivos, mientras que el parche de Gemini se extendió a cuatro archivos adicionales y el proceso de evaluación lo describió como amplio, con una repetición apreciable y cierta alucinación. JetBrains subraya que este ejemplo es ilustrativo y no constituye un resultado estadístico independiente.
El fracaso no es un estado único
El análisis de las 216 tareas en las que ambos modelos fallaron mostró que más del 85 % de los casos incluían, según la evaluación, 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 caracteres 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 fracaso 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 redacció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 un único ranking
JetBrains concluyó que Claude Opus 4.7 mostraba una mayor tendencia a identificar la causa subyacente de defectos ambiguos, y resolvió 53 tareas en las que Gemini había fallado. 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 riesgos no detectados relacionados con regresiones o casos extremos.
Por el contrario, 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 para converger hacia la solución y para apoyarse en el 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 prueba no documentadas. Se clasificaron 195 de sus ejecuciones, es decir, el 37,3 %, como casos con alucinación moderada o grave, frente a 130 de Opus. Además, 80 de sus ejecuciones, o el 15,3 %, mostraron una repetición alta 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 en 522 tareas compartidas, GPT-5.5 alcanzó 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 lideró 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 el coste y los riesgos. El modelo más fuerte en 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 lectura no significa que un modelo mantenga el mismo comportamiento en todos los entornos.
JetBrains advierte que no se deben generalizar los perfiles de comportamiento a los propios modelos, ya que los resultados dependieron de la arquitectura específica de Junie. Además, las evaluaciones de los jueces basados en modelos de lenguaje grandes no son una «verdad de referencia» y se ven muy afectadas por un único parche dorado, aunque las soluciones correctas pueden 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 evidencias sobre la eficiencia, la calidad de la modificación y el flujo de trabajo, en lugar de reducirla a un único ranking general.