Riepilogo Tecnico: Per Aggiungere è Macchina, Per Eliminare è Umano

Problema

Mentre i Large Language Models (LLM) funzionano sempre più come agenti di codifica capaci di risolvere problemi e generare pull request, le evidenze suggeriscono che le loro patch spesso degradano la manutenibilità del codice. Un modo specifico e sistematico di fallimento identificato in questo lavoro è l'evitamento della cancellazione (deletion avoidance): la tendenza dei modelli a mantenere codice che un'intesa modifica richiederebbe invece di rimuovere. Invece di eseguire un'edit sottrattiva, i modelli spesso preservano la logica obsoleta e deviano l'esecuzione attorno ad essa utilizzando guardie condizionali o fallback. Questo comportamento, denominato Guard-and-Go, permette alle patch di superare le suite di test esistenti (che raramente verificano la rimozione del codice) lasciando però i codebase gonfi e più difficili da mantenere. Il paper sostiene che gli attuali benchmark di valutazione, come SWE-bench Verified, possano sopravvalutare la prontezza dei modelli per la produzione perché non penalizzano queste strategie di non-rimozione.

Metodologia

Lo studio impiega un approccio multifasettico combinando l'analisi empirica di benchmark esistenti, la creazione di un benchmark diagnostico specializzato e un intervento di post-training controllato.

1. Analisi Empirica di SWE-bench Verified

Gli autori hanno analizzato le cinque principali sottomissioni alla classifica di SWE-bench Verified (GLM-4.6, GPT-5, Kimi-K2, Opus-4.5 e Salesforce SAGE) utilizzando uno scaffold OpenHands coerente per controllare la variazione dell'agente.

• Metrica: Il richiamo della cancellazione (deletion recall) è stato calcolato confrontando le patch dei modelli con le patch degli sviluppatori, misurando la quota di righe eliminate dallo sviluppatore che il modello ha anch'esso rimosso.
• Controllo di Localizzazione: Lo studio ha distinto tra il non trovare il codice (errore di localizzazione) e il non rimuoverlo (errore di esecuzione) controllando file, ambito (funzione/classe/modulo) ed esatta modifica della riga.
• Classificazione della Strategia: Un classificatore basato su LLM ha categorizzato le patch passate in "Delete-and-Replace" (Elimina e Sostituisci), "Guard-and-Go" (mantenimento della logica con una guardia) o "Non-reference alternative" (alternativa non di riferimento).

2. Retrofitting Sensibile alla Cancellazione

Per determinare se i test passati validino effettivamente la rimozione del codice, gli autori hanno retrofittato 34 task ad alta densità di cancellazione da SWE-bench Verified con nuovi test FAIL_TO_PASS (F2P). Questi test falliscono esplicitamente se il codice target rimane nel file, isolando il requisito di rimozione dalle altre specifiche comportamentali.

3. Benchmark CanItDelete

Per isolare il comportamento di cancellazione da fattori confondenti come la difficoltà di localizzazione o la necessità di codice additivo, gli autori hanno curato CanItDelete.

• Costruzione: 200 task estratti da commit reali dove l'intera modifica richiesta era una cancellazione (nessuna aggiunta). I task sono stati selezionati dai primi 100 repository Python e JavaScript con più stelle, classificati per complessità strutturale (dimensione pre-edit, righe eliminate e blocchi di cancellazione).
• Valutazione: Un valutatore deterministico e consapevole delle occorrenze assegna punteggi in base alla totale assenza del target, alla preservazione della struttura non correlata e all'assenza di aggiunte che influenzino il comportamento.
• Scala Diagnostica: Il benchmark utilizza quattro modalità cumulative per diagnosticare i punti di fallimento:
  1. Vanilla: Richiesta standard in stile sviluppatore.
  2. Explicit Deletion (Cancellazione Esplicita): L'istruzione proibisce guardie o fallback.
  3. Region Pointer (Puntatore di Regione): Identifica le funzioni/regioni rilevanti.
  4. Exact Lines (Righe Esatte): Fornisce gli intervalli esatti da rimuovere.

4. Intervento di Post-Training (Prova di Concetto)

Un modello con 7 miliardi di parametri è stato aumentato con un mixture di post-training focalizzato sulla cancellazione.

• Dati: 12.821 esempi di cancellazione (10.000 a livello di file e 2.821 a livello di repository) sono stati aggiunti al set di addestramento. Questi esempi hanno contribuito con 112,1M di token al mixture di 15,9B di token, costituendo circa lo 0,7% del totale dei token.
• Valutazione: Il modello è stato testato su CanItDelete, SWE-bench Verified, CanItEdit ed EditBench per misurare il miglioramento mirato e potenziali regressioni.

Risultati Chiave

1. Prevalenza dell'Evitamento della Cancellazione

• Basso Richiamo: Anche sui 197 task risolti da tutti e cinque i modelli, il richiamo della cancellazione variava dal 65,2% al 71,7%. I modelli hanno lasciato in sede dal 28,3% al 34,8% delle cancellazioni richieste.
• Localizzazione vs. Esecuzione: I modelli hanno individuato correttamente il file corretto per >92% delle cancellazioni e l'ambito circostante per ~70%, ma hanno rimosso la riga esatta solo nel 44,6% - 51,6% dei casi. Il divario è principalmente un fallimento di esecuzione, non di localizzazione.
• Dominanza del Guard-and-Go: Tra i 1.703 accoppiate task-modello passate analizzate, 494 (29,0%) seguivano il pattern Guard-and-Go, dove il modello mantiene la logica rimossa dallo sviluppatore e aggiunge un bypass condizionale. Queste patch erano in media il 61,1% più grandi della patch dello sviluppatore.

2. Gap di Valutazione

Quando 34 task ad alta densità di cancellazione sono stati rivalutati con controlli sensibili alla cancellazione:

• I tassi di risoluzione per quattro modelli di frontiera sono scesi dal 63,2% al 41,9% (un calo di 21,3 punti percentuali).
• Il 33,7% delle patch che superavano le suite di test originali manteneva il target di cancellazione validato.

3. Risultati di CanItDelete

• Varianza delle Prestazioni: Sui 200 task di sola cancellazione, i tassi di successo variavano dal 79,0% (Claude Opus 4.8) al 18,0% (modelli open più piccoli).
• Modalità di Fallimento: La cancellazione incompleta (lasciare il codice richiesto) ha rappresentato il 69,8% dei fallimenti tra i modelli. Tuttavia, man mano che i modelli miglioravano nel trovare i target, è emerso un secondo modo di fallimento: la sovra-cancellazione (over-deletion) (rimuovere codice oltre il confine del target).
• Impatto della Guida: Fornire gli intervalli di cancellazione esatti (la modalità "Exact lines") ha quasi eliminato la cancellazione incompleta per quattro dei cinque modelli, ma non ha risolto la sovra-cancellazione. Ad esempio, il successo di GPT-5.6 Sol è salito all'80,5%, ma ha comunque fallito il 16,5% dei task eliminando oltre gli intervalli specificati. Ciò indica una mancanza di controllo sul confine della cancellazione piuttosto che una mancanza di capacità di trovare il codice.

4. Intervento di Post-Training

Aggiungere la supervisione della cancellazione al mixture di post-training del modello da 7B:

• Ha ridotto la cancellazione incompleta su CanItDelete di 13,9 punti percentuali (dal tasso di fallimento dell'80,4% al 66,5%).
• Ha migliorato SWE-bench Verified di 5,3 punti e CanItEdit di 1,4 punti.
• Non ha introdotto regressioni significative in altri benchmark.
• Compromesso: L'intervento ha aumentato il tasso di sovra-cancellazione (cancellazione completa con edit invalidi), suggerendo che mentre il modello ha imparato a cancellare, fatica ancora con il dove fermarsi.

Significato e Rivendicazioni

Il paper sostiene che l'evitamento della cancellazione sia un comportamento sistematico e sottoutilizzato negli attuali LLM, piuttosto che un limite intrinseco. Gli autori sostengono che:

1. Gli attuali Benchmark sono insufficienti: Le metriche standard di superamento dei test mascherano il pattern "Guard-and-Go", portando a una sovrastima della prontezza dei modelli per la manutenzione del codice.
2. Il Controllo è il Collo di Bottiglia: I modelli possiedono la capacità di individuare il codice da cancellare, ma mancano del controllo per eseguire rimozioni precise e delimitate senza sovra-editing o aggiunta di guardie.
3. La Cancellazione è Apprendibile: La prova di concetto dell'intervento dimostra che il post-training mirato può ridurre l'evitamento della cancellazione e migliorare le prestazioni generali di editing del codice, suggerendo che il deficit sia dovuto alla rappresentazione dei dati (bias additivo nei dati di addestramento) piuttosto che all'architettura del modello.

Gli autori rimangono modesti riguardo all'ambito, osservando che l'intervento è stato testato su un singolo modello da 7B e che il compromesso della "sovra-cancellazione" indica che la completezza della cancellazione e il controllo del confine sono obiettivi di addestramento distinti che richiedono ulteriori ricerche per essere risolti simultaneamente su larga scala.