← Últimos artículos
🤖 machine learning

The Working Set of a Coding Agent: Coherence Debt in Repository-Scale Tasks

Este artículo introduce el concepto de "deuda de coherencia" para demostrar que el éxito de los agentes de codificación a escala de repositorio depende primordialmente de la disponibilidad inmediata de los hechos contextuales requeridos en lugar de su distancia o la memoria paramétrica del agente, revelando que los agentes suelen fabricar soluciones cuando faltan hechos y que los entornos de evaluación actuales pueden diagnosticar erróneamente los fallos al centrarse en las operaciones de lectura en lugar de en la consistencia de los resultados generados.

Autores originales: Bardia Mohammadi, Lars Klein, Aman Chadha, Akhil Arora, Laurent Bindschaedler

Publicado 2026-08-18
📖 7 min de lectura🧠 Análisis profundo

Autores originales: Bardia Mohammadi, Lars Klein, Aman Chadha, Akhil Arora, Laurent Bindschaedler

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

En el mundo del software, una sola línea de código rara vez existe de forma aislada. Para cambiar un número en un archivo, un programador a menudo necesita saber cómo se usa ese número en otros tres archivos, qué configuraciones controlan dicho número y qué pruebas deben pasar para demostrar que el cambio es seguro. Esta red de conexiones es lo que hace que corregir un error o actualizar un sistema sea difícil; la respuesta correcta depende de hechos dispersos por todo el proyecto. Durante años, los investigadores han intentado construir agentes de inteligencia artificial que puedan navegar estas redes complejas, actuando como desarrolladores junior que pueden leer todo un código base, comprender las reglas y realizar las ediciones correctas. La esperanza ha sido que, si le damos a estos agentes de IA suficiente información sobre el proyecto, tendrán éxito. Pero un nuevo estudio sugiere que simplemente darle al agente más información no es toda la historia. El verdadero desafío no es solo tener los hechos disponibles, sino tener los hechos correctos disponibles en el momento exacto en que el agente intenta escribir una nueva línea de código.

Investigadores de varias instituciones, incluyendo el Instituto Max Planck para Sistemas de Software y la EPFL, se propusieron probar precisamente cómo estos agentes de IA manejan el flujo de información durante una tarea de programación. Trataron el proyecto como un sistema vivo donde el agente debe mantener constantemente un "conjunto de trabajo" de hechos en su mente: los requisitos de las pruebas actuales, los nombres de las herramientas importadas y las reglas sobre cómo debe comportarse el software. Plantearon una pregunta simple pero profunda: ¿qué sucede cuando un hecho necesario falta en la visión del agente? ¿Se detiene el agente y pide ayuda, o adivina? Y, ¿importa si el hecho está justo al lado de la edición o enterrado en una larga lista de instrucciones previas?

Para encontrar la respuesta, el equipo creó una serie de experimentos controlados. Construyeron librerías de software ficticias con reglas específicas que ningún IA había visto antes, asegurando que los agentes no pudieran confiar en el conocimiento memorizado. Luego, sometieron a los agentes a tareas de migración, como la actualización de una librería de una versión a otra, bajo diferentes condiciones. En algunas ejecuciones, se les dio a los agentes la descripción de la tarea pero sin acceso al código o a las reglas, obligándolos a depender enteramente de lo que habían aprendido durante su entrenamiento. En otras ejecuciones, los investigadores proporcionaron las reglas exactas y los archivos fuente justo al principio. También probaron qué sucedía cuando ocultaban deliberadamente piezas específicas de información, como un valor secreto necesario para calcular un resultado, para ver cómo reaccionaban los agentes.

Los resultados fueron crudos y claros. Cuando se les negaba el acceso a los hechos necesarios, los agentes no se limitaban a dejar de trabajar o a admitir que estaban bloqueados. En su lugar, continuaban actuando, a menudo con una confianza peligsa. Si faltaba un archivo, el agente inventaba uno nuevo. Si un valor era desconocido, adivinaba un número. Los agentes producían "trabajo erróneo" en lugar de "trabajo ausente". Fabricaban archivos y adivinaban valores, creando código que parecía completo pero que era fundamentalmente defectuoso. Este comportamiento significó que las herramientas estándar utilizadas para medir el éxito de un agente, que a menudo solo comprueban si el agente leyó un archivo, eran engañosas. Un agente podía leer un archivo que él mismo escribió, o leer un archivo que era irrelevante, y las herramientas lo contarían como "realizando el trabajo", a pesar de que el agente había perdido el hecho crucial que necesitaba.

El estudio también reveló que la ubicación de la información no importaba tanto como su presencia. Los investigadores probaron si hacía una diferencia que un hecho requerido se colocara al principio de una larga lista de instrucciones o justo al lado del lugar donde se realizaba la edición. Encontraron que, mientras el hecho estuviera presente en la visión del agente, este podía usarlo con la misma eficacia ya fuera al principio o al final de una ventana de contexto masiva. La distancia no degradaba la capacidad del agente para usar el hecho. Sin embargo, si el hecho era completamente retenido, el agente fallaba, independientemente de cuánta otra información tuviera. El daño era lineal: ocultar un hecho causaba que el agente fallara en las tareas específicas que dependían de ese hecho, pero no provocaba una cascada de fallos en partes no relacionadas del código.

Quizás el hallazgo más sorprendente se refirió a la capacidad de los agentes para admitir que estaban bloqueados. Los investigadores descubrieron que si un agente diría "no puedo proceder porque me falta un archivo" dependía enteramente de qué modelo de IA específico se estuviera utilizando. Algunos modelos, como uno llamado Opus, reportaban estar bloqueados en cada uno de los ensayos cuando faltaba un archivo. Otros, como Codex, nunca reportaban estar bloqueados; simplemente fabricaban el archivo faltante y continuaban. Esto sugiere que la capacidad de reconocer una brecha en el conocimiento no es un rasgo universal de los agentes de programación, sino un rasgo específico del modelo mismo. Para los sistemas que no admiten que están estancados, la "deuda de coherencia" —la brecha entre lo que el agente necesita y lo que sabe— permanece invisible hasta que el código final es revisado y se encuentra erróneo.

Los investigadores también descubrieron que la forma en que se organiza una tarea de programación importa más que el volumen bruto de información. Cuando dividieron una tarea estrechamente conectada entre múltiples agentes, la tasa de éxito disminuyó porque los agentes no podían mantener consistentes los hechos compartidos. Pero cuando dividieron tareas independientes, los agentes funcionaron igual de bien. Esto confirmó que el problema no es solo tener suficientes datos, sino mantener disponibles al mismo tiempo los hechos específicos que están vinculados entre sí. Si se le pide a un agente que cambie una configuración en un archivo, debe tener el valor actual de esa configuración y la regla de cómo interactúa con otros archivos en su visión inmediata.

Finalmente, el estudio analizó qué sucede cuando la información disponible para el agente es contradictoria. En algunos experimentos, los investigadores proporcionaron un documento de estándares escrito que decía una cosa, mientras que el código existente en el proyecto demostraba lo contrario. En todos los casos, los agentes siguieron el estándar escrito, incluso cuando el estándar prescribía una forma peor o más propensa a errores de escribir el código. Esto sugiere que, para estos agentes de IA, una regla escrita tiene más autoridad que el comportamiento real del software que se supone debe describir. Si el estándar está desactualizado, el agente reproducirá fielmente la regla obsoleta, haciendo que un documento caduco sea más peligroso que no tener ningún documento.

Las implicaciones de estos hallazgos son significativas para la forma en que construimos y evaluamos las herramientas de codificación de IA. Resulta que simplemente hacer la ventana de contexto más grande o darle al agente más memoria no garantiza el éxito. El factor crítico es asegurar que los hechos específicos que un agente necesita para realizar una edición estén presentes y sean consistentes en el momento en que escribe. Si a un agente le falta un hecho, no esperará; adivinará. Y si los hechos que se le dan son contradictorios, seguirá la regla escrita, incluso si esa regla es errónea. El estudio concluye que la mejor manera de construir estos sistemas no es solo alimentarlos con más datos, sino diseñar el entorno para que los hechos necesarios estén siempre disponibles y actualizados, y para verificar la salida del agente contra lo que realmente produjo, en lugar de asumir que leyó las cosas correctas. Los agentes no están fallando porque sean demasiado pequeños o lentos; están fallando porque son demasiado ansiosos por llenar los huecos cuando faltan los hechos.

¿Ahogado en artículos de tu campo?

Recibe resúmenes diarios de los artículos más novedosos que coincidan con tus palabras clave de investigación — con resúmenes técnicos, en tu idioma.

Probar Digest →