A-CODE-LLM Bench: Evaluación comparativa de codificación agéntica
Evaluamos los principales grandes modelos de lenguaje (LLMs) en 10 tareas de desarrollo de software utilizando una herramienta CLI agéntica. Ejecutamos aproximadamente 3.500 pasos de validación automatizados por modelo en ambas capas API y UI.
A-CODE-LLM Bench resultados
Cada alias se ejecutó 3 veces en 10 tareas (30 muestras por alias, 400 celdas por iteración en 40 alias). Consulte más detalles en la metodología.
- El Sonnet de nivel medio supera al Opus insignia. Ambas versiones de Sonnet superan en puntuación a todos los Opus, incluido Opus 4.8 (0.702). El nivel más caro de Anthropic no es su mejor codificador.
- La cima ya no es solo de Anthropic: Grok 4.5 (0.732) supera a todas las variantes de Opus. El nuevo buque insignia de OpenAI, GPT 5.6 Sol, obtiene la mejor puntuación de la compañía (0.615), aún 0.157 por debajo de Sonnet 5, y sus variantes pro de mayor cómputo en su mayoría quedan por debajo de sus propias versiones base (Sol Pro 0.543, Terra Pro 0.568; solo Luna Pro mejora, 0.603 vs 0.579).
- Los especialistas en código no ganaron el benchmark de codificación. GPT 5.3 Codex, la variante de OpenAI ajustada para código, obtiene 0.572, en la media y por debajo del GPT 5.4 Mini general de OpenAI (0.594). Kimi K2.7 Code de Moonshot es el especialista más fuerte con 0.611.
- Kimi K3, un modelo general, lidera los modelos de pesos abiertos superando al especialista en código propio de Moonshot: 0.725, sexto en general, 0.114 por encima de K2.7 Code. Su backend de 0.632 ocupa el quinto puesto, por encima de todos los alias de Opus y GPT.
- Inkling, el primer modelo de Thinking Machines, debuta con 0.575, tercero entre las entradas de pesos abiertos. Su frontend de 0.747 supera a todos los alias de GPT 5.6; el backend de 0.501 limita su clasificación.
- Ningún modelo es fiable en el backend: el techo es 0.701 (Sonnet 5), por lo que incluso el ganador falla en aproximadamente un tercio de las comprobaciones de lógica de negocio y contratos. Grok 4.5 se acerca más entre las incorporaciones de julio con 0.663. El frontend está casi resuelto entre los líderes (0.79 a 0.96), por lo que el backend es el problema pendiente y determina la clasificación. Claude Haiku 4.5 renderiza bien (0.731), pero un backend de 0.277 lo mantiene en 0.413.
- El punto débil de GPT es el frontend. GPT 5.4 y 5.5 igualan a Opus 4.8 en el backend (alrededor de 0.6) pero obtienen entre 0.53 y 0.55 en el frontend; la familia GPT 5.6 eleva eso a entre 0.63 y 0.71, aún muy por debajo de la línea de Sonnet de más de 0.91.
Comparación de costo y éxito
- Los modelos con precio de buque insignia ofrecen el peor valor. Opus 4.7 es el más caro ($3.08/celda) y obtiene 0.610, por debajo de Sonnet 4.6 a $1.33.
- El mejor cobra una prima elevada por una pequeña mejora: Sonnet 5 obtiene 0.024 más que Sonnet 4.6 por un 70 % más de costo por celda.
- Grok 4.5 es el nuevo mejor valor: 0.732, a tan solo 0.040 del ganador, a $0.46 por celda, comparado con los $2.23 de Sonnet 5. Dentro de la familia GPT 5.6, el precio no compra nada: de $0.18 (Luna) a $2.76 (Sol Pro) por celda para puntuaciones entre 0.543 y 0.615, con el alias más barato superando al más caro.
- Kimi K3 consigue su sexto puesto a un precio de gama media: $1.47 por celda, cerca de los $1.33 de Sonnet 4.6 pero 0.007 más alto en puntuación, y muy por debajo de los $2.23 de Sonnet 5. Inkling cuesta $1.64 por celda a precio de lista para 0.575, por encima de Sonnet 4.6 para una puntuación inferior.
Comparación de tiempo de finalización y éxito
- La mejor puntuación está entre las más lentas. Sonnet 5 tarda aproximadamente 30 minutos por tarea, 3 veces más que Sonnet 4.6 por 0.024 adicional; Sonnet 4.6 ofrece casi la misma puntuación en un tercio del tiempo.
- Una ejecución larga suele indicar un modelo atascado, no uno exhaustivo: los peores puntuados, ambas variantes de Qwen, GLM 5.1 base y Deepseek V4 Pro, cada uno ejecutó más de 1.700 segundos por exceso de iteraciones para puntuaciones inferiores a 0.45.
- Grok 4.3 fue rápido porque abandonaba temprano: 142 segundos y 18 llamadas a herramientas para 0.431. Grok 4.5 mantiene la velocidad y evita el abandono: aproximadamente 9 minutos por tarea, menos de un tercio del tiempo de Sonnet 5, para 0.732.
- Kimi K3 se sitúa en el extremo opuesto: puntuación de primer nivel, peor velocidad. Promedia aproximadamente 55 minutos por tarea, el más lento del grupo y aproximadamente el doble que Sonnet 5, para un sexto puesto con 0.725. Su precisión es real, pero es la forma menos práctica de llegar a la élite.
Llamadas a herramientas por tarea
- El recuento de llamadas a herramientas no mide ni la capacidad ni el esfuerzo comparable. Sonnet 5 realizó la mayor cantidad de llamadas (125) y obtuvo la puntuación más alta; MiniMax M3 realizó 108 para un 0.583 medio; Grok 4.5 alcanzó 0.732 con 40; las bajas de OpenAI, de 16 a 36, provienen de que apply_patch agrupa un archivo entero en una sola llamada. Sol Pro y Terra Pro llaman entre un cuarto y un tercio menos de herramientas que sus versiones base y puntúan menos: más razonamiento, menos ejecución. No clasifique a los agentes por volumen de herramientas.
- Dos caminos alcanzan la misma puntuación: Sonnet 5 itera intensamente (125 llamadas), Sonnet 4.6 apenas (aproximadamente 50), a 0.024 de diferencia.
LLM Rendimiento en una sola tarea exitosa
Ningún modelo superó todos los pasos del benchmark completo anterior. Para comparar costo y velocidad en igualdad de condiciones, ejecutamos una tarea de referencia simple que todos los modelos pueden completar: cuatro endpoints CRUD, validación básica, sin autenticación y sin base de datos.
Comparación de costo y líneas de código
- Las tareas simples no pueden clasificar modelos, por lo que las evaluaciones de juguete engañan. En la tarea base que todos los modelos superan, el código converge a entre 40 y 64 líneas, y el costo se reduce a centavos; las diferencias solo aparecen en trabajos largos con múltiples archivos.
- El nivel “rápido y ligero” fue el más caro aquí: Gemini 3.5 Flash base escribió 131 líneas para la tarea trivial, de dos a tres veces más que el resto, convirtiéndolo en la referencia más cara, en contra de su propio posicionamiento.
- La iteración intensa de Sonnet 5 es impulsada por la tarea, no un hábito: 9 llamadas y $0.09 aquí frente a 125 llamadas en el benchmark.
Consulte más detalles en el artículo de Precios de LLM.
Tiempo de finalización y uso de tokens
- La previsibilidad del costo divide a los modelos en dos. Los modelos adaptativos gastan solo cuando es necesario (Opus 4.8: 34s en la base, 1.072s en el benchmark); los modelos de ritmo fijo se ejecutan lentos y costosos incluso en trabajos triviales (MiniMax M3: 475 vs 1.684s).
- La longitud de salida es un rasgo fijo del modelo, con un rango de casi 10x para la misma tarea (787 a 7.508 tokens), lo que impacta directamente en el costo.
¿Qué son los sistemas LLM agénticos?
Construir software es iterativo: escribir código, ejecutarlo, leer errores, corregirlos, repetir. Los sistemas de IA agéntica permiten a los LLMs seguir este mismo ciclo. El modelo opera dentro de un entorno de desarrollo donde puede escribir archivos, ejecutar comandos, leer salidas y realizar cambios basándose en lo que ve, continuando hasta completar la tarea.
Esto es importante porque las aplicaciones reales no son archivos únicos. Tienen backends con rutas y modelos de base de datos, frontends con componentes y llamadas a API, archivos de configuración, dependencias y pruebas. Hacer que todo esto funcione en conjunto requiere pruebas y refinamiento iterativos, que es exactamente lo que permite la arquitectura agéntica.
Cómo funciona
El modelo se encuentra dentro de un arnés con acceso a una shell, al sistema de archivos y a la salida de ejecución. Cuando se le pide construir una aplicación, escribe archivos de manera incremental. Después de cada paso, el arnés muestra al modelo lo que sucedió: ¿se inició el servidor?, ¿pasaron las pruebas?, ¿el linter señaló errores? Basándose en esa retroalimentación, el modelo decide qué escribir o corregir a continuación.
Esto difiere fundamentalmente de la generación de una sola vez. En configuraciones de un solo disparo, el modelo genera todo un código base a ciegas, sin forma de verificar si funciona. En los sistemas LLM agénticos, el modelo ve las consecuencias de cada acción y corrige el rumbo. Sin embargo, esta capacidad por sí sola no es suficiente. El modelo aún necesita un razonamiento sólido para implementar correctamente la lógica de negocio, que es donde realmente surgen las diferencias de rendimiento.
Añadir como fuente preferidaMetodología del benchmark de LLM agéntico
Utilizamos Opencode como el arnés de agente para todos los modelos y los conectamos a través de OpenRouter, con dos excepciones: Claude Fable 5 se ejecutó en el CLI de Claude Code con la suscripción de Claude, e Inkling se ejecutó a través de la API compatible con OpenAI de Thinking Machines porque el modelo no está disponible en OpenRouter. Cada celda se ejecutó 3 veces para medir la varianza por celda y estabilizar la tabla de clasificación. Evaluamos su capacidad para trabajar de manera autónoma en 10 tareas de desarrollo de software (T-1 a T-10), que van desde sistemas de reservas hasta paneles interactivos. Estas tareas requieren que los agentes gestionen proyectos de múltiples archivos y entreguen productos funcionales. Los siete alias añadidos en julio de 2026 (Grok 4.5 y la familia GPT 5.6: Sol, Terra, Luna, cada uno en modo base y pro) se ejecutaron en Opencode 1.15.13 con la configuración predeterminada de API, la misma que todos los modelos aquí; las cifras de lanzamiento de OpenAI para Sol utilizan modos de mayor cómputo.1 Cuatro celdas de Sol Pro y una de Terra Pro terminaron en repetidos fallos silenciosos del flujo de API en lugar de errores del modelo y se contabilizan como fallos.
Kimi K3 e Inkling se añadieron el 18 de julio con la configuración predeterminada de API; Inkling se ejecutó con su esfuerzo de pensamiento predeterminado de 0.9. La columna de costo de Inkling utiliza los precios de lista de Thinking Machines de $3.74 por millón de tokens de entrada y $9.36 por millón de tokens de salida; el proveedor facturó aproximadamente la mitad bajo un descuento de lanzamiento por tiempo limitado.2 Ambos modelos se ejecutaron con un límite de 150 minutos por celda en lugar de los 45 minutos anteriores, porque el flujo de tokens de Kimi K3 es lo suficientemente lento como para alcanzar el límite más corto en medio de la construcción; el tiempo de finalización se informa por separado en el gráfico de tiempo. La capacidad compartida ascendente de Kimi K3 produjo frecuentes errores de límite de velocidad y tiempo de espera durante la ventana de ejecución; las celdas afectadas se volvieron a ejecutar una vez con el mismo límite, la misma política aplicada a los fallos de flujo de Sol Pro y Terra Pro mencionados anteriormente.
Ejecución y orquestación
Cada agente y tarea comienza en un entorno limpio. Las instrucciones se proporcionan como un archivo TASK.md, y utilizamos un vigilante de latido de 20 minutos para los scripts de lanzamiento. Durante esta fase, registramos los códigos de salida, el tiempo de ejecución y si se crearon los archivos de backend y frontend. También rastreamos el uso de tokens en tiempo real en las categorías de entrada, salida y caché.
Validación del backend: Desplegamos los proyectos generados en entornos aislados para probarlos contra un contrato YAML canónico. La validación cubre escenarios de camino feliz, manejo de errores (400/403/409) y consistencia de datos.
Probamos los resultados en dos modos:
El modo Adaptativo valida la funcionalidad incluso con nombres de ruta diferentes, mientras que el modo Estricto requiere una adhesión exacta al contrato.
La puntuación general del backend se calcula por celda como:
backend_overall = has_backend × (0.7 × adaptive_pass_rate + 0.3 × strict_pass_rate)
donde has_backend es 1 si la celda produjo un proyecto de backend, 0 en caso contrario. Adaptativo tiene mayor peso porque mide la corrección del comportamiento; estricto añade una penalización por desviación del contrato (rutas renombradas, códigos de estado sustituidos, campos de respuesta reestructurados).
Pruebas de UI y escenarios de usuario
Utilizamos automatización del navegador para simular flujos de usuario reales, incluyendo pre-vuelos, renderizado y autenticación. Verificamos pasos funcionales como el envío del inicio de sesión y el comportamiento posterior al inicio de sesión para garantizar que la aplicación se ejecute sin fallos.
La puntuación de UI divide ocho pasos en dos grupos. Los pasos de infraestructura (pre-vuelo del backend, renderizado del frontend, formulario de inicio de sesión visible, envío de inicio de sesión, inicio de sesión 2xx, sin fallo en tiempo de ejecución) miden si la aplicación se ejecuta en absoluto. Los pasos de comportamiento (señal de autenticación posterior al inicio de sesión, señal de comportamiento posterior al inicio de sesión) evalúan si la aplicación realiza su función prevista una vez en ejecución.
ui_score = (behavior_passed / (behavior_passed + behavior_failed)) × (infra_passed / infra_total)
Los pasos de comportamiento bloqueados se excluyen del denominador de comportamiento, por lo que una celda no es penalizada doblemente cuando la aplicación no se carga.
Cálculo de tokens
Los recuentos de tokens se extraen de la respuesta de la API del LLM. Restamos los tokens de entrada en caché del total de tokens de entrada para obtener la entrada efectiva, que refleja solo los tokens recién procesados. Los tokens de salida nunca se almacenan en caché, por lo que permanecen sin cambios.
Agregación final
La puntuación final del benchmark se calcula combinando los resultados de las fases anteriores: Final Score = (0.7 × backend_overall) + (0.3 × ui_score) Asignamos un mayor peso al backend porque los fallos de lógica a nivel de API a menudo invalidan cualquier éxito en el frontend.
Ejemplo de tarea
Tarea 6: Sistema de tickets de soporte técnico
La tarea 6 se centra en desarrollar un ecosistema complejo de soporte al cliente. El objetivo principal es construir una plataforma que medie en la comunicación entre clientes y agentes de soporte, aplicando estrictamente reglas de negocio y límites de seguridad. Esta tarea evalúa la capacidad de un agente para manejar máquinas de estado multiusuario, aislamiento de datos y comunicación en hilos dentro de un entorno de pila completa.
La tarea requería construir un sistema de mesa de ayuda con las siguientes características:
- Permisos diferenciados para Clientes (emisión/respuesta) y Agentes (gestión/resolución).
- Un flujo de trabajo de estado rígido que evita transiciones ilegales y aplica acciones específicas de cada rol.
- Aislamiento avanzado de datos donde las solicitudes de recursos no autorizados devuelven 404 en lugar de 403 para proteger la integridad del sistema.
- Un sistema de respuesta cronológica para una interacción fluida entre agente y cliente.
- Un backend con FastAPI combinado con un frontend responsivo basado en Vite (React/Vue/Svelte).
- Configuración reproducible mediante comandos de shell específicos para la activación inmediata del sistema.
Puede consultar la documentación de la Tarea 6 en GitHub.
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{kalelioglu2026,
author = {Kalelioğlu, Berk and Dilmegani, Cem},
title = {{A-CODE-LLM Bench: Evaluación comparativa de codificación agéntica}},
year = {2026},
month = aug,
howpublished = {\url{https://aimultiple.com/agentic-llm}},
note = {AIMultiple. Recuperado el 12 de Agosto de 2026}
}Resultados y marcas de tiempo de 429 puntos de datos. Descargue los datos utilizados en este artículo como un archivo ZIP que contiene 2 archivos CSV y un README.
Enlaces de referencia
El trabajo de Cem ha sido citado por publicaciones globales líderes como Business Insider, Forbes, Washington Post, firmas globales como Deloitte, HPE y ONG como el Foro Económico Mundial y organizaciones supranacionales como la Comisión Europea.
A lo largo de su carrera, Cem se ha desempeñado como consultor tecnológico, comprador de tecnología y emprendedor tecnológico. Asesoró a empresas en sus decisiones tecnológicas en McKinsey & Company y Altman Solon durante más de una década. También publicó un informe de McKinsey sobre digitalización.
Lideró la estrategia tecnológica y las adquisiciones de una empresa de telecomunicaciones reportando directamente al CEO. También lideró el crecimiento comercial de la empresa de tecnología profunda Hypatos, que alcanzó ingresos recurrentes anuales de 7 dígitos y una valoración de 9 dígitos desde 0 en 2 años. El trabajo de Cem en Hypatos fue cubierto por publicaciones tecnológicas líderes como TechCrunch y Business Insider.
Cem habla regularmente en conferencias internacionales de tecnología. Se graduó de la Universidad de Bogazici como ingeniero informático y tiene un MBA de Columbia Business School.
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.