Qué pasó.

Dos papers publicados en julio proponen benchmarks que miden coding agents en lo que realmente hacen en 2026: tomar una intención vaga y construir un proyecto funcional sobre ella. ICAE-Bench (480 tareas, 12 lenguajes) simula un usuario que le encomienda al agente una solicitud de producto incompleta, evaluando planificación, clarificación de requisitos, debugging e integración a nivel de repositorio. Tencent WorkBuddy Bench construye tareas reverse-engineered a partir de commits y pull requests reales, en cuatro dominios: código, web, office, seguridad.

Por qué te afecta.

Si usas Claude Code o Codex, sabes que la parte difícil ya no es que escriba una función. La parte difícil es explicarle qué quieres cuando tú mismo no lo tienes del todo claro. Los benchmarks tradicionales como SWE-bench, como contábamos en la guía del paper que definió el campo, le dan al agente un issue de GitHub con instrucciones precisas y miden si lo resuelve. ICAE-Bench y WorkBuddy parten de un supuesto diferente: el input es difuso, el agente debe hacer preguntas, tomar decisiones de diseño, gestionar restricciones ocultas.

Los resultados de ICAE-Bench lo dejan claro: los agentes reproducen el comportamiento visible pero se esfuerzan con las restricciones ocultas, los casos extremos y la integración en horizontes largos. Es exactamente el punto donde tu trabajo de contexto y verificación marca la diferencia entre un prototipo que funciona y un software que aguanta.

En detalle

El cambio de paradigma es rotundo. SWE-bench, el benchmark que ha definido cómo medimos coding agents hasta ahora, parte de issues de GitHub con descripciones ya precisas: hay un bug, hay una feature solicitada, el agente debe producir un patch que supere los tests. Es un modelo que corresponde al trabajo de un programador que recibe un ticket bien redactado.

El vibe-coding, el término con el que se ha popularizado el uso de agentes que construyen software a partir de descripciones informales, ha desplazado el peso. Quién usa Claude Code o Codex ya no escribe especificaciones completas: lanza una idea, el agente hace preguntas, itera. Los benchmarks tenían que adaptarse.

ICAE-Bench aborda el problema con una arquitectura interesante. Cada tarea proviene de un repositorio open-source real con comportamiento ejecutable verificado. La ambigüedad no está inventada: viene de la diferencia entre lo que un usuario pediría verbalmente y lo que el código debe hacer realmente. Un User Agent automatizado simula la contraparte humana, revelando restricciones ocultas conforme el agente hace preguntas, sin inventar nuevos requisitos ni filtrar la solución. La evaluación combina tests de caja negra estandarizados con diagnósticos multidimensionales: corrección funcional, similitud semántica y de API, fidelidad estructural, calidad del diseño, calidad de la interacción.

Los resultados en seis modelos y dos frameworks agentivos muestran un patrón recurrente. Los agentes logran reproducir el comportamiento visible de la aplicación, pero fallan en las restricciones ocultas, los casos extremos y la integración en horizontes largos. La demo funciona, los detalles no.

Tencent WorkBuddy Bench toma un camino distinto hacia el mismo objetivo. En lugar de adaptar texto de issues públicos, cada tarea se reconstruye hacia atrás a partir de un commit, una pull request o un escenario empresarial real, luego se reformula para resistir la contaminación (el riesgo de que el modelo ya haya visto la solución en los datos de entrenamiento). Cubre cuatro dominios: código, web, office, seguridad. El enfoque en la contaminación es relevante: cuando los benchmarks se basan en repositorios públicos, los modelos más grandes tienen una ventaja espuria porque memorizaron el código durante el training.

¿Qué cambia para quien usa estas herramientas? Dos cosas prácticas. Primero, cuando lees un puntaje de coding agent, verifica qué mide: un número alto en tareas con especificaciones precisas te dice poco sobre cómo el agente se desenvolverá con tu solicitud vaga del viernes por la tarde. Segundo, los puntos débiles que ICAE-Bench pone en relieve (restricciones ocultas, casos extremos, integración larga) son exactamente aquellos donde tu trabajo de clarificación y verificación puntual marca la diferencia entre entregar un prototipo y entregar software usable.

Los límites de ambos benchmarks deben declararse. ICAE-Bench simula el usuario con un modelo, lo que introduce la variabilidad típica del LLM-as-a-judge: el User Agent podría ser más o menos colaborativo que un humano real. WorkBuddy está construido por un equipo Tencent y la documentación completa de la metodología está en el paper, pero el leaderboard cross-model no es aún público en forma verificable de forma independiente.