Investigadores de Alibaba y de varias universidades asiáticas armaron una prueba para agentes de programación a partir de pedidos de cambio que hicieron usuarios reales. El mejor modelo termina bien apenas una de cada cuatro tareas, un resultado que pone en perspectiva los puntajes casi perfectos de las pruebas anteriores.

El equipo bautizó la prueba como Co-Design Bench. Los agentes tienen que modificar aplicaciones web que ya existen según lo que pide el usuario, y en algunos casos el pedido llega acompañado de imágenes, grabaciones de audio, videos o documentos.

Según el paper, GPT-6 Astra, el mejor de los diez modelos evaluados, cumple en promedio cerca del 70% de los requisitos de cada tarea. Pero el resultado queda completamente correcto solo en el 26,4% de los casos. Casi siempre el agente resuelve el grueso del trabajo y deja al menos un detalle sin terminar, así que quien usa estas herramientas casi siempre tiene que corregir a mano.

Las pruebas de código quedaron demasiado fáciles

Los autores justifican la prueba nueva con la saturación de las que ya existen. Cuando un modelo puede ejecutar, revisar y corregir su propio código, supera el 99% en esas pruebas, y las diferencias entre modelos casi no se pueden medir.

En pruebas antiguas como WebCompass-edit, los modelos de programación agéntica sacan puntajes casi perfectos, mientras que Co-Design Bench deja una brecha de más de 35 puntos porcentuales.

Co-Design Bench se alimenta de pedidos reales sacados de sesiones de programación. Los investigadores prefirieron los casos en que el usuario tuvo que reformular su pedido varias veces o deshacer cambios, de modo que la prueba reúne sobre todo tareas que ya les dieron problemas a los agentes en la práctica. Van desde ajustes chicos, como sacar un monto de una boleta y actualizar todos los totales que dependen de él, hasta rehacer un proyecto entero.

En la categoría multimodal, los agentes tienen que extraer valores de boletas, tablas o videos y actualizar de forma coherente todas las vistas que dependen de esos datos.

La corrección es igual de estricta. Un primer juez de IA prueba la aplicación terminada en un navegador, y un segundo vuelve a revisar cada veredicto positivo y busca maquetas o resultados escritos a mano en el código. Solo suman puntos las funciones que de verdad operan dentro de la aplicación.

¿Qué modelos quedaron arriba?

Detrás de GPT-6 Astra aparecen Claude Opus 5 y Qwen3.8-Max, mientras que Grok 4.6 termina último. En las reformas más grandes, el mucho más chico Qwen3.8-27B sube al segundo lugar, aunque los autores no sacan de ese resultado una ventaja general del modelo.

El rendimiento cae en todos los modelos a medida que una tarea mezcla más tipos de cambio, entre diseño de página, estilo visual, interacción y contenido. Y esos requisitos entrelazados son la norma en los proyectos reales. Los diez modelos empeoran cuando una tarea exige tres o cuatro tipos de cambio distintos.

Gastar más cómputo tampoco corrige la falla. GLM-5.2 consume casi seis veces más tokens que GPT-6 Astra en los cambios chicos y aun así obtiene un puntaje bastante más bajo.

GPT-6 Astra encabeza las dos categorías, pero resuelve por completo solo el 41% de las tareas multimodales y poco menos del 18% de las tareas sobre repositorios.

¿Pesa más el modelo o el entorno de trabajo?

En una prueba aparte, los investigadores corrieron los mismos modelos dentro de distintos harness, que son los programas a través de los cuales un agente lee, escribe y ejecuta código. Qwen3.8-27B sacó 75% o apenas 56% en las reformas grandes según el entorno. Cuál de dos modelos quedaba adelante también dependía del entorno.

Por eso, una tabla de posiciones que solo nombra al modelo cuenta la mitad de la historia. Los autores recomiendan informar siempre el modelo y el entorno de trabajo juntos. Para una empresa que está eligiendo un agente de programación, eso significa probar las dos piezas como un par.

La prueba tiene límites. Evalúa un único pedido fijo por tarea, sin preguntas de seguimiento ni correcciones del usuario a mitad de camino. Los jueces de IA también pueden equivocarse.

Un estudio de la organización de investigación METR ya había mostrado cuánto pueden separarse los resultados de una prueba y la utilidad real. La tasa con que los responsables de proyectos aceptaban de verdad el código generado por IA quedó unos 24 puntos porcentuales por debajo de los puntajes en SWE-bench Verified, una de las pruebas más usadas.

Las fallas en los entornos de prueba también pueden dejar que un agente apruebe tareas sin resolverlas. El efecto del entorno de trabajo, en todo caso, no es parejo. Un estudio reciente sobre agentes de programación casi no encontró beneficio medible en los harness más elaborados, aunque gastaban hasta tres veces más tokens.