Technische Samenvatting: SWE-Refactor

Probleemstelling

Hoewel Large Language Models (LLM's) aanzienlijke capaciteiten hebben getoond in codegeneratie, vormt code-refactoring een specifieke uitdaging. Refactoring vereist precieze, semantiek-behoudende bewerkingen die de programmastructuur verbeteren zonder het gedrag te wijzigen. Deze taak vereist redeneren op repository-niveau, een begrip van complexe afhankelijkheden en iteratieve verificatie—vaardigheden die moeilijk te evalueren zijn en vaak buiten het bereik van huidige modellen liggen.

Bestaande benchmarks voor code-refactoring lijden aan vier kritieke tekortkomingen:

1. Beperkte scenario-dekking: Ze richten zich voornamelijk op atomische refactoring-typen (enkelvoudige transformaties) in plaats van de samengestelde refactorings (meerdere gecoördineerde transformaties) die gebruikelijk zijn in de echte wereld van softwareontwikkeling.
2. Gebrek aan automatische constructie: Veel benchmarks vertrouwen op handmatige curatie of door LLM's gegenereerde grondwaarheid (ground truth), wat leidt tot bias en schaalbaarheidsproblemen.
3. Onvoldoende context op repository-niveau: Bestaande datasets missen vaak de structurele informatie (bijv. klassenhiërarchieën, caller/callee-relaties) die nodig is voor een realistische beoordeling.
4. Ruis in de data: Veel benchmarks bevatten "onzuivere" commits waarbij refactoring wordt gemengd met bugfixes of het toevoegen van functies, wat het moeilijk maakt om de refactoring-capaciteiten van het model te isoleren en te evalueren.

Verder lijdt het veld aan een gebrek aan diversiteit in programmeertalen, waarbij de meeste recente benchmarks zich uitsluitend op Python richten, ondanks het feit dat Java een dominante taal is in enterprise-systemen.

Methodologie: SWE-Refactor

Om deze hiaten te adresseren, introduceren de auteurs SWE-Refactor, een benchmark op repository-niveau die is geconstrueerd uit real-world Java-projecten. De benchmark is gebouwd met behulp van een volledig geautomatiseerde vierstaps-pipeline:

1. Mining via Statische Analyse: De auteurs maken gebruik van RefactoringMiner, een AST-gebaseerde tool, om commits te extraheren die refactorings bevatten uit 18 veelgebruikte Java-projecten.
2. Curatie van Pure Refactorings: Met behulp van PurityChecker (een uitbreiding van RefactoringMiner) filtert de pipeline onzuivere wijzigingen (bijv. bugfixes) eruit om alleen "pure" refactorings over te houden. De auteurs hebben een willekeurige steekproef van 200 instanties handmatig geverifieerd om de betrouwbaarheid van de detectoren te bevestigen.
3. Verrijking met Informatie op Meerdere Niveaus: Om redeneren op repository-niveau te ondersteunen, gebruikt de pipeline Eclipse JDT om uitgebreide context te extraheren, inclusief projectstructuur, volledige klasselichamen, method callers/callees en build-configuraties.
4. Verificatie: De pipeline waarborgt de functionele correctheid door het project te compileren met de juiste JDK-versie en de volledige testsuite uit te voeren (met behulp van JaCoCo) om te verifiëren dat de refactoring het gedrag behoudt.

Samenstelling van de Dataset:

• Schaal: 1.099 door ontwikkelaars geschreven, gedrag-behoudende refactorings.
• Bronnen: 18 diverse Java-projecten.
• Typen: Bevat 922 atomische instanties en 177 samengestelde instanties.
• Refactoring-typen: Omvat drie atomische typen (Extract Method, Move Method, Inline Method) en drie samengestelde typen (Extract and Move, Move and Inline, Move and Rename).

Evaluatiemetrieken:
De benchmark evalueert de prestaties van LLM's op twee dimensies:

1. Functionele Correctheid: Gemeten door compilatiesucces, test-pass rates en AST-gebaseerde Refactoring Verificatie (met behulp van RefactoringMiner om te garanderen dat de beoogde transformatie heeft plaatsgevonden zonder onbedoelde bijwerkingen).
2. Menselijke Gelijkenis: Gemeten met behulp van CodeBLEU om de gelijkenis met de door de ontwikkelaar geschreven grondwaarheid te beoordelen.

Belangrijkste Bijdragen

1. SWE-Refactor Benchmark: Een nieuwe, hoogwaardige dataset van 1.099 pure refactorings uit 18 Java-projecten, die zowel atomische als samengestelde transformaties dekt. Het is de eerste die uitgebreide context op repository-niveau en automatische verificatie voor Java biedt.
2. Geautomatiseerde Constructie-pipeline: Een reproduceerbare, vierstaps-pipeline die real-world refactorings extraheert, filtert op zuiverheid, structurele data verrijkt en de correctheid verifieert zonder handmatige annotatie of door LLM's gegenereerde grondwaarheid.
3. Uitgebreide Evaluatie: Een uitgebreide beoordeling van 9 veelgebruikte LLM's (inclusief GPT-4o-mini, DeepSeek-V3 en diverse CodeLLaMa/Qwen-varianten) over verschillende refactoring-typen en prompting-strategieën (Simple Prompting, RAG en Multi-Agent workflows).

Experimentele Resultaten

De auteurs hebben 9 LLM's geëvalueerd op de 1.099 instanties. Belangrijkste bevindingen zijn:

• Algemene Prestaties: Algemene modellen presteerden beter dan open-source code-specifieke modellen. DeepSeek-V3 behaalde het hoogste succespercentage (41,58%), gevolgd door GPT-4o-mini (39,85%). Open-source modellen zoals CodeLLaMa-7B behaalden slechts 1,10% succes.
• Atomisch vs. Samengesteld: Modellen presteerden aanzienlijk beter op atomische refactorings (lokale bewerkingen) dan op samengestelde refactorings (bestands-overschrijdende, meerstaps-transformaties).
  • DeepSeek-V3 blonk uit in Extract Method (301 successen).
  • GPT-4o-mini toonde een bredere generalisatie in cross-file taken zoals Move Method (92 successen).
  • Open-source modellen hadden bijna volledig moeite met samengestelde typen.
• Impact van Geavanceerde Technieken:
  • Multi-Agent Workflows: Een workflow die gebruikmaakt van een Developer Agent en een Reviewer Agent (met behulp van GPT-4o-mini) behaalde het hoogste algemene succes (579 instanties), wat simple prompting en Retrieval-Augmented Generation (RAG) aanzienlijk overtrof, met name bij complexe samengestelde refactorings.
  • Agentic Scaffolding (OpenAI Codex): Zelfs een krachtige agent (GPT-5.1-Codex) behaalde slechts een succespercentage van 39,4% op samengestelde instanties, vergeleken met 82,6% op atomische instanties, wat de hardnekkige moeilijkheid van meerstaps, strikt gecontroleerde transformaties onderstreept.

Betekenis en Claims

Het artikel positioneert SWE-Refactor als een noodzakelijke evolutie in benchmarks voor software engineering. De betekenis ligt in:

• Realisme: Door gebruik te maken van door ontwikkelaars geschreven commits uit echte projecten, vermijdt het de biases en hallucinaties die geassocieerd worden met synthetische of door LLM's gegenereerde benchmarks.
• Complexiteit: Het richt zich expliciet op de kloof tussen atomische en samengestelde refactorings, en biedt een rigoureuze test voor redeneervermogen op repository-niveau.
• Taaldiversiteit: Het adresseert de Python-centrische bias in de huidige literatuur door een robuuste Java-benchmark te bieden, die de talen reflecteert die worden gebruikt in grootschalige enterprise-systemen.
• Betrouwbaarheid: De geautomatiseerde pipeline zorgt ervoor dat de grondwaarheid gedrag-behoudend en structureel correct is, wat een betrouwbare standaard biedt voor toekomstig onderzoek.

De auteurs concluderen dat hoewel LLM's veelbelovend zijn voor codegeneratie, ze nog steeds aanzienlijk worden uitgedaagd door complexe, samengestelde refactoring-taken, wat suggereert dat huidige agentic frameworks nog niet betrouwbaar zijn voor meerstaps software-onderhoud zonder menselijk toezicht.