Resumen Técnico: BUILD-AND-FIND

Enunciado del Problema

Las actuales pruebas de referencia para agentes de codificación evalúan principalmente la corrección conductual (por ejemplo, superar pruebas unitarias). Sin embargo, a medida que los agentes pasan de la síntesis de funciones a la ingeniería a nivel de repositorio, los repositorios de código generados sirven cada vez más como artefactos intermedios: un agente escribe un repositorio y agentes subsiguientes deben inspeccionarlo, auditarlo o extenderlo. En este contexto, un repositorio no es meramente una respuesta a una tarea, sino un artefacto de comunicación.

El artículo identifica una brecha: un repositorio puede superar las pruebas conductuales visibles y, sin embargo, no exponer claramente la intención de diseño y las decisiones detrás de ese comportamiento. Si un repositorio generado oculta su intención, impone una carga de inspección adicional a los agentes aguas abajo, incluso si el código funciona correctamente. Las pruebas de referencia existentes no miden si las decisiones previstas son recuperables del propio artefacto antes de intentar cualquier modificación.

Metodología: El Protocolo BUILD-AND-FIND

Los autores proponen BUILD-AND-FIND, un protocolo diseñado para evaluar la recuperación evidenciada por el artefacto. Este enfoque separa la capacidad de construir código de la capacidad de recuperar la intención a partir de ese código.

Roles Principales

1. Constructor: Recibe una especificación oculta (que define comportamientos previstos y decisiones de diseño) y genera una base de código autónoma.
2. Buscador: Recibe únicamente la base de código generada y un banco de preguntas de opción múltiple trazado a la especificación. La especificación oculta permanece inaccesible. El buscador debe inspeccionar archivos, realizar llamadas a herramientas y responder preguntas basándose únicamente en el artefacto.

Capas de Evaluación

El protocolo define tres capas distintas de evaluación:

1. Corrección Conductual: ¿Supera el código las pruebas? (Enfoque estándar de las pruebas de referencia).
2. Recuperabilidad de la Intención del Lado del Artefacto: ¿Puede un agente aguas abajo recuperar los comportamientos previstos y las decisiones de diseño únicamente a partir del artefacto? (El enfoque de BUILD-AND-FIND).
3. Éxito de la Modificación Aguas Abajo: ¿Puede un agente posterior modificar el repositorio de forma segura? (Trabajo futuro).

Métricas y Controles

El protocolo reporta cuatro métricas clave, con una jerarquía estricta de interpretación:

• Precisión de Recuperación: Precisión de coincidencia exacta en el banco de preguntas.
• Estabilidad/Repetibilidad: Consistencia de las respuestas en ensayos repetidos.
• Cobertura de Implementación: La fracción de afirmaciones de la especificación que se implementan realmente en el artefacto (audita para asegurar que los buscadores no sean penalizados por afirmaciones de oro no implementadas).
• Esfuerzo de Inspección: Medido en bytes de inspección de agente novedosos (nuevos bytes recuperados mediante llamadas a herramientas, excluyendo los prompts del sistema y la sobrecarga de transporte).

Restricción Crucial: El esfuerzo de inspección se interpreta como un proxy para la legibilidad del artefacto solo después de que se superen las barreras de precisión y estabilidad de la recuperación. Si la recuperación falla, el esfuerzo carece de significado.

Controles:

• Solo Pregunta: Los buscadores ven solo las preguntas (mide los priores de ingeniería genéricos).
• Solo Especificación: Los buscadores ven la especificación (mide la respondibilidad límite superior).
• Fallo de Compilación: Los artefactos que fallan la compilación se retienen como diagnósticos de estrés.
• Auditoría de Evidencia: Comprobaciones a posteriori para verificar si las respuestas correctas citan evidencia específica del artefacto (archivos fuente, configuraciones) en lugar de depender de priores.

Contribuciones Clave

1. Objetivo de Evaluación: Define la recuperación evidenciada por el artefacto como una capa distinta entre la corrección conductual y la modificación aguas abajo.
2. Protocolo Constructor–Buscador: Un marco de roles divididos donde los constructores codifican especificaciones ocultas en código, y los buscadores intentan decodificarlas sin ver la especificación.
3. Contrato de Medición: Un estándar riguroso de informes que separa la precisión (validez) del esfuerzo (legibilidad), asegurando que el esfuerzo solo se analice cuando la recuperación es fiable.
4. Calibración y Lanzamiento: Un lanzamiento exhaustivo que incluye el entorno de pruebas, las tareas (scratch_minidb, scratch_nanoweb), los artefactos generados, tablas canónicas y auditorías de evidencia. Incluye diagnósticos para la afinidad constructor–buscador y la sensibilidad a priores bajos.

Resultados Empíricos

El estudio evaluó 12 configuraciones de agentes (incluyendo GPT-5.5, Opus 4.7, Sonnet 4.6 y variantes de MiMo) en dos familias de tareas.

• Régimen de Alta Recuperación: En el paquete de tareas de alto prior lanzado, la precisión de recuperación está cerca de la saturación (por ejemplo, ~98,9% para ejecuciones condicionadas al artefacto frente a 94,5% para solo pregunta). Debido a que la precisión es alta, sirve principalmente como una barrera y no como una señal discriminativa.
• Esfuerzo de Inspección como Discriminador: Con las barreras de recuperación superadas, el esfuerzo de inspección condicional se convierte en la métrica principal para comparar la legibilidad del artefacto.
  • GPT-5.5 demostró el menor esfuerzo de inspección (alta legibilidad), con una puntuación de esfuerzo relativo ($R_b$) de 1,033 en el panel de alto esfuerzo.
  • Las variantes de MiMo generalmente requirieron un mayor esfuerzo de inspección.
  • Claude Sonnet 4.6 y Opus 4.7 mostraron niveles de esfuerzo intermedios, con cierta variación basada en la configuración del esfuerzo de razonamiento (alto vs. bajo).
• Afinidad: El estudio encontró que la legibilidad puede depender del lector. Los pares constructor–buscador de la misma familia (por ejemplo, constructor de OpenAI + buscador de OpenAI) mostraron residuos de afinidad positivos, lo que sugiere que recuperan la intención más fácilmente que los pares de familias cruzadas.
• Auditoría de Evidencia: En una muestra de 72 respuestas correctas, 65 estaban "respaldadas" por evidencia de artefacto citada (principalmente archivos fuente), confirmando que en esta configuración, una alta precisión generalmente se correlaciona con un razonamiento fundamentado en el artefacto.

Significado y Afirmaciones

El artículo afirma que BUILD-AND-FIND establece un contrato de evaluación necesario para los repositorios de código gestionados por agentes. Su importancia radica en:

• Cambio de Enfoque: Pasar de "¿funciona?" a "¿es comprensible para otro agente?".
• Proxy de Legibilidad: Tratar el esfuerzo de inspección como un proxy medible de qué tan bien un artefacto comunica la intención de diseño, siempre que la recuperación sea estable.
• Separación de Preocupaciones: Desacoplar explícitamente la capacidad de implementación de la capacidad de recuperar la intención, permitiendo un análisis más matizado del rendimiento de los agentes.
• Marco Auditables: Proporcionar una infraestructura reproducible y lista para la auditoría que separa los priores genéricos de la recuperación condicionada al artefacto, evitando que las pruebas de referencia se resuelvan únicamente mediante memorización o conocimiento de ingeniería genérico.

Los autores mantienen modestia, señalando que las afirmaciones actuales se limitan al panel lanzado y a las familias de tareas. Enfatizan que la prueba de referencia no mide la corrección en tiempo de ejecución, la seguridad o la mantenibilidad humana, sino la capacidad específica de los agentes de utilizar los repositorios generados como memoria externa y medio de comunicación.