Un paper de un equipo ByteDance muestra que los agentes de codificación ya tienen dentro de sí un mapa de lo que es relevante en el código que leen. No necesitas un clasificador externo para decidir qué mantener y qué descartar: basta una pequeña cabecera que lee las representaciones internas del modelo y decide, línea por línea, si mantenerla o podarla.

SWE-Pruner Pro funciona así: cuando el agente lee la salida de una herramienta, una cabecera ligera transforma sus representaciones internas en una etiqueta “mantener” o “podar” para cada línea, con un embedding que tiene en cuenta la longitud de la salida. En dos modelos open-weight y cuatro benchmarks multi-turno, el ahorro llega al 39% de los tokens de prompt y completion manteniendo la calidad (datos declarados en el paper, no verificados por nosotros). En MiMo-V2-Flash la poda incluso mejora los resultados: +3,8% en SWE-Bench Verified y +2,2 puntos en Oolong.

Por qué te importa. Si usas agentes de codificación en codebases grandes, el contexto es el cuello de botella. Cada archivo leído, cada salida de herramienta se acumula en la ventana y consume tokens. Un sistema que poda el contexto desde dentro del modelo, sin sobrecargar el pipeline con un clasificador separado, reduce costos y latencias donde más duele. Es particularmente relevante para quien hace refactoring o debugging en proyectos grandes, donde las sesiones se alargan y el contexto crece hasta saturar la ventana. El overhead de tokens en agentes de codificación es un problema concreto que ya hemos visto de cerca.

El código es público en GitHub, pero no lo hemos probado.

En detalle

Qué había antes.

Los agentes de codificación que trabajan en codebases reales acumulan contexto en cada paso. El agente lee un archivo, ejecuta una búsqueda, inspecciona un directorio: cada salida termina en la ventana de contexto y permanece allí para el resto de la sesión. En proyectos grandes, la ventana se satura rápidamente, los costos suben y la calidad del razonamiento empeora, porque el modelo debe navegar entre miles de líneas, muchas de las cuales irrelevantes.

La solución existente, llamada SWE-Pruner, engancha un clasificador externo al modelo: un modelo separado lee la salida de la herramienta y decide qué mantener y qué descartar. Funciona, pero añade un componente más, con sus costos y sus latencias.

Qué cambia.

Los investigadores de ByteDance descubrieron que el modelo principal, el que actúa como agente, ya codifica en sus representaciones internas una indicación de relevancia. Cuando lee la salida de una herramienta, sus capas intermedias “saben” qué líneas importan y cuáles no. Basta una cabecera ligera, un pequeño módulo añadido sobre el modelo existente, que lee esas representaciones y produce una etiqueta binaria para cada línea: mantener o podar.

La cabecera incluye también un embedding sensible a la longitud de la salida, porque el juicio sobre qué es relevante cambia si la herramienta devuelve 10 líneas o 1.000. Este detalle importa: un clasificador externo trataba todas las salidas igual, mientras que el agente adapta su propio filtro a la escala del material.

Los números, en su contexto.

El paper prueba SWE-Pruner Pro en dos backbone open-weight y cuatro benchmarks multi-turno. El máximo ahorro declarado es el 39% de los tokens de prompt y completion, con un overhead de inferencia que los investigadores describen como “limitado” sin cuantificarlo de forma que podamos verificar desde el resumen. En MiMo-V2-Flash, uno de los dos backbone, la poda no se limita a ahorrar: mejora los resultados, con +3,8% en SWE-Bench Verified y +2,2 puntos en Oolong, un benchmark de contexto largo.

El hecho de que podar el contexto mejore la calidad no es tan contraintuitivo como parece. Un contexto lleno de líneas irrelevantes distrae al modelo y empeora sus decisiones. Menos ruido, señal más limpia.

Cuánta confianza depositar.

Los números vienen del paper, no de una evaluación independiente. Los benchmarks son cuatro, los backbone dos: es una muestra respetable para un paper de investigación, pero no dice cómo se comportaría en un modelo diferente o en una codebase con características distintas. El overhead de inferencia se describe como “limitado” pero no se cuantifica de forma verificable en el resumen. El código es público en GitHub, así que quien quiera puede reproducir o verificar.

Qué hacer con esto.

Si construyes o configuras agentes de codificación para uso real, el punto práctico es que el contexto debe gestionarse también después: podar lo que el agente ya ha leído y no sirve, no solo decidir de antemano qué debe leer. SWE-Pruner Pro sugiere que el propio modelo es la mejor fuente para ese juicio, y que un clasificador externo puede ser redundante. Para quien usa agentes de codificación listos para usar, la lección sigue siendo útil incluso sin implementar el sistema: cuando una sesión se alarga, compactar el contexto manualmente (resumiendo lo que ha emergido y descartando las salidas brutas) es el gesto que este paper automatiza desde dentro.