Nuevo benchmark de Alibaba: los agentes de IA cumplen parte de los requisitos, pero no toda la tarea

Alibaba, junto con la Universidad China de Hong Kong, la Universidad Jiao Tong de Shanghái y la Universidad Tecnológica de Nanyang, ha presentado Co-Design Bench. Se trata de un conjunto de tareas para agentes de IA que escriben código. Los modelos se evalúan con lo que piden de verdad los usuarios: tomar una aplicación web que ya funciona y modificarla según una descripción, a veces acompañada de una captura de pantalla, una grabación de voz, un vídeo o un documento.

El resultado de los diez modelos probados es este: el mejor cumple una parte notable de los requisitos de media por tarea, pero completa por entero solo una fracción menor de las tareas. Resuelve puntos sueltos, pero no logra ensamblarlos todos.

Tareas de sesiones reales, no sintéticas

Muchas pruebas para agentes de programación se construyen de forma artificial: rompen una página de referencia y piden arreglarla, o entregan un conjunto de cambios predefinido. Los autores de Co-Design Bench siguieron otro camino. Tomaron peticiones de sesiones reales de usuarios, eliminaron duplicados y se quedaron con aquellas que ofrecían algo verificable. Para cada tarea reconstruyeron la aplicación ejecutable «antes de la edición», además del historial de la sesión y los archivos adjuntos.

La prueba tiene dos tracks:

• Multimodal Editing (ME): ediciones locales de diseño, estructura y contenido. El agente dispone de la página, un área seleccionada y una petición, a veces con una imagen, un audio, un vídeo o un documento. Ejemplo: un recibo indica un importe, y hay que actualizarlo de forma coherente en la tabla y en los resúmenes finales.
• Repository Editing (RE): cambios coordinados en un repositorio de frontend: componentes, rutas, estado y flujo de datos. Ejemplo: un editor de clips de vídeo deportivo en el que hay que limitar el número y la duración de los clips, alinear la línea de tiempo al cambiar la escala y volver a habilitar la inserción tras eliminar o cortar un clip.

Las tareas se evalúan en tres dimensiones: comprensión del contexto (Grounded Understanding), transformación de la interfaz (UI Transformation) e implementación de funciones (Functional Implementation).

Antes de entrar en el conjunto, la aplicación debe compilarse, ejecutarse en un contenedor y renderizarse en Playwright (una herramienta de automatización del navegador). Se excluyeron las tareas que requerían servicios externos no disponibles. Las peticiones se ordenaron por dificultad, verificabilidad y señales de fallos previos, como reformulaciones y reversiones. Después, los expertos pulieron las peticiones hasta dejarlas con una formulación clara y escribieron criterios de aceptación ocultos.

Cómo se comprueba sin código de referencia

La tarea no tiene una solución de referencia, porque una misma edición puede hacerse de distintas maneras. Por eso los criterios describen el resultado: qué debe aparecer y cómo debe comportarse. No dictan la implementación. La comparación con la aplicación original ayuda a entender qué cambió y qué había que conservar.

La comprobación se hace en varios pasos:

• Primero, un agente evaluador examina la aplicación final: la diferencia en el código fuente, las páginas renderizadas y las acciones grabadas en el navegador. Un manejador en el código no demuestra nada si el usuario no puede llegar hasta él a través de la interfaz.
• Después, un verificador LLM independiente recibe los veredictos y las pruebas reunidas e intenta refutarlos. Busca stubs, respuestas incrustadas en el código, puntos de entrada inalcanzables, fallos con otros datos de entrada e incumplimientos de la petición.
• Una auditoría obligatoria exige un renderizado correcto y capturas de pantalla para las afirmaciones visuales, y registros de acciones en el navegador para las interactivas. Si no hay pruebas, la evaluación se interrumpe antes de calcular las puntuaciones.

Todos los veredictos y registros se conservan, de modo que cualquier valoración puede rastrearse hasta sus evidencias. Además, dos expertos en frontend revisaron a mano una parte de las valoraciones. Los autores reconocen con franqueza que esto no elimina por completo los errores de los jueces.

Qué mostraron los diez modelos

Los diez endpoints de modelos se ejecutaron con un mismo arnés agéntico: el agente puede consultar el código, editar archivos, compilar y ejecutar la aplicación. De los resultados se desprenden varias conclusiones.

• La proporción de criterios cumplidos y la de tareas resueltas por completo difieren de forma notable. Un usuario cuya petición se implementó en su mayor parte sigue encontrándose con un escenario que no funciona.
• La clasificación de los modelos varía entre tracks: el mejor en ediciones locales no es necesariamente el mejor en ediciones de repositorio.
• En los diez modelos, la completitud es peor en tareas de repositorio con tres o cuatro tipos de cambios (estructura, estilo, interactividad, contenido) que en las de uno o dos.

Por separado, los autores mostraron que el modo de trabajo altera la puntuación. En las tareas de WebCompass-edit, pasar de un único intento a un modo agéntico con herramientas elevó de forma notable la proporción media de funciones completadas, aunque la rúbrica, el juez y el renderizado seguían siendo los mismos. Por tanto, las cifras de pruebas con modos distintos no pueden compararse directamente.

Los autores comparan Co-Design Bench con otros benchmarks. Design2Code, WebSight-Test y WebRenderBench evalúan la conversión de una captura de pantalla en código. IWR-Bench añade vídeo de interacción. WebGen-Bench y FrontendBench prueban sitios creados desde cero. DesignBench, MT-Web2Code, WebCompass y FronTalk abordan las ediciones y el diálogo. SWE-bench, SWE-bench Multimodal y SWE-Lancer toman tareas de GitHub y de trabajo freelance. La novedad de Co-Design Bench está en combinar sesiones reales, adjuntos multimodales, un estado inicial ejecutable, una verificación sin referencia y un verificador adversarial.

Para los equipos que incorporan agentes de programación, la conclusión es práctica. La métrica del «porcentaje de puntos superados» sobrestima la preparación: es más importante contar la proporción de tareas cerradas por completo y analizar por separado las ediciones complejas de varios componentes. Para validar código generado por IA conviene exigir pruebas como capturas de pantalla y grabaciones de acciones en el navegador. El código en un diff no demuestra que la función esté operativa.