CodeTaste: Can LLMs Generate Human-Level Code Refactorings?

Il paper presenta CodeTaste, un benchmark che valuta la capacità degli agenti LLM di eseguire refactoring di codice, rivelando un divario significativo tra le loro soluzioni e le scelte umane che può essere ridotto attraverso una strategia di "proposta-implementazione".

L'essenziale

🍽️ CODETASTE: Gli Chef AI Sanno Cucinare un "Piatto Pulito"?

Immagina che scrivere codice sia come cucinare in una cucina professionale.
Fino a poco tempo fa, gli "Chef AI" (i modelli linguistici o LLM) erano bravissimi a aggiungere nuovi ingredienti o a creare un nuovo piatto da zero. Se gli chiedevi: "Fammi un panino con il prosciutto", lo facevano subito.

Ma c'era un problema: se dovevano riformattare la cucina, spostare i fornelli o riordinare i cassetti per renderla più efficiente, spesso facevano un disastro. Aggiungevano troppi oggetti, lasciavano il caos, creavano doppioni e rendevano la cucina difficile da pulire in futuro.

Gli umani, invece, quando vedono una cucina disordinata, fanno il refactoring: non cambiano il sapore del cibo (il comportamento del programma), ma riorganizzano tutto per renderlo più sicuro, veloce e facile da usare.

La domanda del paper è: Gli Chef AI sono capaci di fare un buon "refactoring" da soli, o hanno bisogno che qualcuno gli dica esattamente quale cassetto spostare?

Per scoprirlo, i ricercatori hanno creato CODETASTE, una sorta di "gara di cucina" molto severa.

---

🕵️‍♂️ Come hanno costruito la gara (CODETASTE)

Invece di inventare compiti a caso, i ricercatori hanno guardato nella "spazzatura" di GitHub (il posto dove gli sviluppatori salvano il codice) per trovare 100 grandi riorganizzazioni fatte da umani veri e propri.

Hanno creato un laboratorio virtuale dove:

1. Il Codice è la Cucina: Prendono un progetto reale (come un motore di un'auto o un sito web).
2. Le Regole sono i Controlli: Creano una lista di cose "brutte" da eliminare (es. "non usare più questo vecchio metodo") e cose "belle" da aggiungere (es. "usa questo nuovo metodo").
3. La Prova del Fuoco: L'AI deve modificare il codice. Alla fine, due cose devono succedere:
   • Il cibo deve essere ancora buono (i test automatici devono passare).
   • La cucina deve essere riordinata secondo le regole (le vecchie pratiche devono sparire).

🎮 Due Modi per Giocare

Hanno testato gli AI in due modalità diverse, come due tipi di sfide culinarie:

1. La Sfida "Ricetta Dettagliata" (Instructed Track)

• La situazione: Dai all'AI una ricetta precisa: "Prendi il file A, sposta la riga 10 nel file B, e rinomina la variabile X in Y".
• Il risultato: Gli AI più avanzati (come GPT-5) sono stati molto bravi. Hanno seguito le istruzioni alla lettera, riordinando la cucina quasi perfettamente (circa il 70% di successo).
• La metafora: Se gli dai un foglio con scritto esattamente cosa fare, sono ottimi esecutori.

2. La Sfida "Cosa C'è da Sistemare?" (Open Track)

• La situazione: Dai all'AI solo un consiglio vago: "Questa cucina è un po' disordinata, sistemala un po'". Non dici cosa cambiare, solo dove guardare.
• Il risultato: Qui è andato tutto in fumo. Gli AI hanno ottenuto punteggi bassissimi (meno dell'8%).
• Cosa hanno fatto: Invece di riorganizzare la struttura, hanno fatto cose inutili.
  • Hanno corretto un errore di battitura in un nome (come se avessero cambiato il colore di un coltello invece di spostare il forno).
  • Hanno creato "scorciatoie" brutte (come mettere un pezzo di nastro adesivo invece di riparare il muro).
  • Hanno ignorato il problema principale.
• La metafora: Se chiedi a un cuoco di "migliorare la cucina" senza specificare, lui potrebbe pulire il pavimento ma dimenticare che il frigorifero è rotto. Non capiscono l'intento umano profondo.

💡 Le Scoperte Sorprendenti

1. Il "Piano" aiuta: Se si chiede all'AI di prima pensare a un piano ("Ok, prima sposto i cassetti, poi cambio le luci") e poi agire, le cose vanno meglio. È come se l'AI si fermasse a disegnare la pianta della cucina prima di toccare un solo mattone.
2. Scegliere il migliore: Se l'AI genera 5 piani diversi e un "giudice" (un altro AI molto intelligente) sceglie quello migliore, il risultato migliora ulteriormente.
3. Costa caro: Per fare un buon lavoro, gli AI più bravi consumano molta più energia e denaro rispetto a quelli che fanno cose superficiali. Riorganizzare bene costa, ma ne vale la pena.

🏁 La Conclusione

Il paper ci dice una cosa importante: Oggi gli AI sono bravi a seguire ordini, ma pessimi a prendere decisioni autonome su come migliorare le cose.

Se vuoi che un AI riscriva il tuo codice per renderlo migliore nel tempo, non puoi dirgli solo "fai di meglio". Devi dirgli esattamente cosa fare. Altrimenti, rischia di creare un codice che funziona, ma che è pieno di "debiti tecnici" (problemi nascosti) e che sarà un incubo da mantenere in futuro.

CODETASTE è quindi un nuovo righello per misurare quanto gli AI siano davvero pronti a diventare dei veri "architetti del software" e non solo dei "muratori" che seguono le istruzioni.

In sintesi con una metafora finale:

Gli AI attuali sono come automobili a guida autonoma molto avanzate: se gli dici "vai dritto fino al semaforo rosso", lo fanno perfettamente. Ma se gli dici "trova il percorso più sicuro e bello per arrivare a casa", spesso si perdono, prendono scorciatoie pericolose o finiscono in un vicolo cieco. CODETASTE ci aiuta a capire quanto manca per insegnare loro a guidare con l'intuito di un umano.

Sommario tecnico

Ecco un riassunto tecnico dettagliato del paper CODETASTE: Can LLMs Generate Human-Level Code Refactorings? in italiano.

1. Il Problema

Gli agenti basati su Large Language Models (LLM) dimostrano capacità notevoli nella generazione di codice funzionante e nella risoluzione di issue. Tuttavia, esiste un problema critico: le soluzioni generate tendono ad accumulare complessità, duplicazione e "debito tecnico architetturale" nel tempo. A differenza degli sviluppatori umani, che utilizzano il refactoring (trasformazioni di programma che preservano il comportamento ma migliorano struttura e manutenibilità) per mantenere il codice pulito, gli agenti attuali faticano a:

1. Eseguire refactoring in modo affidabile su larga scala.
2. Identificare autonomamente quali refactoring siano necessari in un codice esistente, senza istruzioni esplicite.

I benchmark esistenti (come RefactorBench o SWE-Refactor) sono limitati: coprono solo piccoli scope (spesso file singoli), si basano su test sintattici e non valutano la capacità dell'agente di scoprire autonomamente la necessità di un refactoring.

2. Metodologia: CODETASTE

Gli autori introducono CODETASTE, un nuovo benchmark progettato per colmare queste lacune, basato su cambiamenti reali multi-file estratti da repository open-source.

Pipeline di Costruzione del Benchmark

1. Discovery dei Commit: Viene analizzato un vasto dataset di commit GitHub (2023-2025) per identificare refactoring su larga scala effettuati da umani. Un pipeline a tre stadi (filtraggio per parole chiave, pre-filtraggio per accessibilità e dimensione, scoring tramite LLM) seleziona 100 istanze di alta qualità.
2. Generazione del Task: Per ogni istanza, viene generata una descrizione del task strutturata come un issue GitHub.
3. Ambiente di Esecuzione: Per ogni task, viene creato un ambiente containerizzato riproducibile che include il repository, le dipendenze e gli script per eseguire i test. Questo garantisce che le modifiche non rompano la funzionalità esistente.
4. Generazione delle Regole (Static Analysis): Invece di confrontare solo il codice generato con quello "golden", il sistema genera regole di analisi statica (usando OpenGrep con ragionamento sul flusso di dati simbolico) che catturano l'intento semantico del refactoring (pattern da rimuovere e pattern da introdurre).

Track di Valutazione

Il benchmark valuta gli agenti su due percorsi complementari:

• Instructed Track (Istruito): L'agente riceve una descrizione dettagliata del refactoring da eseguire. Valuta la capacità di implementare istruzioni complesse.
• Open Track (Aperto): L'agente riceve solo un'area di focus generica (es. "migliora l'organizzazione interna") senza sapere esattamente cosa cambiare. Valuta la capacità di scoprire autonomamente il refactoring necessario, simulando scenari reali di debito tecnico.

Metriche di Valutazione

• Correttezza Funzionale (PASS): Il patch generato deve far passare i test del repository.
• Instruction Following Rate (IFR): Misura quanto il codice generato rispetta le regole di analisi statica (pattern corretti introdotti e pattern errati rimossi).
• Alignment Score (A): Un punteggio composto che moltiplica la correttezza funzionale per l'IFR (A = PASS × IFR). Questo assicura che un refactoring sia premiato solo se è sia corretto che strutturale.
• Precision: Misura se l'agente ha introdotto modifiche non necessarie oltre al refactoring richiesto.

3. Risultati Sperimentali

Lo studio ha testato modelli all'avanguardia (GPT-5.2, GPT-5.1 Mini, Claude 4.5 Sonnet, Qwen3 Coder).

Track Istruito

• Gli agenti performano bene quando le istruzioni sono dettagliate.
• GPT-5.2 eccelle con un Alignment Score del 69.6%, superando significativamente gli altri modelli (Sonnet 4.5: 32.4%, Qwen3: 11.8%).
• Tuttavia, anche i modelli migliori mostrano un divario nella correttezza funzionale (PASS): GPT-5.2 raggiunge il 76% di test passanti, mentre gli altri scendono sotto il 50%. Questo suggerisce che, anche con istruzioni chiare, mantenere la correttezza del codice su larga scala è difficile.

Track Aperto (La sfida principale)

• C'è un divario enorme quando gli agenti devono scoprire il refactoring autonomamente.
• L'Alignment Score crolla drasticamente: il modello migliore (GPT-5.2) raggiunge solo il 7.7% nel modo "Direct" (esecuzione diretta).
• Strategia Proposta-Poi-Implementa: Introdurre una fase di pianificazione ("Plan Mode") dove l'agente genera un piano prima di scrivere codice, raddoppia quasi il punteggio (fino al 14.1% per GPT-5.2).
• Selezione Oracolo: Se l'agente genera più piani e un "giudice" (LLM con conoscenza completa) ne seleziona il migliore ("Oracle Multiplan"), il punteggio sale ulteriormente al 19.4%.
• Nonostante questi miglioramenti, i punteggi restano molto lontani dalle scelte umane, indicando che la capacità di giudizio autonomo su cosa refattorizzare è ancora un collo di bottiglia fondamentale.

Casi di Studio (Failure Modes)

Nel track aperto, gli agenti tendono a:

1. Fissarsi su dettagli superficiali (es. correggere un typo) ignorando l'architettura.
2. Usare soluzioni "hacky" o shims di compatibilità invece di rifattorizzare.
3. Eseguire sostituzioni di stringhe distruttive che rompono il codice.
4. Lavorare su aspetti del sistema completamente diversi da quelli richiesti.

4. Contributi Chiave

1. CODETASTE Benchmark: Il primo benchmark su larga scala per refactoring multi-file che combina test di esecuzione, analisi statica semantica e due modalità di valutazione (istrutta e aperta).
2. Valutazione Realistica: Dimostra che la capacità di generare patch funzionanti non equivale alla capacità di mantenere la qualità del codice a lungo termine.
3. Analisi del Gap: Evidenzia che mentre gli agenti possono seguire istruzioni complesse, mancano gravemente di "giudizio architetturale" autonomo per identificare e pianificare refactoring necessari.
4. Strategie di Miglioramento: Dimostra che la decomposizione "proponi-poi-implementa" e la selezione di piani multipli migliorano significativamente l'allineamento con le scelte umane.

5. Significato e Implicazioni

Il paper conclude che, sebbene gli agenti di codifica siano diventati strumenti potenti per la generazione di codice, non sono ancora pronti per sostituire i sviluppatori umani nella gestione della qualità del codice a lungo termine e del debito tecnico. La capacità di riconoscere autonomamente quando il codice è diventato non manutenibile e di decidere quali trasformazioni applicare rimane una sfida aperta.

CODETASTE fornisce un target di valutazione rigoroso e un segnale di preferenza per allineare i futuri agenti di codifica non solo alla funzionalità, ma anche alla manutenibilità e alla struttura del codice, elementi cruciali per lo sviluppo software sostenibile.