A-CODE-LLM Bench: Benchmark de Codificación Agentiva
Evaluamos los mejores Large Language Models (LLMs) en 10 tareas de desarrollo de software utilizando una herramienta CLI agentiva. Ejecutamos ~3,500 pasos de validación automatizada por modelo en las capas de API y UI.
Resultados del A-CODE-LLM Bench
Cada alias se ejecutó 3 veces en 10 tareas (30 muestras por alias, 300 celdas por iteración). Consulte más detalles en la metodología.
- Sonnet obtiene puntuaciones más altas que Opus en codificación agentiva. Sonnet 5 (0.772) y Sonnet 4.6 (0.748) superan a todas las variantes de Opus, incluido Opus 4.8 (0.702). El mejor modelo de codificación de Anthropic es el de gama media Sonnet, no el insignia Opus.
- La ventaja de Sonnet 5 crece con la longitud de la tarea. Encabeza el benchmark de construcción de 10 tareas con el backend más alto de cualquier modelo (0.701) y 125 llamadas a herramientas, pero en la línea base trivial utiliza solo 9 llamadas. La ventaja se manifiesta en construcciones largas y autónomas, no en tareas cortas.
- Las puntuaciones de frontend se agrupan en valores altos, por lo que el backend determina la clasificación. Los ocho mejores obtienen entre 0.79 y 0.96 en frontend. Claude Haiku 4.5 tiene un frontend funcional (0.731) pero un backend de 0.277, lo que lo limita a 0.413; GPT 5.5 thinking tiene un backend sólido (0.620) pero un frontend de 0.542.
- El nivel del modelo no predice la capacidad de codificación. El Sonnet de gama media supera al insignia Opus en todas las variantes, por lo que ajustar un modelo para trabajo agentivo importa más que su tamaño o nivel de precio.
- La lógica de backend es la parte difícil para los LLMs actuales, no la UI. Entre los líderes, el frontend está casi resuelto (los ocho mejores entre 0.79 y 0.96) y la clasificación se decide casi enteramente por el backend, donde las puntuaciones se distribuyen desde 0.70 hasta 0.23.
Comparación de coste y éxito
- El coste y la puntuación no están relacionados. El modelo más caro, Opus 4.7 a $3.08 por celda, obtiene 0.610, por debajo de Sonnet 4.6 a $1.33. Gastar más no aumenta la puntuación.
- Sonnet 4.6 cuesta menos que Sonnet 5 por casi la misma puntuación: 0.748 a $1.33 frente a 0.772 a $2.23. Los 0.024 adicionales cuestan $0.90 más por celda.
- Todas las variantes de Opus cuestan más que Sonnet por una puntuación inferior o igual.
- Mejor relación calidad-precio: Kimi K2.7 Code es el modelo más económico por encima de 0.60 a $0.70. Gemini 3.5 Flash thinking obtiene 0.625 a $1.30, igualando el precio de Sonnet y superando a todos los Opus.
- El precio no es una señal de calidad para la codificación agentiva. El coste refleja el posicionamiento del proveedor, no la puntuación que un modelo obtiene en este benchmark, por lo que un precio más alto no indica un mejor modelo agentivo.
Comparación de tiempo de finalización y éxito
- El tiempo de finalización y la puntuación no están relacionados. El modelo más rápido, Grok 4.3 a 142 segundos, obtiene 0.431; el más lento, Qwen 3.6 Plus a 1,948 segundos, obtiene 0.333.
- Sonnet 5 es el más lento de los seis mejores. A 1,763 segundos tarda aproximadamente 3x más que Sonnet 4.6 (612 segundos) por 0.024 más.
- Sonnet 4.6 es el más rápido entre los de alta puntuación, alcanzando 0.748 en un tercio del tiempo de Sonnet 5.
- Las ejecuciones de más de 1,600 segundos se debieron a sobre-iteración, no a tareas más difíciles: MiniMax M3, ambas variantes de Qwen, GLM 5.1 base, y Deepseek V4 Pro obtuvieron todos por debajo de 0.55.
- Dos causas no relacionadas impulsan el tiempo de ejecución. Dentro de un mismo modelo, ejecuciones más largas pueden significar iteración más profunda que mejora la puntuación (Sonnet 5). Entre modelos, las ejecuciones más largas provienen de sobre-iteración improductiva (todos los modelos por encima de 1,600 segundos obtuvieron menos de 0.55). El tiempo por sí solo no puede distinguir ambos casos.
Llamadas a herramientas por tarea
- El recuento de llamadas a herramientas es una huella conductual, no una medida de capacidad, y no es comparable entre entornos de ejecución. La función
apply_patchde OpenAI colapsa una edición de archivo completo en una sola llamada, por lo que sus recuentos bajos reflejan el diseño de la herramienta, no menos trabajo. - El recuento de llamadas no predice la puntuación. Los recuentos van de 18 (Grok 4.3) a 125 (Sonnet 5), sin ningún patrón entre recuento y puntuación.
- Sonnet 5 realiza el mayor número de llamadas de cualquier modelo (125) y obtiene la puntuación más alta; Sonnet 4.6 alcanza casi la misma puntuación con aproximadamente 50. Ambos funcionan, en extremos opuestos del rango.
- MiniMax M3 realizó 108 llamadas para un 0.583 de mitad de tabla, por lo que un recuento alto por sí solo no ayuda.
Rendimiento de los LLM en una sola tarea exitosa
Ningún modelo superó cada paso del benchmark completo anterior. Para comparar coste y velocidad en igualdad de condiciones, ejecutamos una tarea de línea base simple que todo 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 triviales no separan a los modelos, razón principal por la que existe el benchmark completo. En la línea base, el coste, la longitud del código y la tasa de aprobación convergen: todos los modelos la completan, las líneas se agrupan entre 40 y 64, y el coste baja a céntimos. Las diferencias entre modelos aparecen solo en trabajo agentivo largo de múltiples archivos.
- La longitud del código no es un rasgo del modelo en tareas simples (40 a 64 líneas), excepto por un sobre-generador, Gemini 3.5 Flash base, que produjo 131 líneas y se convirtió en la línea base más cara.
- Sonnet 5 ajusta el esfuerzo a la tarea: 9 llamadas, 46 líneas, $0.09 en la línea base frente a 125 llamadas en el benchmark completo. Sonnet 4.6 ejecutó la línea base a aproximadamente el 15% de su coste por celda del benchmark completo ($0.20 base, $0.15 thinking). Opus 4.8 también redujo a $0.16 y 6 llamadas. Consulte el artículo de Precios de LLM para las tarifas por token.
Tiempo de finalización y uso de tokens
- Los modelos se dividen en dos tipos de ritmo. Los modelos adaptativos escalan el esfuerzo según la dificultad (Opus 4.8: 34 segundos en la línea base, 1,072 en el benchmark); los modelos de ritmo fijo se ejecutan lento sin importar la dificultad (MiniMax M3: 475 frente a 1,684).
- La salida para la misma tarea varía 8x, desde 787 tokens (Qwen 3.6 Plus thinking) hasta 6,643 (GPT 5.4 Mini), por lo que la verbosidad es una disposición estable del modelo, no un efecto de la tarea.
¿Qué son los sistemas agentivos de LLM?
Construir software es iterativo: escribir código, ejecutarlo, leer errores, corregirlos, repetir. Los sistemas de IA Agentiva 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 hacer cambios basándose en lo que ve, continuando hasta que la tarea esté completa.
Esto importa 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 iterativas y refinamiento, que es exactamente lo que la arquitectura agentiva permite.
Añadir como fuente preferidaCómo funciona
El modelo se sitúa dentro de un entorno con acceso a una terminal, sistema de archivos y salida de ejecución. Cuando se le pide construir una aplicación, escribe archivos de forma incremental. Después de cada paso, el entorno muestra al modelo lo que ocurrió: ¿se inició el servidor, pasaron las pruebas, detectó errores el linter? Basándose en esa retroalimentación, el modelo decide qué escribir o corregir a continuación.
Esto difiere fundamentalmente de la generación en un solo paso. En configuraciones de una sola pasada, el modelo genera una base de código completa a ciegas, sin forma de verificar si funciona. En los sistemas agentivos de LLM, 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 la lógica de negocio correctamente, que es donde realmente emergen las diferencias de rendimiento.
Metodología del benchmark agentivo de LLM
Usamos Opencode como entorno 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 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 requieren que los agentes gestionen proyectos de múltiples archivos y entreguen productos funcionales.
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 watchdog 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 adherencia exacta al contrato.
La puntuación global 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. Adaptativo tiene mayor peso porque mide la corrección conductual; 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
Usamos automatización de navegador para simular flujos de usuario reales, incluyendo 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 asegurar que la aplicación se ejecuta sin fallos.
La puntuación de UI 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 en absoluto. 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 recibe doble penalización cuando la aplicación no logra cargarse.
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é de los tokens totales de entrada para obtener la entrada efectiva, que refleja solo los tokens recién procesados. Los tokens de salida nunca se cachean, 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 peso mayor 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 helpdesk
La Tarea 6 se centra en desarrollar un ecosistema complejo de soporte 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 helpdesk 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 impide transiciones ilegales y aplica acciones específicas por 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 respuestas cronológicas para una interacción fluida entre agente y cliente.
- Un backend 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{kaleliolu2026,
author = {Kalelioğlu, Berk and Dilmegani, Cem},
title = {{A-CODE-LLM Bench: Benchmark de Codificación Agentiva}},
year = {2026},
month = jul,
howpublished = {\url{https://aimultiple.com/agentic-llm}},
note = {AIMultiple. Recuperado el 2 de Julio de 2026}
}Resultados y marcas de tiempo de 341 puntos de datos. Descargue los datos utilizados en este artículo como un archivo ZIP que contiene 2 archivos CSV y un README.
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.