Evalúa agentes de IA de programación con una escena de Three.js

Una escena pequeña expone los fallos más rápido

Estás decidiendo si un agente de IA de programación puede asumir una tarea real de frontend. Entrégale una escena de Three.js restringida que se abra en un navegador, muestre el comportamiento requerido y pueda fusionarse tras una revisión breve. El prompt de referencia especificaba una escena de un solo archivo Three.js de un hangar de ciencia ficción con drones flotantes, luces de advertencia, franjas de pista y planos de niebla. Una posición en un ranking muestra cómo se comportó un modelo en el benchmark de otro; un archivo entregado muestra si tu equipo puede fusionarlo.

Un prompt de hangar de ciencia ficción en Three.js se ejecutó con diversas combinaciones de modelos y harness en modo /goal. También solicitaba un interruptor para cambiar formaciones de drones, un recorrido de cámara cinematográfico y un archivo HTML autónomo con el JavaScript incrustado en línea. Mantén la tarea lo suficientemente pequeña para que un ingeniero senior pueda revisarla en una sola sesión.

El mismo prompt hace la comparación justa

Ejecuta el prompt con tu lista de candidatos en un solo modo de harness. Usa un archivo de entrada, un navegador y una lista de verificación de aceptación en todas las ejecuciones. En esas pruebas, cada ejecución de GLM llevaba la etiqueta GLM 5.3 Flash Max. Registra esa etiqueta exactamente y anota la versión del prompt, la fecha, la versión del navegador y la persona que ejecutó la prueba antes de puntuar.

El adaptador DSH no proporciona un recuento separado de tokens de razonamiento, por lo que trata el coste en tokens como incompleto cuando ese campo no está presente. La tabla de ejecuciones debe incluir la etiqueta del modelo, el harness, el archivo de salida, el recuento de tokens, el tiempo real y el coste en dólares. Si una ejecución falla, guarda el archivo de salida y el registro de consola antes de reintentar. Una prueba repetible, no un resultado aislado, es el objetivo.

No dejes que una demo vistosa oculte un interruptor faltante; la ficha de puntuación registra el comportamiento entregado, no capturas de pantalla. Si el harness puede desplegar subagentes en worktrees aislados, registra si tu tarea realmente lo necesita. La beta de Muse Code de Meta puede ejecutar subagentes en worktrees aislados en paralelo; Meta reportó una prueba en la que construyó seis funciones de juego a la vez sin colisiones. Para esta escena, el paralelismo suele ser sobrecarga, no señal.

Puntúa el comportamiento entregado, no el pulido de la demo

Usa la ficha de puntuación como puerta de entrega. Mantén la puntuación compacta: aprobado/rechazado para cada puerta, más una nota breve sobre el fallo.

• Compilación aprobada: el archivo se abre sin errores de consola que bloqueen la escena.
• Apariencia aprobada: los elementos requeridos de la escena están presentes y son legibles.
• Tiempo de ejecución aprobado: las interacciones requeridas se ejecutan realmente.
• Funciones requeridas: cuenta solo lo que un humano puede activar.
• Número de ediciones: las modificaciones humanas necesarias antes de que el archivo sea fusionable.
• Coste: incluye prompt, reintentos y correcciones locales.
• Tiempo: incluye prompt, reintentos y correcciones locales.
• Modos de fallo nombrados: etiqueta cada fallo.

Un estudio de Claude Code sobre 567 pull requests en 157 proyectos de código abierto encontró que el 83,8 % finalmente se fusionó, pero solo el 54,9 % se fusionó sin cambios adicionales, dejando un 45,1 % que necesitaba revisión humana. Espera revisión humana; la ficha de puntuación debe medir cuánto.

El rendimiento puede aumentar mientras la carga de revisión se desplaza. En el estudio empresarial, a medida que crecieron los pull requests escritos por IA, la proporción que recibió al menos una revisión humana bajó del 89 % al 68 %, la cobertura de revisión automatizada por IA subió de aproximadamente el 19 % al 84 %, y la carga de trabajo de los revisores se duplicó aproximadamente. Tras la directiva de 2x de la empresa, los pull requests escritos por IA necesitaron aproximadamente un 20 % más de tiempo de fusión tras la primera revisión humana, y un 22 % más de tiempo total.

Mide el rendimiento por separado de la calidad. Un estudio de cuatro meses de Microsoft sobre agentes de IA de programación por línea de comandos encontró que los desarrolladores que usaban las herramientas fusionaron un 24,0 % más de pull requests por ingeniero y por día. Para abril de 2026, el rendimiento por desarrollador del estudio empresarial era 2,09 veces la línea base previa a la directiva, pasando de 21,2 a 44,3 pull requests fusionados por cada desarrollador activo. Esos números son útiles para la adopción, no para decidir si un agente puede entregar tu tarea de frontend.

Un registro de fallos respalda la próxima decisión

Mantén un registro de fallos con etiquetas breves: interruptor faltante, cámara rota, formato de archivo incorrecto, contabilidad de tokens inexplicable y errores que bloquean la fusión. El registro está listo cuando indica qué modelo y harness entregaron, cuánto costó, cuántas ediciones necesitó y qué modos de fallo se repitieron.

El GLM-5.2 de Z.ai fue segundo en Code Arena a mediados de junio de 2026, por detrás solo del Claude Fable 5 de Anthropic. Una posición en un ranking público de programación sigue sin eliminar la necesidad de una prueba de entrega. Promueve un agente a trabajo real solo cuando supere la escena repetidamente y sus modos de fallo sean aburridos. Aburrido significa una etiqueta faltante, no una interacción requerida ausente. Usa el registro para comparar proveedores, no para clasificar modelos. Si el mismo fallo aparece en diferentes harness, trátalo como una debilidad del modelo, no como un caso aislado.