Un paper di un team ByteDance mostra che i coding agent hanno già dentro di sé una mappa di ciò che è rilevante nel codice che leggono. Non serve un classificatore esterno per decidere cosa tenere e cosa scartare: basta una piccola testa che legge le rappresentazioni interne del modello e decide, riga per riga, se tenerla o tagliarla.

SWE-Pruner Pro funziona così: quando l’agente legge l’output di un tool, una testa leggera trasforma le sue rappresentazioni interne in un’etichetta “tieni” o “pota” per ogni riga, con un embedding che tiene conto della lunghezza dell’output. Su due modelli open-weight e quattro benchmark multi-turno, il risparmio arriva al 39% dei token di prompt e completion mantenendo la qualità (dati dichiarati nel paper, non verificati da noi). Su MiMo-V2-Flash il pruning migliora persino i risultati: +3,8% su SWE-Bench Verified e +2,2 punti su Oolong.

Perché ti riguarda. Se usi agenti di coding su codebase lunghe, il contesto è il collo di bottiglia. Ogni file letto, ogni output di tool si accumula nella finestra e costa token. Un sistema che pota il contesto dall’interno del modello, senza appesantire la pipeline con un classificatore separato, riduce costi e latenze dove fanno più male. È particolarmente rilevante per chi fa refactoring o debugging su progetti grandi, dove le sessioni si allungano e il contesto cresce fino a saturare la finestra. L’overhead di token negli agenti di coding è un problema concreto che abbiamo già visto da vicino.

Il codice è pubblico su GitHub, ma non l’abbiamo testato.

Nel dettaglio

Cosa c’era prima.

I coding agent che lavorano su codebase reali accumulano contesto a ogni passo. L’agente legge un file, esegue una ricerca, ispeziona una directory: ogni output finisce nella finestra di contesto e resta lì per il resto della sessione. Su progetti grandi, la finestra si satura in fretta, i costi salgono e la qualità del ragionamento peggiora, perché il modello deve districarsi fra migliaia di righe di cui molte irrilevanti.

La soluzione esistente, chiamata SWE-Pruner, aggancia un classificatore esterno al modello: un modello separato legge l’output del tool e decide cosa tenere e cosa scartare. Funziona, ma aggiunge un componente in più, con i suoi costi e le sue latenze.

Cosa cambia.

I ricercatori di ByteDance hanno scoperto che il modello principale, quello che fa da agente, codifica già nelle sue rappresentazioni interne un’indicazione di rilevanza. Quando legge l’output di un tool, i suoi strati intermedi “sanno” quali righe contano e quali no. Basta una testa leggera, un piccolo modulo aggiunto sopra il modello esistente, che legge quelle rappresentazioni e produce un’etichetta binaria per ogni riga: tieni o pota.

La testa include anche un embedding sensibile alla lunghezza dell’output, perché il giudizio su cosa è rilevante cambia se il tool restituisce 10 righe o 1.000. Questo dettaglio conta: un classificatore esterno trattava tutti gli output allo stesso modo, mentre l’agente adatta il proprio filtro alla scala del materiale.

I numeri, nel loro contesto.

Il paper testa SWE-Pruner Pro su due backbone open-weight e quattro benchmark multi-turno. Il risparmio massimo dichiarato è il 39% dei token di prompt e completion, con un overhead di inferenza che i ricercatori descrivono come “limitato” senza quantificarlo in modo che possiamo verificare dall’abstract. Su MiMo-V2-Flash, uno dei due backbone, il pruning non si limita a risparmiare: migliora i risultati, con +3,8% su SWE-Bench Verified e +2,2 punti su Oolong, un benchmark di contesto lungo.

Il fatto che potare il contesto migliori la qualità non è controintuitivo come sembra. Un contesto ingombro di righe irrilevanti distrae il modello e peggiora le sue decisioni. Meno rumore, segnale più pulito.

Quanto fidarsi.

I numeri vengono dal paper, non da una valutazione indipendente. I benchmark sono quattro, i backbone due: è un campione rispettabile per un paper di ricerca, ma non dice come si comporterebbe su un modello diverso o su una codebase con caratteristiche diverse. L’overhead di inferenza è descritto come “limitato” ma non quantificato in modo verificabile nell’abstract. Il codice è pubblico su GitHub, quindi chi vuole può riprodurre o verificare.

Cosa farne.

Se costruisci o configuri agenti di coding per uso reale, il punto pratico è che il contesto va gestito anche a valle: potare quello che l’agente ha già letto e non serve più, non solo decidere a monte cosa far leggere. SWE-Pruner Pro suggerisce che il modello stesso è la fonte migliore per quel giudizio, e che un classificatore esterno può essere ridondante. Per chi usa agenti di coding pronti all’uso, la lezione resta utile anche senza implementare il sistema: quando una sessione si allunga, compattare il contesto manualmente (riassumendo cosa è emerso e scartando gli output grezzi) è il gesto che questo paper automatizza dall’interno.