Resumen Técnico: ¿Qué contexto necesita realmente un agente de codificación para actuar?

Planteamiento del problema

Los agentes de codificación modernos poseen ventanas de contexto lo suficientemente grandes como para contener repositorios de código completos, sin embargo, la evidencia sugiere que gran parte de este contexto no se utiliza. Aunque se emplea con frecuencia la generación aumentada por recuperación (RAG) y andamiajes sofisticados para gestionar el contexto, los benchmarks como ContextBench indican que estos sistemas complejos apenas superan a los baselines triviales. La pregunta central abordada no es cuánto contexto puede contener un agente, sino qué contexto mínimo es realmente necesario para que un agente edite código con éxito y en qué representación.

Los autores distinguen entre dos subproblemas que a menudo se confunden en el diseño de agentes:

1. Encontrar (Find): Localizar las funciones o archivos específicos donde debe realizarse el trabajo.
2. Actuar (Act): Dado el lugar, poseer la información suficiente para realizar la edición correctamente.

Este estudio aísla la fase de Actuar. Al mantener la localización fija (utilizando un oráculo para proporcionar los archivos exactos de "gold-standard" que deben ser editados), los autores varían únicamente la representación de ese código para determinar el contexto mínimo requerido para la resolución.

Metodología

Entorno experimental: resolve@cost

Los autores construyeron un instrumento auditado para medir las tasas de resolución frente a los costes de contexto.

• Dataset: 70 instancias de múltiples archivos de SWE-bench Verified (tras excluir una instancia donde el parche de oro falló su propia validación de entorno).
• Localización por Oráculo: Para aislar los efectos de la representación de los errores de recuperación, cada "brazo" (condición) experimental recibe exactamente el mismo conjunto de archivos de cambio de oro. La única variable es cómo se renderiza el contenido de esos archivos.
• Agente: Una ejecución de un solo paso (single-shot) de Claude Sonnet 4.6 (Temperatura 0, máximo 8000 tokens). El agente genera bloques SEARCH/REPLACE, que se convierten en diffs unificados mediante un constructor determinista (difflib) y se verifican mediante un harness de Docker.
• Validación:
  • Puerta de Expresibilidad: Antes de cualquier llamada al agente, se verifica que cada línea eliminada o ancla insertada en el parche de oro esté presente de forma literal en el contexto renderizado para todos los brazos.
  • Determinismo: Los parches se construyen de forma determinista para evitar confusiones derivadas de la generación de diffs no reproducible.
  • Pre-registro: Las hipótesis y los protocolos se congelaron antes de la recolección de datos.

Brazos de Representación

El estudio compara tres representaciones principales para los archivos modificados de oro:

1. oracle_full: Los archivos fuente completos y sin modificar.
2. oracle_tier: Una representación estructurada donde el código que no es el foco (non-locus) se renderiza como esqueletos UML (estructuras de clases) y firmas de métodos, mientras que el foco del cambio permanece completo.
3. oracle_keep_drop: Un enfoque binario donde el código que no es el foco se elimina por completo, dejando solo las funciones/clases específicas que se están editando.

Sondas de Comportamiento (El límite "Find/Act")

Para probar si las representaciones comprimidas portan señal accionable, los autores utilizaron sondas de comportamiento:

• Configuración: 15 clases de reserva de seaborn, pylint y pytest. Se crearon tres sondas (preguntas de comportamiento) para cada clase a partir de archivos de prueba.
• Tarea: El agente (Sonnet 4.6) lee una representación (Fuente Completa, Resumen de Frontera, Resumen de Modelo 3B o Firmas) y responde a la sonda.
• Evaluación: Un juez independiente (GPT-4o-mini) califica las respuestas.
• Control: Un resumidor de frontera (Sonnet 4.6) y un modelo pequeño (Qwen-3B) generaron resúmenes para asegurar que el fallo de la "suma" no se debiera a una mala calidad de la misma.

Resultados Clave

1. El contexto para "Actuar" es extremadamente mínimo

La hipótesis registrada ($H_2$) predecía que los niveles de representación estructurada (esqueletos UML/firmas) resolverían más problemas que un enfoque simple de mantener/eliminar (keep/drop). Esta hipótesis falló.

• Tasas de Resolución:
  • oracle_keep_drop: 25/70 resueltos (35.7%)
  • oracle_tier: 23/70 resueltos (32.9%)
  • oracle_full: 19/70 resueltos (27.1%)
• Significancia Estadística: La diferencia entre los niveles estructurados y el enfoque keep/drop es nula (McNemar $p=0.75$). Renderizar el código circundante como esqueletos UML no proporciona ningún beneficio mensurable sobre la eliminación directa cuando la localización es perfecta.
• Eficiencia de Coste: Los contextos comprimidos resuelven problemas con 3–3.7× menos tokens que los archivos completos.
  • Coste por resolución: ~19K tokens (keep/drop) frente a ~94K tokens (full files).

2. Los resúmenes en lenguaje natural no portan señal accionable

Las sondas de comportamiento revelaron una brecha masiva en la información accionable entre el código fuente y los resúmenes.

• Precisión: La fuente completa respondió al 60% (27/45) de las sondas de comportamiento. Los resúmenes en lenguaje natural (tanto de modelos de frontera como de 3B) respondieron solo un ~9% (4/45).
• Representación vs. Resumidor: La brecha es inherente a la clase de representación, no a la calidad del resumidor. Los resúmenes de frontera funcionaron de forma idéntica a los resúmenes del modelo 3B.
• Firmas: Las firmas de métodos + docstrings funcionaron ligeramente mejor que los resúmenes en prosa (6/45), pero aun así no lograron igualar al código fuente.
• Conclusión: Los resúmenes en lenguaje natural no responden a las preguntas de comportamiento que el código fuente sí responde; la "señal" reside en la estructura del código, no en la narrativa de los resúurnos.

3. No determinismo entre ejecuciones

Un hallazgo metodológico crítico concierne a la estabilidad de la inferencia de LLM a Temperatura 0.

• Observación: Volver a ejecutar el brazo keep/drop con protocolos de bytes idénticos (mismo modelo, mismos prompts, T=0) resultó en que aproximadamente el ~9% de los resultados por instancia cambiaran de estado (25/70 resueltos originalmente frente a 23/70 en la repetición).
• Implicación: Este ruido de fondo (~9%) limita la interpretación de los tamaños de efecto pequeños. Las diferencias de 1 a 2 instancias (como la hipótesis registrada $H_2$) son estadísticamente indistinguibles del ruido de la inferencia.

Contribuciones y Significado

El artículo reclama cuatro contribuciones principales:

1. Un Instrumento Auditado: Un marco resolve@cost con verificación de expresibilidad por instancia, construcción de parches determinista e hipótesis pre-registradas, asegurando que cada número sea trazable a artefactos brutos.
   2.Un Resultado Nulo Potenciado: Evidencia de que los niveles de representación estructurada (UML/esqueletos) no aportan ninguna señal de resolución adicional sobre el enfoque binario keep/drop bajo localización de oráculo. Esto desafía la suposición de que "más estructura" equivale a "mejor acción".
2. Una Descircularización del Límite Find/Act: Demostración de que el código fuente contiene aproximadamente 7× la señal accionable de los resúmenes en lenguaje natural. Crucialmente, un resumidor de frontera no puede cerrar esta brecha, lo que indica que la limitación es el formato de la representación, no la capacidad del resumidor.
3. Cautela Metodológica: La cuantificación de un ~9% de ruido de fondo en la inferencia de la API de un solo paso a T=0. Esto sugiere que muchos efectos pequeños reportados en la literatura de SWE-bench (incluyendo los propios resultados nulos de este estudio) pueden ser artefactos de la no determinidad en lugar de una señal real.

Alcance y Limitaciones

Los autores declaran explícitamente que sus conclusiones se aplican a agentes de un solo paso sin bucles de retroalimentación de ejecución. Reconocen que los agentes de múltiples turnos podrían recuperarse de un contexto comprimido leyendo más, pero en el régimen de un solo paso, el paso de "encontrar" debe ser perfecto (oráculo) y el contexto para "actuar" debe ser mínimo. El estudio no pretende decir que los resúmenes sean inútiles para la navegación (encontrar código), sino que son insuficientes para actuar (editar código) en comparación con el propio código fuente.

El artículo concluye que, para la tarea específica de editar código dada la ubicación correcta, el contexto mínimo requerido es el código que se está editando, y el contexto circundante (incluso en formas estructuradas) añade un valor insignificante mientras incurre en costes de tokens considerables.