A-CODE-LLM Bench: Evaluación Comparativa de Codificación Agentic
Evaluamos los mejores grandes modelos de lenguaje (LLMs) en 10 tareas de desarrollo de software usando una herramienta CLI agentic. Realizamos ~3,500 pasos de validación automatizados por modelo, tanto en la capa de API como en la interfaz de usuario.
Resultados de A-CODE-LLM Bench
Cada alias se ejecutó 3 veces en 10 tareas (30 muestras por alias, 380 celdas por iteración en 38 alias). Ver más detalles en metodología.
- Sonnet de nivel medio supera al buque insignia Opus. Ambas versiones de Sonnet superan a cada Opus, incluido Opus 4.8 (0.702). El nivel más caro de Anthropic no es su mejor codificador.
- El tope ya no es exclusivo de Anthropic: Grok 4.5 (0.732) supera a todas las variantes de Opus. El nuevo buque insignia de OpenAI, GPT 5.6 Sol, logra 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 bases (Sol Pro 0.543, Terra Pro 0.568; solo Luna Pro mejora, 0.603 vs 0.579).
- Los especialistas en código no ganaron la evaluación. GPT 5.3 Codex, la variante afinada para código de OpenAI, obtiene 0.572, en la media y por debajo del propio GPT general de OpenAI, 5.4 Mini (0.594). El especialista más fuerte es Kimi K2.7 Code de Moonshot, con 0.611.
- Ningún modelo es fiable en backend: el techo es 0.701 (Sonnet 5), así que incluso el ganador falla aproximadamente un tercio de las verificaciones de lógica de negocio y contratos. Grok 4.5 es el que más se acerca entre las adiciones 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 abierto, y es lo que define el ranking. Claude Haiku 4.5 renderiza bien (0.731), pero un backend de 0.277 lo limita a 0.413.
- El punto débil de GPT es el frontend. GPT 5.4 y 5.5 igualan a Opus 4.8 en backend (aproximadamente 0.6), pero puntúan 0.53 a 0.55 en frontend; la familia GPT 5.6 eleva eso a 0.63 a 0.71, todavía muy por debajo de la línea Sonnet, que supera 0.91.
Comparación de coste y éxito
- Los modelos con precio de buque insignia son el peor valor. Opus 4.7 es el más caro ($3.08/celda) y puntúa 0.610, por debajo de Sonnet 4.6 a $1.33.
- Los mejores cobran una prima elevada por poca ganancia: Sonnet 5 supera a Sonnet 4.6 por 0.024 con un coste por celda un 70% mayor.
- Grok 4.5 es la nueva mejor opción en relación calidad-precio: 0.732, a 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: desde $0.18 (Luna) hasta $2.76 (Sol Pro) por celda, para puntuaciones entre 0.543 y 0.615, y el alias más barato supera al más caro.
Comparación de tiempo de finalización y éxito
- La puntuación más alta está entre las más lentas. Sonnet 5 tarda unos 30 minutos por tarea, 3x Sonnet 4.6 por 0.024 más; 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 concienzudo: los peores puntuadores, ambas variantes de Qwen, GLM 5.1 base y Deepseek V4 Pro, cada uno se ejecutó más de 1,700 segundos por sobreiteración, para puntuaciones inferiores a 0.45.
- Grok 4.3 fue rápido porque abandonó pronto: 142 segundos y 18 llamadas a herramientas para 0.431. Grok 4.5 mantiene la velocidad y deja de abandonar: alrededor de 9 minutos por tarea, menos de un tercio del tiempo de Sonnet 5, para 0.732.
Llamadas a herramientas por tarea
- El recuento de llamadas a herramientas no mide ni la capacidad ni el esfuerzo que se puede comparar. Sonnet 5 hizo la mayor cantidad de llamadas (125) y obtuvo la puntuación más alta; MiniMax M3 hizo 108 para una media de 0.583; Grok 4.5 alcanzó 0.732 con 40; los bajos números de OpenAI (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 bases 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 mucho (125 llamadas), Sonnet 4.6 apenas (unas 50), 0.024 de diferencia.
Rendimiento de LLM en una única tarea exitosa
Ningún modelo pasó todos los pasos de la evaluación completa anterior. Para comparar coste y velocidad en igualdad de condiciones, ejecutamos una tarea base simple que cualquier modelo puede completar: cuatro endpoints CRUD, validación básica, sin autenticación y sin base de datos.
Comparación de coste y líneas de código
- Las tareas simples no pueden clasificar modelos, por lo que las evaluaciones de juguete engañan. En la línea base, todos los modelos pasan, el código converge a 40 a 64 líneas, y el coste baja a céntimos; las diferencias aparecen solo en trabajos largos y 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, dos o tres veces más que los demás, convirtiéndose en la línea base más cara, en contra de su propio posicionamiento.
- La fuerte iteración de Sonnet 5 depende de la tarea, no es un hábito: 9 llamadas y $0.09 aquí, frente a 125 llamadas en la evaluación comparativa.
Ver más detalles en el artículo LLM Pricing.
Tiempo de finalización y uso de tokens
- La predictibilidad de costes divide a los modelos en dos. Los modelos adaptativos gastan solo cuando es necesario (Opus 4.8: 34s en línea base, 1,072s en la evaluación); 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 alimenta directamente el coste.
¿Qué son los sistemas LLM agentic?
Construir software es iterativo: escribir código, ejecutarlo, leer errores, corregirlos, repetir. Los sistemas de IA agentic 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 observa, continuando hasta que la tarea esté completa.
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 APIs, archivos de configuración, dependencias y pruebas. Hacer que todo esto funcione junto requiere pruebas y refinamiento iterativos, que es exactamente lo que permite la arquitectura agentic.
Añadir como fuente preferidaCómo funciona
El modelo se sitúa dentro de un arnés con acceso a una terminal, sistema de archivos y salida de ejecución. Cuando se le pide que construya una aplicación, escribe los archivos incrementalmente. 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 el código a ciegas, sin forma de verificar si funciona. En los sistemas LLM agentic, 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.
Metodología de la evaluación comparativa de LLM agentic
Usamos Opencode como arnés agente para todos los modelos y los conectamos a través de OpenRouter, con una excepción: Claude Fable 5 se ejecutó en la CLI de Claude Code con la suscripción de Claude. 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 forma 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 exigen 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, igual que todos los demás modelos aquí; los números de lanzamiento de OpenAI para Sol usan modos de mayor cómputo.1 Cuatro celdas de Sol Pro y una de Terra Pro terminaron en fallos repetidos de transmisión silenciosa de la API, en lugar de errores del modelo, y se puntúan como fallos.
Ejecución y orquestación
Cada agente y tarea comienza en un entorno limpio. Las instrucciones se proporcionan como un archivo TASK.md, y usamos 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 adherencia 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 backend, 0 en caso contrario. El adaptativo tiene mayor peso porque mide la corrección del comportamiento; el estricto añade una penalización por desviación del contrato (rutas renombradas, códigos de estado sustituidos, campos de respuesta reestructurados).
Pruebas de interfaz de usuario y escenarios de usuario
Usamos automatización del navegador para simular flujos reales de usuario, incluidos preflights, renderizado y autenticación. Verificamos pasos funcionales como el envío de 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 la interfaz de usuario divide ocho pasos en dos grupos. Los pasos de infraestructura (preflight del backend, renderizado del frontend, formulario de inicio de sesión visible, envío de inicio de sesión, login 2xx, sin fallo en tiempo de ejecución) miden si la aplicación se ejecuta. Los pasos de comportamiento (señal de autenticación post-login, señal de comportamiento post-login) 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 LLM API. Restamos los tokens de entrada en caché de los tokens de entrada totales 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 de la evaluación 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 lógicos a nivel de API a menudo invalidan cualquier éxito en el frontend.
Ejemplo de tarea
Tarea 6: Sistema de tickets de soporte
La tarea 6 se centra en desarrollar un ecosistema complejo de atención al cliente. El objetivo principal es construir una plataforma que medie 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 full-stack.
La tarea requería construir un sistema de soporte con las siguientes características:
- Permisos distintos para Clientes (emisión/respuesta) y Agentes (gestión/resolución).
- Un flujo de trabajo de estado rígido que impide 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 FastAPI combinado con un frontend responsive potenciado por 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{kaleliolu2026,
author = {Kalelioğlu, Berk and Dilmegani, Cem},
title = {{A-CODE-LLM Bench: Evaluación Comparativa de Codificación Agentic}},
year = {2026},
month = jul,
howpublished = {\url{https://aimultiple.com/agentic-llm}},
note = {AIMultiple. Recuperado el 10 de Julio de 2026}
}Resultados y marcas de tiempo de 418 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
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.