Auditoría del feedback que revelaba la respuesta esperada a agentes de código

El problema

Un agente de código que repara una función suele ejecutarse en bucle: propone un parche, corre una prueba, lee el mensaje que vuelve, lo intenta de nuevo. Cuando el bucle recibe el feedback de un ejecutor de pruebas y la tasa de reparación sube, la mejora se atribuye al feedback. La pregunta que el programa de investigación del fundador se propuso poner a prueba era más acotada: ¿la fiabilidad depende de quién es dueño del veredicto que detiene el bucle, el propio modelo o un supervisor cuyo veredicto no puede falsificarse?

Esa pregunta no puede responderse mientras el mensaje de feedback lleve la respuesta. Un traceback que imprime assert f(x) == y hace más que informar de un fallo. Revela la relación que comprueba la prueba visible y el valor objetivo literal. Cualquier ganancia medida después de un mensaje así queda confundida con una pista específica de la tarea, y el estudio llama a eso un problema de medición.

Qué se construyó

El preprint "When Execution Feedback Reveals the Expected Output: A Forensic Study of Answer Leakage in Agentic Code Repair" se publicó en Zenodo el 10 de julio de 2026 como preprint del autor, versión 1.0.0, sin revisión por pares, bajo licencia Creative Commons Atribución 4.0. Su autor es el fundador de NASCIA, que escribe bajo su afiliación a la Universidad de São Paulo. Es un estudio forense de su propio programa de investigación, no un producto, y no encuentra ninguna evidencia positiva limpia y validada del beneficio que el programa se había diseñado para demostrar.

Se auditaron tres diseños experimentales, cada uno con su benchmark y su estado forense: diez tareas creadas por el autor con Qwen2.5-Coder 14B; HumanEvalFix con Qwen2.5-Coder 1.5B sobre 80 tareas y tres semillas; QuixBugs con el mismo modelo 1.5B sobre 29 tareas y tres semillas, lo que da 87 observaciones por brazo. El artículo aporta dos auditorías de filtración específicas para esos bancos, un diagnóstico vinculado a la procedencia y un protocolo de control para estudios futuros.

Las auditorías son fáciles de enunciar. Para QuixBugs, una búsqueda de la palabra "expected" en cada mensaje de feedback consumido, seguida de un recuento estricto que exige la plantilla del propio banco, "Input gave X, expected Y". Para HumanEvalFix, un comparador que toma cada línea de aserción de la prueba de ejemplo oficial y exige que la línea completa, específica de la tarea, aparezca en el feedback, y que admite una ronda solo si el SHA-256 del último mensaje de usuario de la transcripción coincide con el hash guardado en la fila de resultado. Las rondas que no pueden vincularse se cuentan como limpias, así que cada fracción reportada para HumanEvalFix es una cota inferior.

El artículo reemplaza un preprint anterior del mismo programa. Aquel trabajo se retiró por completo después de que una auditoría forense determinara que sus resultados no habían sido producidos por un bucle con un modelo en vivo, y ninguna de sus cifras entra en el nuevo análisis. El registro nombra el preprint retirado en su propia página, y el artículo explica por qué: revelar el fallo es parte del resultado.

Cómo funciona

El diagrama muestra el bucle en estudio y la auditoría construida a su alrededor. Un modelo de lenguaje propone un parche; una prueba visible lo ejecuta; un mensaje de feedback vuelve al modelo. La auditoría lee las propias cadenas devueltas y vincula cada mensaje con su fila de resultado mediante un hash; junto al verificador real, tres brazos de control del mismo bucle entregan al modelo un mensaje erróneo, obsoleto o barajado en lugar del feedback real.

La campaña sobre QuixBugs tuvo siete brazos prerregistrados: una línea base ciega, feedback en el prompt, detención por el propio modelo, verificación out-of-band con feedback rico y los tres controles de integridad. La regla de invalidación se fijó antes del primer intento de campaña: el diseño es inválido si cualquier control supera la línea base en al menos 0,07 con una p exacta de McNemar pareada por debajo de 0,05. Solo después de que la campaña primaria cerrara y la regla se activara se especificaron dos brazos exploratorios, cada uno con una marca de tiempo anterior a su propia ejecución: un bucle solo de andamiaje, con mensajes sin contenido, y un verificador out-of-band cuyo mensaje dice únicamente si pasó o falló.

La inferencia se agrupa por tarea. Las 87 observaciones por brazo son 29 tareas repetidas sobre tres semillas, así que la tarea es la unidad de la prueba de signos bilateral y del bootstrap pareado. Los intervalos de Wilson describen las tasas por celda, y la prueba de McNemar se conserva donde decidió una regla registrada. No se prerregistró ningún margen de equivalencia, por lo que un valor p grande nunca se lee como prueba de ausencia de efecto.

Evidencia

En el brazo primario de QuixBugs con el modelo 1.5B, 156 de los 169 mensajes de feedback consumidos, el 92,3%, mostraron el campo fijo de salida esperada (descripción del registro en Zenodo y sección 6 del artículo, hecho answer-leakage-study-08). En HumanEvalFix, al menos 316 de las 417 rondas de feedback out-of-band, el 75,8%, expusieron la aserción específica de la tarea, y 289 de las 417, el 69,3%, expusieron una igualdad explícita con un valor esperado; ambas son cotas inferiores (Tabla 4 del artículo, página 8, hecho answer-leakage-study-09). El diseño más antiguo emitía la salida bruta de pytest, que nunca se examinó, así que sigue sin resolverse (sección 8 del artículo, hecho answer-leakage-study-10).

La regla de invalidación prerregistrada se activó. Un control obsoleto (stale), nominalmente inerte, superó la línea base ciega en 0,138, con una p exacta de McNemar pareada de 0,0018; el análisis posterior a la campaña, honesto con el agrupamiento, corroboró la decisión con una prueba de signos a nivel de tarea con p de 0,0117 y un intervalo bootstrap pareado y agrupado por tarea de [0,046; 0,241] (descripción del registro en Zenodo y sección 6 del artículo, página 7, hecho answer-leakage-study-11). La interpretación causal primaria de la campaña es, por lo tanto, inválida.

Los brazos exploratorios muestran lo que queda una vez eliminada la filtración. El feedback rico out-of-band resolvió 33 de las 87 celdas de tarea y semilla; el verificador que solo dice si pasó o falló resolvió 21 de 87; el bucle solo de andamiaje resolvió 21 de 87; la línea base ciega resolvió 22 de 87. El contraste entre feedback rico y pasó o falló fue de +0,138, con una p de la prueba de signos de 0,0020 y un intervalo bootstrap de [0,069; 0,230]. Los dos brazos limpios no mostraron ninguna ganancia detectable sobre la línea base con la precisión alcanzada, y el artículo es explícito en que esto no es un resultado de equivalencia (descripción del registro en Zenodo y Tablas 2 y 3 del artículo, página 7, hecho answer-leakage-study-12).

La ejecución almacenada de QuixBugs es recomputable mediante análisis forense: en las 870 filas, la autoauditoría no encontró ninguna discrepancia de modelo en la primera llamada, y ninguno de los 870 desenlaces divergió cuando las soluciones almacenadas se volvieron a ejecutar en un subproceso nuevo; las 2.875 llamadas al modelo que produjeron reparaciones no se repitieron (sección 6 del artículo, página 8, y sección 11, página 12, hecho answer-leakage-study-18). El corpus de HumanEvalFix no lo es: una ejecución posterior con el modelo 3B sobrescribió 783 archivos de transcripción referenciados por filas de resultado, de modo que sus tasas históricas exactas de filtración son irrecuperables y se reportan como cotas inferiores conservadoras (descripción del registro en Zenodo y sección 7 del artículo, hecho answer-leakage-study-13).

Los límites están declarados en el propio artículo. Los experimentos cubren la reparación de Python a nivel de función y una sola familia de modelos, principalmente el modelo 1.5B servido mediante una etiqueta mutable de Ollama; la resolución final en QuixBugs es aproximadamente un 95% colineal con pasar el único caso visible; los brazos limpios se especificaron después de la campaña; y el hallazgo negativo es una falsación de la evidencia anterior del propio programa, no una afirmación universal de que la verificación sin filtración sea ineficaz (secciones 9 y 13 del artículo, hecho answer-leakage-study-19). El estudio usó benchmarks públicos y modelos servidos localmente, sin participantes humanos y sin datos personales (sección 12 del artículo, hecho answer-leakage-study-26).

Tecnologías

Los bancos corrieron en local: modelos Qwen2.5-Coder servidos mediante Ollama, ejecución de pruebas en Python en un subproceso aislado con un tope de CPU, y tracebacks de pytest o la plantilla de resultado del propio banco como canal de feedback. El paquete de análisis es Python de biblioteca estándar que regenera la tabla de brazos y vuelve a ejecutar cada solución almacenada; el repositorio contiene 3.389 entradas de manifiesto SHA-256 (sección 11 del artículo, hecho answer-leakage-study-24). El repositorio de evidencia sigue siendo privado, y el registro dice que no debe describirse como un artefacto de reproducibilidad público y completo (hecho answer-leakage-study-21).

Qué demuestra

Definir. La unidad, el contraste primario, la familia de brazos y la regla que invalidaría el diseño se escribieron antes de los datos. Cuando la regla se activó, el resultado principal se descartó en lugar de justificarse.

Instrumentar. La evaluación no se detuvo en el marcador. Se auditaron las cadenas devueltas al modelo, la auditoría se vinculó a las filas brutas mediante hash, y los controles de integridad corrieron junto al verificador real. Esa es la disciplina detrás del segundo paso de NASCIA: construir el banco primero, para que una mejora pueda distinguirse de una respuesta filtrada.

Integrar. La procedencia se trata como parte del estimando. Cada fila nombra su ejecución y su modelo, guarda la solicitud y la respuesta exactas y vincula cada mensaje consumido por SHA-256, de modo que una sobrescritura posterior es detectable y su daño puede acotarse en lugar de adivinarse.

Transferir. El artículo cierra con un protocolo mínimo de seis puntos para cualquier estudio futuro: pasó o falló como feedback por defecto, un único conjunto inmutable de candidatos para todo selector, presupuestos equiparados, identificadores inmutables, vinculación por hash verificada antes de agregar y una recomputación nueva antes de cualquier narrativa causal. Es la misma forma del runbook que NASCIA deja con el cliente: las pruebas, los límites y las palabras, todo por escrito.