Un benchmark del mundo real descubre que los agentes de programación aún requieren revisión humana en la mayoría de las tareas

Los agentes de programación con IA pueden completar gran parte de un cambio de software y aun así no entregar un resultado plenamente funcional, según un nuevo benchmark basado en solicitudes reales de usuarios. La prueba descubrió que incluso el sistema más potente completó todas las partes requeridas de una tarea en solo el 26,4 % de los casos, lo que significa que la revisión humana siguió siendo necesaria en casi tres de cada cuatro encargos.

El benchmark, llamado Co-Design Bench, fue desarrollado por investigadores de Alibaba y varias universidades asiáticas. Según informó The Decoder, evalúa a los agentes mediante cambios en aplicaciones web existentes, en lugar de problemas de programación aislados. Las tareas pueden incluir referencias visuales, audio, vídeo y documentos, reflejando las entradas combinadas que los equipos de producto e ingeniería proporcionan cada vez más a las herramientas de IA.

Una prueba más exigente para los agentes de programación

Co-Design Bench está diseñado para abordar lo que sus investigadores describen como la saturación de las evaluaciones de programación establecidas. Cuando los modelos pueden ejecutar, inspeccionar y reparar su propio código, pueden superar el 99 % en algunos benchmarks antiguos, dejando poco margen para distinguir entre sistemas.

La nueva prueba se basa en cambio en solicitudes de sesiones de programación reales. Los investigadores seleccionaron casos en los que los usuarios ya habían tenido que reformular solicitudes o revertir cambios fallidos. Estos casos van desde tareas relativamente limitadas, como extraer un importe de un recibo y actualizar los totales relacionados, hasta rediseños más amplios de aplicaciones.

Este diseño hace que el benchmark sea menos representativo de un ejercicio de programación limpio y autónomo, y más representativo del trabajo desordenado que implica mantener un producto activo. También significa que los resultados no deben interpretarse como una medida universal de todos los flujos de trabajo de programación. Sin embargo, sí ponen de relieve la diferencia entre producir código plausible y completar la solicitud íntegra de un usuario.

La evidencia detrás del resultado del 26,4 %

Según el artículo descrito por The Decoder, GPT-6 Astra fue el modelo con mejor rendimiento entre los diez evaluados. Cumplió aproximadamente el 70 % de los requisitos de las tareas en promedio, pero resolvió por completo solo el 26,4 % de ellas. Una tarea se consideraba completa únicamente cuando todas las funciones requeridas funcionaban en la aplicación.

Claude Opus 5 y Qwen3.8-Max siguieron a GPT-6 Astra en la clasificación publicada, mientras que Grok 4.6 quedó en último lugar. En las grandes revisiones de aplicaciones, el modelo más pequeño Qwen3.8-27B subió al segundo puesto, aunque los investigadores no consideraron que ese resultado demostrara una ventaja general del modelo.

El proceso de evaluación también fue más estricto que una simple revisión del código. Un evaluador automatizado probó la aplicación terminada en un navegador, mientras que un segundo revisor comprobó los resultados positivos y buscó maquetas visuales, salidas codificadas manualmente u otros atajos que pudieran aparentar satisfacer una solicitud sin implementar el comportamiento subyacente.

Estos son resultados de investigación, no mediciones de adopción o productividad verificadas de forma independiente. Los autores del benchmark reconocen que sus evaluadores automatizados pueden cometer errores, y las tareas utilizan una única solicitud fija en lugar de una conversación en directo en la que un usuario pueda responder preguntas o corregir a un agente durante el trabajo. Por tanto, los resultados muestran dónde tuvieron dificultades los agentes bajo esta configuración de prueba, no la cantidad exacta de trabajo humano necesaria en todos los entornos de producción.

El modelo es solo una parte del sistema

Uno de los hallazgos más importantes del benchmark se refiere al arnés del agente: el entorno de software que permite a un modelo leer archivos, modificar código, ejecutar aplicaciones e inspeccionar resultados. En una comparación independiente, Qwen3.8-27B obtuvo un 75 % en grandes revisiones con un arnés, pero solo un 56 % con otro. La clasificación relativa de dos modelos también cambió en función del entorno.

Este resultado cuestiona la práctica de comparar agentes de programación únicamente mediante clasificaciones de modelos. El rendimiento de un modelo depende de las herramientas que puede utilizar, del contexto que recibe, de cómo observa el comportamiento del navegador y de la eficacia con la que puede recuperarse de un cambio incorrecto. Para los compradores que evalúan un asistente de programación con IA, la unidad práctica de comparación es, por tanto, la combinación de modelo y arnés.

El estudio también descubrió que un cómputo adicional no cerraba la brecha de forma fiable. GLM-5.2 utilizó casi seis veces más tokens que GPT-6 Astra en cambios pequeños, pero obtuvo una puntuación considerablemente inferior. Un mayor razonamiento o una ejecución más larga pueden ayudar en algunas tareas, pero el resultado sugiere que utilizar más tokens no sustituye a una mejor descomposición de tareas, pruebas e interacción con la aplicación.

Qué significan los hallazgos para desarrolladores y empresas

Para los equipos de ingeniería, la implicación inmediata es que los agentes de programación con IA siguen siendo más útiles como socios de implementación supervisados que como responsables autónomos de los cambios de producto. Un agente puede crear la mayor parte de una función, pero los equipos aún deben comprobar los casos límite, la fidelidad visual, el manejo de datos y las interacciones entre requisitos.

El riesgo es especialmente alto en tareas que combinan cambios de diseño, maquetación, interacción y contenido. El benchmark descubrió que el rendimiento disminuía en todos los modelos a medida que se combinaban más tipos de cambios, aunque esos requisitos interrelacionados son habituales en el trabajo de producto real. Por tanto, un flujo que trate cada solicitud como un único prompt puede producir una implementación parcial convincente y dejar sin terminar detalles importantes.

Los equipos que evalúen herramientas deberían probarlas con tareas internas representativas, incluidos cambios en bases de código y aplicaciones existentes, en lugar de limitarse a ejemplos de proyectos nuevos. Deberían medir la aceptación completa, las tasas de regresión, el tiempo de revisión y la frecuencia de correcciones manuales. Esto complementa evaluaciones establecidas como SWE-bench Verified, pero no debe sustituir la revisión humana ni las salvaguardas de despliegue.

Los hallazgos también son relevantes para los desarrolladores de plataformas de agentes. Una mejor inspección del navegador, un seguimiento más claro del estado, una reversión fiable y una validación más sólida podrían mejorar los resultados tanto como un modelo subyacente más grande. El resultado relativo al arnés indica que los equipos de producto deberían evaluar todo el flujo de trabajo, incluidos los permisos, la fiabilidad de las herramientas, la observabilidad y la recuperación ante fallos.

Qué observar a continuación

La próxima señal útil será saber si Co-Design Bench o evaluaciones similares se amplían más allá de las solicitudes fijas de una sola interacción. El trabajo real de software implica aclaraciones, requisitos cambiantes y comentarios de usuarios o responsables de proyecto, por lo que las versiones interactivas de la prueba podrían ofrecer una imagen diferente de la utilidad de los agentes.

Investigadores y compradores también deberían prestar atención a resultados que informen conjuntamente sobre el modelo y el arnés, en lugar de publicar una única clasificación de modelos. Una replicación independiente ayudaría a determinar si la clasificación publicada y los grandes efectos del entorno se mantienen en distintas bases de código y tipos de aplicaciones.

Por último, las tasas de aceptación en equipos de ingeniería reales seguirán siendo más significativas que la finalización de benchmarks por sí sola. The Decoder citó investigaciones anteriores de METR que mostraban que los responsables de proyectos aceptaban código generado por IA a una tasa aproximadamente 24 puntos porcentuales inferior a las puntuaciones de SWE-bench Verified. Esa diferencia advierte de que la finalización aparente de una tarea no se traduce automáticamente en software listo para desplegar.

Perspectiva de Creati.ai

Co-Design Bench importa porque mide la última milla del trabajo de los agentes de programación: no si un agente puede producir código, sino si el cambio de producto solicitado funciona realmente en toda la aplicación. Su resultado de solo un 26,4 % de finalización completa recuerda que la automatización parcial aún puede generar importantes obligaciones de revisión y reparación.

Para los desarrolladores de IA y los compradores empresariales, la lección práctica es dejar de tratar el modelo como el producto completo. La ejecución fiable dependerá de la combinación de modelo, arnés, pruebas, contexto de la aplicación y aprobación humana. Hasta que esos componentes se evalúen conjuntamente en tareas realistas, las afirmaciones sobre el desarrollo autónomo de software deben tratarse con cautela.