Co-Design Bench muestra la distancia entre avanzar en una tarea y completarla: el mejor modelo evaluado cumplió todos los requisitos en el 26,4% de los casos.
Le pides a una inteligencia artificial que modifique tu web. En pantalla aparece un diseño atractivo, los botones están en su sitio y el agente anuncia que ha terminado. Pero empiezas a probar: un filtro no actualiza los resultados, un cambio se pierde al navegar o una cifra no coincide con el resumen.
Es un ejemplo hipotético, pero ayuda a entender una pregunta importante: ¿cuándo podemos considerar que una tarea de programación está realmente terminada?
Qué pone a prueba Co-Design Bench
El estudio, publicado en arXiv el 26 de octubre de 2026 por investigadores de Alibaba y varias universidades, evalúa modificaciones de aplicaciones existentes. Reúne 273 tareas seleccionadas de 37.463 peticiones procedentes de sesiones reales de programación.
Las solicitudes incluyen cambios de interfaz, contenido y funcionamiento, en ocasiones apoyados en imágenes, audio, vídeo o documentos. La selección tiene en cuenta la dificultad y señales de problemas anteriores: no representa una muestra aleatoria de todo el trabajo de programación.
Dos cifras que cuentan historias diferentes
GPT-6 Astra obtuvo el mejor resultado entre los diez modelos evaluados: satisfizo, de media, el 69,9% de los criterios por tarea, pero solo cumplió todos los requisitos en el 26,4% de las tareas.
El 73,6% restante dejó al menos un criterio sin satisfacer por completo. Eso no equivale a demostrar que todas esas aplicaciones se bloquearan, fueran inseguras o necesitaran una reconstrucción.
Por qué “casi terminado” puede ser insuficiente
Imagina una petición sencilla: añadir un formulario para que los visitantes soliciten información. Puedes dividirla en varias comprobaciones: que los campos aparezcan, que el correo se valide, que el envío llegue a su destino y que el usuario reciba una confirmación.
Si todo funciona salvo la entrega del mensaje, la apariencia puede ser impecable y el formulario seguir siendo inútil para el negocio. Si lo único pendiente es ajustar un margen, la gravedad será muy distinta.
Este ejemplo permite ver por qué conviene separar dos preguntas: cuánto se ha completado y qué importancia tiene lo que falta. Un porcentaje de avance, por sí solo, no responde a ambas.
La revisión empieza antes de escribir código
Para quien trabaja con estas herramientas, una práctica útil es transformar la petición inicial en condiciones observables. “Mejora el buscador” deja mucho espacio a interpretaciones. “Permite combinar país e idioma, conserva los filtros al volver atrás y muestra un aviso cuando no haya resultados” ofrece un objetivo comprobable.
También conviene distinguir entre lo que se ve y lo que sucede. Una captura puede mostrar que existe un botón. Para comprobar su comportamiento hay que pulsarlo, observar el resultado y repetir la operación en situaciones diferentes.
En una web de empleo, por ejemplo, no bastaría con que las ofertas aparecieran correctamente. Habría que verificar que los filtros combinados funcionan, que los enlaces llevan a la oferta correspondiente y que una candidatura puede completar el recorrido previsto. Son ejemplos prácticos, no incidencias documentadas por este estudio.
Cómo aprovechar los agentes sin perder el control
- Define qué significa terminar: escribe una lista breve de resultados que puedas comprobar.
- Divide los cambios amplios: revisar una modificación concreta facilita localizar el origen de un problema.
- Prueba recorridos completos: comprueba qué ocurre antes, durante y después de una acción.
- Comprueba lo que debía conservarse: una mejora también debe respetar las funciones anteriores que siguen siendo necesarias.
- Pide pruebas del resultado: una afirmación de éxito debe ir acompañada de comprobaciones que puedas revisar.
El criterio humano tiene un trabajo concreto
La aportación de una persona no tiene por qué limitarse a reparar el resultado final. También consiste en decidir qué se necesita, resolver ambigüedades y distinguir un detalle pendiente de un fallo que impide utilizar el producto.
Por eso, al valorar una herramienta de programación, merece la pena observar el recorrido completo: definir, generar, revisar y corregir. La velocidad de escritura es solo una parte de ese trabajo.
El pincel digital puede ayudar a construir. Dar la obra por terminada exige comprobar que hace lo que se le pidió.
Fuentes y lecturas recomendadas
- Estudio original: Co-Design Bench — Multimodal Collaborative Coding Evaluation for Agentic Models.
- Repositorio del proyecto Co-Design Bench.
Sombra Radio · Apoyo de lectores
Ayuda a mantener viva Sombra Radio
Tu aportación voluntaria nos ayuda a seguir publicando sobre IA. Puedes apoyarnos desde 1 € al mes.
