AIM-Code Bench: benchmark de codificación agéntica
Evaluar los LLMs sin sus arneses de agentes de codificación no refleja del todo cómo se usan en la práctica. El desarrollo real también implica ampliar trabajo existente, hacerse cargo de código desconocido y dejar implementaciones sobre las que otros puedan construir. Presentamos AIM-Code Bench para evaluar modelos junto con sus arneses de agentes de codificación en tareas de software en evolución. Más allá de la corrección, el benchmark mide el rendimiento en tiempo de ejecución, la adaptación a requisitos cambiantes y los resultados cuando los agentes construyen sobre el código de otros.
Resultados
Fable 5.1 tuvo la latencia observada más baja en las etapas 1 y 2; Opus 5 lideró las etapas 3 y 4.
Modelo | Producto de codificación | S1: inicial | S2: capacidad | S3: expiración | S4: HTTP |
|---|---|---|---|---|---|
Fable 5.1 | Claude Code | 6.523 | 7.293 | 11.079 | 2.897 |
Opus 5 | Claude Code | 6.732 | 7.491 | 9.557 | 2.648 |
Opus 5.5 | Claude Code | 6.703 | 7.464 | 10.502 | 2.799 |
Sonnet 5 | Claude Code | 11.156 | 12.011 | 14.188 | 3.512 |
GPT-6 Astra | Codex | 10.957 | 12.114 | 13.214 | 3.292 |
GPT-5.6 Sol | Codex | 11.208 | 11.709 | 13.390 | 3.296 |
GPT-5.6 Luna | Codex | 10.841 | 12.091 | 13.995 | 3.483 |
SWE-2 | Devin CLI | 9.192 | 9.702 | 12.484 | 3.147 |
Grok 4.6 | Grok Build | 7.395 | 8.149 | 12.798 | 3.348 |
GLM 5.3 | OpenCode | 11.006 | 11.730 | 12.915 | 3.445 |
La tabla muestra la latencia p95 (el percentil 95) en milisegundos; cuanto más baja, mejor. Cada valor es la mediana de diez mediciones de reproducción del programa guardado. Las clasificaciones usan precisión completa dentro de cada etapa. Las mismas mediciones de la etapa 4 sirven como controles de código propio en la comparación de traspaso. Las clasificaciones numéricas cercanas no indican necesariamente un rendimiento distinguible.
Parte 1: desarrollo y mejora de sus propias implementaciones
Cada agente conservó su código y su conversación a lo largo de las etapas. Actualizábamos la especificación de la tarea a medida que llegaban nuevos requisitos y le dábamos hasta 20 minutos para cada etapa. Las instrucciones describían trabajo de desarrollo ordinario y pedían a los agentes buscar el mejor rendimiento que pudieran lograr sin dejar de preservar el comportamiento requerido.
El experimento cubrió trece configuraciones de modelo y producto: cuatro en Claude Code, tres en Codex, cuatro en OpenCode, una en Grok Build y una en Devin CLI. El esfuerzo fue medio donde se admitía, alto para Kimi K3 y GLM 5.3, y el valor predeterminado del proveedor para MiniMax M3. Por lo tanto, cada resultado pertenece al modelo y al producto de codificación en conjunto.
Intentamos reflejar lo más fielmente posible cómo las personas usan realmente los productos de codificación con IA en escenarios de la vida real. Muchas personas usan modelos dentro de sus propios arneses; por lo tanto, aunque utilizamos los modelos disponibles dentro de sus respectivos arneses, usamos modelos de pesos abiertos a través de opencode.
Cuatro etapas del proyecto
Las etapas 1 a 3 usaron 5.000 operaciones por lote. La etapa 4 usó solicitudes HTTP independientes con 1.000 operaciones cada una, con una CPU y 128 MiB de memoria asignada al servicio candidato.
La latencia de lote medida de MiniMax M3 pasó de 37.833 ms en la etapa inicial a 12.254 ms en la etapa de capacidad. Se trata de una reducción observada del 67,6 % a medida que la implementación cambió y el desalojo se convirtió en un requisito. Su implementación HTTP original de la etapa 4 quedó más tarde en el lugar 4, con 3.009 ms.
La latencia de lote medida de Qwen 3.8 Max pasó de 11.638 a 8.023 ms entre las dos primeras etapas, una reducción observada del 31,1 %. Su resultado de la etapa 3 quedó en el lugar 4. Estas trayectorias muestran por qué un único resultado inicial omite cambios que aparecen cuando un agente continúa desarrollando un proyecto.
Estos porcentajes describen las trayectorias registradas, no aceleraciones de optimización controladas. Cada etapa cambia el comportamiento o la carga de trabajo requeridos. En particular, la latencia de la etapa 4 no puede restarse de la latencia de la etapa 3: la interfaz y las operaciones por solicitud son diferentes. Una afirmación directa de optimización antes/después requeriría reproducir ambas versiones bajo la misma carga de trabajo aplicable.
¿Cuánto código cambió a lo largo del proceso?
Las cuatro etapas abarcan 52 diferencias verificadas de la etapa original en las trece configuraciones. La etapa 4 ilustra la variación en el tamaño de la implementación y el estilo de edición:
Estos recuentos incluyen pruebas y herramientas de código fuente escritas por el agente, comentarios y líneas en blanco; las actualizaciones suministradas de tareas/pruebas y los diagnósticos JSON se excluyen. Miden la diferencia final con respecto a la instantánea inicial de cada etapa. Los cambios más grandes pueden incluir pruebas u optimizaciones útiles; los cambios más pequeños no son automáticamente mejores. El informe de diferencias vinculado contiene los cambios de código fuente por etapa.
Parte 2: hacerse cargo de la implementación de otro agente
Después de medir las trayectorias originales, planteamos dos preguntas diferentes: ¿qué código ofrece a otros agentes un punto de partida útil y qué agente rinde mejor al ampliar el código ajeno?
Partimos de las implementaciones guardadas de la etapa 3 y pedimos a los receptores que realizaran la etapa 4. Cada una de las trece configuraciones recibió el código de las otras doce configuraciones, lo que dio 156 pares ordenados donante–receptor. No hubo nuevas autotransferencias. Cada receptor comenzó una sesión aislada nueva con el código del donante y los mismos requisitos de la etapa 4; no podía ver el arnés ni las sesiones de otros agentes.
Las entregas originales de la etapa 4 sirven como controles de código propio, usando las mismas mediciones que la Parte 1. Esos controles se habían desarrollado con el historial de conversación original, mientras que los traspasos comenzaron desde cero. Por lo tanto, la comparación combina efectos del código inicial y de la conversación. Esta transición pide a los sucesores ampliar una caché existente hasta convertirla en un servicio HTTP y, al mismo tiempo, optimizar la latencia de las solicitudes.
Vista A: beneficio proporcionado por el código de un donante
Para cada par, comparamos la latencia HTTP del sucesor con la latencia original de la etapa 4 de ese mismo sucesor:
successor benefit = (recipient own latency − inherited-code latency) / recipient own latency
La puntuación de un donante es la mediana de estos doce beneficios porcentuales. Un valor positivo significa que sus sucesores lograron normalmente una latencia más baja que sus propias continuaciones originales. Esta es una visión basada en el rendimiento de cuán útil fue una implementación de partida; no mide directamente la calidad de la documentación ni la facilidad de comprensión.
Opus 5 proporcionó el mayor beneficio medio del sucesor, con +17,30 %, seguido de Opus 5.5 con +15,70 % y Fable 5.1 con +11,34 %. Esos resultados pueden reflejar tanto el rendimiento de la implementación heredada como la facilidad con la que los sucesores pudieron ampliarla. Los porcentajes normalizan la escala, pero no eliminan las diferencias de calidad de partida ni de margen de optimización.
Vista B: rendimiento como sucesor
Para cada donante, calculamos la latencia mediana lograda por sus doce receptores. A continuación, cada receptor de ese donante se compara con esta referencia compartida:
successor advantage = (same-donor median latency − recipient latency) / same-donor median latency
La puntuación del receptor es su ventaja mediana entre doce donantes. Un valor positivo significa que normalmente fue más rápido que el receptor mediano del mismo código de partida. Esto evita recompensar a un receptor simplemente porque su propia implementación original era lenta.
GPT-6 Astra lideró este resumen exploratorio de sucesores con +2,68 %, seguido de Opus 5 con +2,33 % y Grok 4.6 con +0,88 %. La ventaja de Astra sobre Opus 5 no fue distinguible dentro de la incertidumbre medida. Ser el donante más fuerte y ser el sucesor más fuerte son resultados diferentes en este experimento.
¿Construyeron los sucesores sobre el código fuente heredado?
Informamos del cambio de código fuente por separado del rendimiento: (added lines + deleted lines) / inherited source lines. También contamos los traspasos que eliminan más del 50 % del código fuente heredado. Se trata de una tasa de eliminación grande, no de una prueba de reescritura desde cero: los renombrados, el reformateo y la eliminación de código auxiliar pueden superar el umbral.
Ninguno de los sucesores seleccionados eliminó más de la mitad del código fuente heredado total de GPT-6 Astra, Claude Fable 5.1, Claude Opus 5, Claude Opus 5.5 ni de Qwen 3.8 Max. Los doce superaron ese umbral en el caso de Kimi K3, GPT-5.6 Luna, MiniMax M3 y Claude Sonnet 5. Se trata de observaciones sobre cambios de líneas físicas, no de una clasificación de mantenibilidad. Los programas donantes contenían solo de 75 a 668 líneas de código fuente incluyendo código auxiliar, y la decisión de incluir pruebas/herramientas afecta a los porcentajes de eliminación.
Método de medición, reintentos y alcance
Cada puntuación de rendimiento indicada utiliza diez reproducciones del mismo programa guardado. Las etapas 1 a 3 usaron 40 lotes medidos por reproducción. La temporización de la etapa 4 y de los traspasos utilizó 1.200 solicitudes HTTP por reproducción a 20 solicitudes por segundo durante 60 segundos, con una CPU, 128 MiB de memoria y un límite de 64 procesos/hilos para cada candidato.
Medimos los programas de forma serial en un servidor Linux Intel i7-7700 dedicado. El controlador y el candidato se ejecutaron en núcleos físicos separados con hilos hermanos sin usar, una política de CPU fija de 2 GHz y turbo desactivado.
Las 156 entregas de traspaso seleccionadas y las 52 compilaciones de la etapa original superaron todas las reproducciones. La evaluación completa contiene 2.080 mediciones, incluidos los trece controles de código propio. Comprobamos las respuestas sin procesar, recalculamos la latencia p95, verificamos los hashes de código fuente y los límites de recursos, y conservamos cada medición programada.
Calculamos intervalos del 95 % a partir de 10.000 remuestreos de las diez rondas de medición, usando las mismas rondas muestreadas en todos los programas. Una comparación queda sin resolver cuando su intervalo de diferencia incluye el cero. Estos intervalos exploratorios no están ajustados para comparaciones múltiples. Los recuentos de sucesores más rápidos comparan puntuaciones medidas y no implican diferencias estadísticamente distinguibles.
En 13 compilaciones originales de la etapa 4 y 156 traspasos, las 2.028.000 respuestas HTTP medidas fueron correctas. El retraso máximo de despacho fue de 0.607 ms. Todas las reproducciones cumplieron los límites del controlador de un retraso de despacho p95 inferior a 0.05 ms y un retraso máximo inferior a 1 ms. El retraso sigue incluido en la latencia.
La selección publicada incluye intentos adicionales. GLM 5.3 y Qwen 3.8 Max utilizan sus segundas trayectorias originales completas tras fallos iniciales en la etapa 3. Se reutilizaron cuatro compilaciones piloto de traspaso completadas, quince pares de Claude recibieron intentos de recuperación de infraestructura y siete traspasos fallidos recibieron un intento nuevo de codificación de sus donantes originales. Los siete reintentos de codificación superaron la prueba. Se seleccionaron intentos nuevos independientemente del resultado; los intentos anteriores permanecen archivados. Estos resultados comparan compilaciones seleccionadas, no la fiabilidad del primer intento.
El evaluador distingue los fallos de los candidatos de las mediciones inválidas por infraestructura. La corrección HTTP requiere al menos el 99 % de las solicitudes atendidas, calentamientos correctos y ninguna respuesta incorrecta. Cada compilación clasificada debe tener diez reproducciones válidas. No se modificó código durante la evaluación de tiempos.
Se trata de un único proyecto y una única trayectoria seleccionada por configuración. Las cuatro etapas están relacionadas y los 156 pares de traspaso comparten donantes y receptores. Los intervalos describen la variación de reproducción en este host; no cubren otras tareas, máquinas ni ejecuciones de codificación independientes. Los hallazgos describen estos artefactos bajo estas cargas de trabajo, en lugar de una clasificación general de la capacidad de codificación, la comprensión del código o la mantenibilidad en producción.
Añadir como fuente preferida¿Qué sigue?
Los próximos experimentos añadirán más proyectos y trayectorias de codificación independientes, aumentarán la dificultad de las etapas que alcancen el techo de carga ofrecida y medirán versiones aplicables de antes/después bajo la misma carga de trabajo. Los controles de autocontinuación en una sesión nueva ayudarían a separar los efectos del historial de conversación del hecho de comenzar con el código de otro agente.
Cita este benchmark
Elige el formato que se ajuste al lugar donde vas a publicar. Pegar la versión con enlace en tu CMS conserva el enlace de retroceso.
@misc{alper2026,
author = {Alper, Şevval},
title = {{AIM-Code Bench: benchmark de codificación agéntica}},
year = {2026},
month = sep,
howpublished = {\url{https://aimultiple.com/agentic-llm}},
note = {AIMultiple. Recuperado el 22 de septiembre de 2026}
}Resultados y marcas de tiempo de 485 puntos de datos. Descargue los datos resumidos que se muestran en los gráficos y las tablas de este artículo como un archivo ZIP que contiene 7 archivos CSV y un README.
¿Quieres los datos granulares que hay detrás? Únete a Premium
Registro de cambios
13 actualizacionesAñadidos los resultados de los modelos Kimi K3 e Inkling a la clasificación.
Se añadieron Kimi K3 e Inkling al benchmark de codificación agéntica.
Se añadieron Grok 4.5 y la familia de modelos GPT 5.6 a la comparativa del benchmark de codificación.
Se añadieron siete modelos al benchmark: Grok 4.5 y la familia GPT-5.6 (Sol, Terra, Luna).
Añadida comparación de los modelos especializados en código GPT 5.3 Codex y Kimi K2.7 Code a la sección de puntuación de backend.
Se añadió Claude Sonnet 5 a la clasificación del benchmark con una puntuación general de 0,772.
Añadidos Kimi K2.7 Code y Claude Fable 5 a los resultados del benchmark y las secciones de comparación de costes.
Actualizada la metodología del entorno: Claude Fable 5 se ejecutó en la suscripción de Claude Code CLI en lugar de Opencode vía OpenRouter.
Añadidos Claude Opus 4.8, Gemini 3.5 Flash y MiniMax M3 a la tabla de resultados y las comparaciones de costos.
Reemplazada la lista de modelos evaluados y todos los resultados de éxito, costo y latencia con nuevos valores.
Se reemplazó Aider por opencode como entorno de agentes y se añadieron tres ejecuciones por celda para medir la varianza.
Reemplazado Gemini 3 Pro por Gemini 3.1 Pro Preview en el resumen de resultados del benchmark.
Se añadió Gemini 3.1 Pro Preview a los resultados del benchmark Agentic LLM.
Şevval se centra en herramientas de codificación con IA, agentes de IA y tecnologías cuánticas.
Sé el primero en comentar
Tu dirección de correo electrónico no será publicada. Todos los campos son obligatorios. Los comentarios se dejan en su idioma original.