Un desarrollador observó durante un mes a los agentes en su código: el árbol de archivos cuesta más que el JSON

Hace un año, el autor del texto en Habr copiaba los archivos a la ventana del chat uno por uno. Hoy los agentes leen su proyecto por sí solos a través de un servidor MCP, y él pasó un mes observando qué incluyen exactamente en el contexto. Las conclusiones son prácticas. El árbol de archivos en texto cuesta más que el JSON, la carpeta build no se debe excluir por su nombre, es posible ocultar las contraseñas de tal modo que el código deje de funcionar, y un agente sin supervisión administra el contexto de forma mucho más derrochadora de lo que cabría esperar.

El artículo original solo está disponible como anuncio, así que a continuación se analizan las tesis planteadas y la lógica de ingeniería que hay detrás. Conviene consultar las mediciones exactas del autor en la fuente original.

Por qué el árbol cuesta más que el JSON

A primera vista parece justo al revés. El árbol con sangrías y pseudográficos se lee fácilmente a simple vista, mientras que el JSON, con sus comillas, llaves y claves repetidas, parece redundante. Pero el modelo cuenta tokens, no caracteres. Los símbolos especiales de ramificación, las largas cadenas de espacios y los prefijos de ruta repetidos se tokenizan de forma poco eficiente. Esta es nuestra suposición sobre el mecanismo; el autor pudo explicarlo de otra manera. La conclusión en sí conviene comprobarla en el propio repositorio: en un proyecto grande, la diferencia de coste crece a medida que aumenta el número de archivos.

En este punto MCP desempeña un papel especial. El protocolo convierte la lectura del proyecto en un conjunto de llamadas a herramientas: lista de archivos, contenido, búsqueda. El formato de la respuesta de cada una de esas llamadas entra completo en el contexto, y su coste se paga en cada petición del agente.

La carpeta build y las contraseñas

La segunda lección tiene que ver con el filtrado. La regla «omitir las carpetas llamadas build» parece razonable hasta que aparece en el proyecto un directorio con ese mismo nombre que contiene código fuente, y no artefactos de compilación. Es más fiable fijarse en lo que hace la carpeta: si figura en .gitignore, si la genera la compilación, cuánto hace que cambió por última vez.

Con los secretos es más complicado. Si simplemente se elimina la línea con la contraseña, la configuración deja de poder analizarse y el agente empieza a arreglar lo que él mismo ha roto. La opción que funciona es otra: sustituir el valor por un marcador de posición y conservar la estructura del archivo, la clave y el tipo de dato. Así el código sigue siendo legible y el secreto real queda fuera del contexto.

El agente sin supervisión

El autor describe con brevedad la cuestión más curiosa: qué hace el agente con el contexto cuando nadie lo vigila. Los síntomas típicos los conoce cualquiera que haya lanzado sesiones largas: relectura de los mismos archivos, carga de directorios innecesarios, ventana inflada por resultados antiguos de herramientas. Cada uno de esos pasos cuesta tokens y empeora la calidad de las respuestas, porque la señal útil se ahoga en el ruido.

• Formato de descripción del proyecto: el árbol de texto cuesta más que el JSON.
• Filtros: el nombre de la carpeta no sirve como único criterio.
• Secretos: enmascarar los valores en lugar de eliminar líneas.
• Transporte: el servidor MCP como punto único de control sobre lo que ve el agente.
• Riesgo: crecimiento descontrolado del contexto en sesiones largas.

Por dónde empezar a revisar tu proyecto

Primero, comprueba qué se envía realmente al contexto. Si tu servidor MCP o la capa del agente no registra el volumen de las respuestas, añade un contador de tokens en cada llamada. Sin él, no hay nada que optimizar.

Después, compara formatos. Pasa el mismo repositorio por el árbol y por un JSON compacto y compara el número de tokens. A continuación, revisa las reglas de exclusión: básate en .gitignore y en los indicios de archivos generados, no en una lista de nombres.

Por último, aplica el enmascaramiento de secretos antes de enviar los datos al agente, no después. Comprueba que la configuración enmascarada sigue pasando por el analizador. Y fija un presupuesto para el agente: un límite al tamaño del contexto y al número de relecturas de un mismo archivo. Así, un mes de observación se convierte en un conjunto de reglas y no en una sorpresa puntual.