CodeTaste: Can LLMs Generate Human-Level Code Refactorings?

Dit paper introduceert CodeTaste, een benchmark die aantoont dat hoewel LLM-agents refactorings kunnen uitvoeren wanneer deze gedetailleerd worden gespecificeerd, er nog een aanzienlijke kloof bestaat met menselijke keuzes, tenzij er een 'voorstel-gevolgd-door-implementatie'-benadering wordt gebruikt om de uitlijning te verbeteren.

De kern

CODETASTE: Kunnen AI's net zo goed code "opknappen" als mensen?

Stel je voor dat je een oude, rommelige garage hebt. Je hebt er een nieuwe, slimme robot voor gehuurd om de rommel op te ruimen en de spullen netjes te ordenen. De robot is geweldig in het bouwen van nieuwe dingen (hij kan een auto repareren of een nieuwe kast bouwen), maar als het gaat om het opruimen van de bestaande chaos, maakt hij vaak een grotere puinhoop dan hij aanving.

Dit is precies wat deze paper, CODETASTE, onderzoekt.

Het Probleem: De "Rommelige" Robot

Vandaag de dag zijn er slimme AI's (zoals Large Language Models of LLM's) die code kunnen schrijven. Ze kunnen een programma maken dat werkt. Maar vaak is die code een puinhoop:

• Het is te langdradig.
• Het bevat dubbel werk.
• De structuur is een lappendeken.

Mensen noemen dit technische schuld. Om dit op te lossen, doen programmeurs refactoring. Dat is een fancy woord voor "opknappen zonder de functionaliteit te veranderen". Het is alsof je de garage niet leegt, maar alles verplaatst naar de juiste planken, zodat je later makkelijk kunt vinden wat je zoekt.

De vraag van de auteurs is: Kunnen deze AI-robots dit zelfstandig doen? Kunnen ze zien waar het rommelig is en hoe het opgelost moet worden, net als een ervaren mens?

De Oplossing: CODETASTE (De Keukentest)

Om dit te testen, hebben de onderzoekers CODETASTE bedacht. De naam is een knipoog naar "Code" en "Taste" (smaak). Het is een testomgeving die werkt als een keukentest voor koks:

1. De Ingrediënten: Ze hebben 100 echte, grote "opruimingsklussen" uit open-source software (zoals grote projecten op GitHub) gehaald.
2. De Keuken: Ze hebben voor elke klus een perfecte, veilige keuken (een digitale omgeving) gebouwd waar de AI veilig kan werken.
3. De Smaaktest: Ze hebben niet alleen gekeken of het programma nog werkt (de test), maar ook of de AI de juiste opknapklus heeft gedaan. Ze gebruiken slimme regels om te zien of de AI de oude rommel echt heeft verwijderd en de nieuwe, nette structuur heeft toegevoegd.

De Twee Proeven

Ze hebben de AI's op twee manieren getest:

1. De "Volg de Recept" Test (Instructed Track)
Hier zeggen ze tegen de AI: "Verplaats alle rode dozen naar de linkerkast en noem ze 'Winterkleding'."

• Resultaat: De beste AI's (zoals GPT-5) deden dit best goed. Ze volgden het recept en maakten de kast netjes. Maar zelfs dan maakten ze soms fouten in de functionaliteit (de kast viel misschien wel uit elkaar).

2. De "Maak het Leuker" Test (Open Track)
Hier zeggen ze tegen de AI: "Deze garage is een puinhoop. Maak het beter." Ze geven geen specifieke instructies.

• Resultaat: Hier faalden de AI's bijna volledig.
  • In plaats van de grote structuur op te ruimen, pakte de AI een klein detail (bijvoorbeeld: "Oh, hier staat een spelfout in een naam, die ga ik fixen").
  • Of ze maakten een snelle, slordige oplossing (een "hack") die wel werkte, maar de echte rommel niet oploste.
  • Ze dachten niet na over het grote plaatje. Ze zagen niet dat de hele garage moest worden herschikt, maar probeerden alleen een losse schroef vast te draaien.

De Leerzame Analogie: De Architect vs. De Werkman

De paper laat zien dat AI's momenteel uitstekende werklieden zijn als je ze precies vertelt wat ze moeten doen. Maar ze zijn nog geen architecten.

• Een werkman kan een muur schilderen als je zegt: "Schilder deze muur wit."
• Een architect ziet dat de muur scheef staat en zegt: "We moeten de hele muur verplaatsen om de kamer groter te laten lijken."

De AI's in de "Open Track" proef gedroegen zich als werklieden die probeerden een architectenklus te doen. Ze zagen de scheve muur niet; ze probeerden alleen de verf te verbeteren.

De Oplossing: Eerst Denken, Dan Doen

Een interessante ontdekking was dat als je de AI dwingt om eerst een plan te maken voordat hij begint met werken, het resultaat veel beter wordt.

• Direct doen: AI maakt een rommelige oplossing.
• Eerst plannen: AI denkt na, schetst een plan, en voert dat dan uit. Dit helpt de AI om het "grote plaatje" te zien, net als een mens die eerst even naar de garage kijkt voordat hij begint met slepen.

Conclusie

De boodschap van deze paper is helder:
AI's zijn geweldige tools om code te schrijven als je ze precies vertelt wat ze moeten doen. Maar ze zijn nog niet slim genoeg om zelfstandig te zien waar code slecht is en hoe je die het beste kunt opknappen. Ze missen nog het menselijke "oordeel" en de visie om complexe, grote structuren te verbeteren zonder dat je ze stap voor stap moet aansturen.

CODETASTE is dus een nieuwe meetlat om te zien hoe dicht we bij dat moment komen dat AI's niet alleen code schrijven, maar ook echte, slimme software-ontwerpers worden die hun eigen werk kunnen verbeteren.

Technische samenvatting

Hier is een gedetailleerde technische samenvatting van het paper "CODETASTE: Can LLMs Generate Human-Level Code Refactorings?" in het Nederlands.

1. Het Probleem

Hoewel Large Language Models (LLM) en coderende agenten uitstekend zijn in het genereren van werkende code voor het oplossen van specifieke problemen (issue resolution), vertonen ze tekortkomingen in het handhaven van codekwaliteit op de lange termijn. Hun oplossingen leiden vaak tot een opeenstapeling van complexiteit, duplicatie en "architecturale schuld".

Menselijke ontwikkelaars gebruiken refactoring (gedragsbehoudende programma-transformaties) om de structuur en onderhoudbaarheid te verbeteren. Bestaande benchmarks voor refactoring hebben echter beperkingen:

• Ze focussen vaak op kleine, enkelvoudige bestanden of methoden.
• Ze testen vaak alleen of een model een gespecificeerde transformatie kan uitvoeren, niet of het model zelfstandig kan herkennen welke refactoring nodig is.
• Ze meten niet of de agent de menselijke keuze voor een specifieke architecturale verbetering kan repliceren in een realistische, multi-bestands context.

De kernvraag van het paper is: Kunnen LLM-agenten betrouwbaar refactorings uitvoeren en kunnen ze de specifieke refactorings die menselijke ontwikkelaars kiezen, zelfstandig identificeren en implementeren?

2. Methodologie: De CODETASTE Benchmark

De auteurs introduceren CODETASTE, een nieuwe benchmark die is opgezet om deze kloof te meten. De aanpak bestaat uit een geautomatiseerde pijplijn:

• Dataverzameling: Uit populaire GitHub-repositories worden 100 grote, menselijke refactorings gemined die meerdere bestanden betreffen (gemiddeld 91 bestanden en 2600 regels code per taak).
• Omgeving: Voor elke taak wordt een reproduceerbare, gecontaineriseerde uitvoeringsomgeving gebouwd die de unit-tests van het project kan draaien.
• Static Analysis Rules (OpenGrep): In plaats van alleen te vertrouwen op tests, genereren de auteurs semantische regels (met dataflow-redenering) die de bedoelde transformatie vastleggen.
  • Additieve regels ($\Gamma+$): Patronen die in de nieuwe code moeten voorkomen.
  • Reductieve regels ($\Gamma-$): Patronen die uit de oude code moeten verdwijnen.
• Evaluatiemetrics:
  • Functionele Correctheid (PASS): De tests moeten slagen.
  • Instruction Following Rate (IFR): De mate waarin de gegenereerde code de semantische regels volgt.
  • Alignment Score (A): Een gecombineerde score ($A = PASS \times IFR$) die alleen beloont als de code functioneel correct is en de juiste refactoring heeft doorgevoerd.

De twee tracks:

1. Instructed Track: De agent krijgt een gedetailleerde beschrijving van de te maken refactoring (zoals een GitHub-issue). Dit test de uitvoeringsvaardigheid.
2. Open Track: De agent krijgt slechts een vaag doelgebied (bijv. "Verbeter de interne organisatie"). De agent moet zelf beslissen welke refactoring nodig is. Dit test het autonome oordeel.

3. Belangrijkste Resultaten

De experimenten met state-of-the-art modellen (GPT-5.2, GPT-5.1 Codex Mini, Claude Sonnet 4.5, en Qwen3) tonen een duidelijke kloof aan:

• Instructed Track (Gedetailleerde instructies):

  • Modellen presteren redelijk goed wanneer de taak specifiek is. GPT-5.2 bereikt een Alignment Score van 69,6%.
  • Er is echter een groot verschil in functionaliteit: GPT-5.2 behoudt de testsuccesratio (PASS) veel beter dan andere modellen (76% vs ~43-47%), wat suggereert dat het doelgerichter patcht in plaats van grove zoek-en-vervang-commando's te gebruiken.
  • De precisie (het vermijden van onnodige wijzigingen) ligt rond de 56-59%, wat vergelijkbaar is met menselijke precisie.

• Open Track (Zelfstandige besluitvorming):

  • De prestaties storten in. Zelfs de beste modellen bereiken slechts 7,7% alignment (GPT-5.2 in Direct mode).
  • Agenten hebben moeite om de menselijke architecturale keuzes te raden. Ze neigen naar oppervlakkige oplossingen (typo's fixen), "hacky" werkoplossingen (compatibility shims) of destructieve globale vervangingen die de codebreuk veroorzaken.
  • Planning helpt: Het gebruik van een "propose-then-implement" strategie (eerst een plan maken, dan uitvoeren) verdubbelt de score voor GPT-5.2 naar 14,1%. Het gebruik van een "Oracle" (een LLM die het beste plan kiest uit meerdere opties) brengt de score op 19,4%. Dit is echter nog steeds ver verwijderd van menselijk niveau.

4. Belangrijkste Bijdragen

1. CODETASTE Benchmark: Een schaalbare, realistische benchmark met 100 complexe, multi-bestands refactorings uit open-source repositories, ondersteund door containerized testomgevingen en semantische statische analyse.
2. Semantische Evaluatie: Het gebruik van OpenGrep-regels met dataflow-redenering om te verifiëren of specifieke patronen zijn verwijderd of toegevoegd, wat robuuster is dan puur syntactische matching.
3. Empirisch Bewijs van een "Judgment Gap": Het paper bewijst dat hoewel LLM's uitstekend zijn in het uitvoeren van specifieke instructies, ze nog zeer slecht zijn in het identificeren van de juiste refactoring in een ongespecificeerde context.
4. Analyse van Falen: Gedetailleerde case studies tonen aan dat agenten vaak vastlopen in lokale optima (bijv. alleen bestaande bestanden aanpassen) of de verkeerde scope kiezen (bijv. backend aanpassen in plaats van frontend).

5. Betekenis en Conclusie

De studie concludeert dat autonome code-agenten nog niet klaar zijn voor het zelfstandig beheren van technische schuld of het doorvoeren van menselijke kwaliteitsverbeteringen in bestaande codebases. Hoewel ze gedetailleerde instructies goed kunnen volgen, missen ze het vermogen om de intentie achter een refactoring te begrijpen en de juiste architecturale keuzes te maken zonder menselijke sturing.

Toekomstperspectief:

• De "propose-then-implement" aanpak (planning vooraf) is essentieel voor betere prestaties.
• CODETASTE dient als een cruciale evaluatiedoelstelling en een "preference signal" om toekomstige modellen te trainen op het nemen van menselijke refactoring-beslissingen.
• Er is nog veel werk te doen aan het verbeteren van het autonome oordeel van agenten om codebases op de lange termijn onderhoudbaar te houden.