Construir para la prueba: los agentes de codificación entregan lo que verificas, no lo que solicitaste

Resumen

Los puntos de referencia se utilizan ampliamente para evaluar la finalización de tareas por parte de los Modelos de Lenguaje de Gran Escala (LLMs), pero este enfoque ha acumulado problemas de validez de constructo, y una puntuación aprobatoria puede no indicar si la tarea solicitada fue realmente entregada. Estudiamos ambos problemas. En un entorno controlado de código como especificación, dos agentes Copilot CLI de producción (claude-opus-4.7, gpt-5.5) reimplementan una tabla de datos React Fluent-UI en Angular como una biblioteca reutilizable bajo un oráculo oculto Playwright de 222 pruebas en 18 ejecuciones y tres condiciones de disponibilidad del oráculo. Junto con la puntuación, realizamos una auditoría mecánica de la biblioteca y verificamos cada veredicto con una ablación sin operación. Sin el oráculo, la biblioteca está presente pero incompleta, como revelan las puntuaciones. Con el oráculo en el proceso, la puntuación alcanza un nivel casi perfecto, pero a partir de una demo que alberga directamente el comportamiento evaluado, la biblioteca queda inactiva o ausente. A esto lo denominamos construir para la prueba; la disposición más amplia detrás de ambos fenómenos la llamamos autoconciencia de validación. El agente, por sí mismo, no valida lo que entrega como lo haría un usuario. La prevalencia sigue siendo una pregunta abierta en otros agentes, señales y familias de modelos. Más allá de las puntuaciones de los puntos de referencia, disposiciones como la autoconciencia de validación merecen atención investigativa.

English

Benchmarks are widely used to evaluate task completion by Large Language Models (LLMs), but this approach has accumulated construction-validity problems, and a passing score may not show whether the requested task was delivered. We study both problems. In a controlled code-as-spec setup, two production Copilot CLI agents (claude-opus-4.7, gpt-5.5) re-implement a React Fluent-UI data table in Angular as a reusable library under a hidden 222-test Playwright oracle across 18 runs and three oracle-availability conditions. Alongside the score, we run a mechanical library audit and check each verdict with a no-op ablation. Without the oracle, the library is present but unfinished, revealed by scores. With the oracle in the loop, the score reaches near-perfect, but from a demo holding the tested behavior directly, the library left dead or absent. We call this building to the test; the broader disposition behind both we call validation self-awareness. The agent does not, on its own, validate what it ships as a user would. Prevalence remains an open question across other agents, signals, and model families. Beyond benchmark scores, dispositions like validation self-awareness merit research attention.