💻 computer science

Evaluating LLMs on Java Code Snippet Adaptation Using a Mutation-Injection Framework

Dit artikel stelt een mutatie-injectiekader voor om grote taalmodellen te evalueren op instructievrije adaptatie van Java-codefragmenten, waarbij wordt onderzocht hoe de prestaties variëren over verschillende typen adaptatie, complexiteitsniveaus en contextgranulariteiten met behulp van een dataset afgeleid van open-source repositories met een sterke testdekking.

Oorspronkelijke auteurs: Ali Aman, Muhammad Asaduzzaman, Shaowei Wang, Chanchal K. Roy

Gepubliceerd 2026-06-30

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Ali Aman, Muhammad Asaduzzaman, Shaowei Wang, Chanchal K. Roy

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een chef bent die een heerlijk recept voor "Spaghetti Carbonara" vindt in een oud kookboek. Je wilt het maken voor je vrienden, maar er is een probleem: je vrienden zijn allergisch voor eieren en je hebt alleen een heel klein potje, niet een grote pan. Je kunt het recept niet zomaar exact kopiëren; je moet het aanpassen. Je moet de eieren vervangen door iets anders, de kooktijd veranderen en misschien een stap overslaan.

In de wereld van computerprogrammeren doen ontwikkelaars precies hetzelfde. Ze vinden een stukje code (een "snippet") dat voor iemand anders werkt, kopiëren het, en moeten het dan aanpassen om het in hun eigen project te laten passen.

Dit document is een plan om te testen hoe goed Artificiële Intelligentie (AI) dit werk van "receptaanpassing" zelfstandig kan uitvoeren, zonder dat er precies wordt verteld wat er veranderd moet worden.

Hier is een uitsplitsing van het plan van het onderzoek met behulp van eenvoudige analogieën:

1. Het Probleem: De "Stille Chef"-test

Momenteel, wanneer we AI vragen om code te repareren, geven we het meestal een zeer specifieke lijst met instructies, zoals: "Verander de variabelenaam van 'x' naar 'y' en vervang de bibliotheek."

Maar in de echte wereld schrijven ontwikkelaars geen lijsten. Ze zeggen gewoon: "Hier is de code die ik heb gekopieerd; zorg dat het werkt in mijn nieuwe project." De AI moet de code en de nieuwe omgeving bekijken en de wijzigingen zelf uitzoeken. De auteurs willen weten: Kan de AI de wijzigingen uitzoeken zonder een stapsgewijze handleiding?

2. De Oplossing: De "Mutatie-machine"

Om dit eerlijk te testen, kunnen de auteurs niet zomaar willekeurige code van het internet gebruiken, want dan zouden ze niet precies weten welke wijzigingen de AI had moeten maken.

In plaats daarvan bouwen ze een "Mutatie-machine" (een framework dat ze Mutation-Injection noemen). Zo werkt het:

Stap 1: Ze beginnen met een perfect, werkend stuk code dat al getest is (zoals een perfect recept).
Stap 2: Ze gebruiken een robot om de code op specifieke, gecontroleerde manieren opzettelijk te "breken" of te "verpesten". Bijvoorbeeld, ze kunnen een variabele hernoemen, een getal veranderen of een hulpmiddel vervangen door een ander.
Stap 3: Ze geven deze "kapotte" code aan de AI en zeggen: "Fix dit zodat het weer werkt."
Stap 4: Als de AI het repareert en de code alle tests doorstaat, krijgt de AI een punt.

Omdat zij de "fouten" zelf hebben gecreëerd, weten zij precies wat de AI had moeten doen. Het is als een leraar die een wiskundeprobleem met een bekende fout schrijft, dit aan een leerling geeft, en controleert of de leerling die specifieke fout heeft gevonden en hersteld.

3. De Drie Grote Vragen (Het "Menu")

De onderzoekers testen de AI op drie hoofdzaken:

Vraag 1: Welke "ingrediënten" zijn het moeilijkst om te vervangen?
Sommige wijzigingen zijn makkelijk, zoals het hernoemen van een variabele (het veranderen van "bloem" naar "suiker"). Andere zijn moeilijk, zoals het veranderen van de volledige bereidingswijze (overstappen van bakken naar bakken in de pan). Ze willen zien welke soorten wijzigingen de AI het meest in de war brengen.
Vraag 2: Wordt het moeilijker als je meer dingen tegelijk breekt?
Als de AI één kapot onderdeel kan repareren, kan het dan ook drie kapotte onderdelen tegelijk repareren? Ze testen of de moeilijkheid lineair optelt of dat de AI volledig in de war raakt wanneer er meerdere dingen misgaan.
Vraag 3: Hoeveel "context" heeft de AI nodig?
Stel je voor dat je een recept aan het repareren bent.
- Scenario A: Je ziet alleen de receptenkaart.
- Scenario B: Je ziet de receptenkaart en de lijst met ingrediënten in je voorraadkast.
- Scenario C: Je ziet de receptenkaart, de voorraadkast en de hele keukenindeling.
  De onderzoekers willen weten: Heeft de AI de hele "keuken" (de omliggende code) nodig om een goede indruk te maken, of is de receptenkaart genoeg?

4. De Spelregels

De Taal: Ze testen dit met behulp van Java, een zeer gebruikelijke programmeertaal.
De "Geen Hulp"-regel: De AI mag niet verteld worden wat er veranderd moet worden. De AI krijgt alleen een algemene opdracht: "Pas deze snippet aan aan de context."
Het Veiligheidsnet: Ze gebruiken echte, open-source projecten met sterke "test suites". Zie deze tests als een veiligheidsinspecteur. Als de AI de code verandert en de veiligheidsinspecteur zegt: "Dit werkt nog steeds perfect", dan slaagt de AI.

5. Waarom dit belangrijk is

Op dit moment weten we niet echt hoe goed AI is in deze specifieke "kopiëren-plakken-en-repareren"-vaardigheid. Bestaande tests zijn ofwel te makkelijk, te vaag, of kijken alleen naar volledige functies (zoals een hele maaltijd) in plaats van kleine fragmenten (zoals een enkel ingrediënt).

Deze studie heeft als doel een enorme, eerlijke speeltuin te bouwen waar ze precies kunnen meten waar AI slaagt en waar het faalt bij het aanpassen van code. Als ze ontdekken dat AI slecht is in het "vervangen van gereedschap" maar goed in het "hernoemen van ingrediënten", kunnen toekomstige tools worden gebouwd om ontwikkelaars specifiek te helpen met de moeilijke delen.

Kortom: De auteurs bouwen een gecontroleerde "hindernisbaan" voor AI om te zien hoe goed het kapotte code zelfstandig kan repareren, zonder dat er een spiekbriefje wordt gegeven.

Technische Samenvatting: Het evalueren van LLM's op de aanpassing van Java-codefragmenten met behulp van een Mutatie-Injectie-Framework

Probleemstelling

Ontwikkelaars hergebruiken code vaak door fragmenten uit bestaande repositories of online bronnen te kopiëren en aan te passen aan nieuwe contexten. Dit aanpassingsproces omvat diverse wijzigingen zoals het hernoemen van variabelen, het vervangen van API's, het toevoegen van foutafhandeling en het wijzigen van de besturingsstroom (control flow). In realistische scenario's geven ontwikkelaars geen expliciete stapsgewijze instructies voor bewerkingen; zij verwachten dat tools de noodzakelijke wijzigingen afleiden op basis van het gekopieerde fragment en de omliggende context.

Huidige benchmarks voor het evalueren van Large Language Models (LLM's) op code-aanpassing lijden onder drie primaire beperkingen:

Afhankelijkheid van Expliciete Instructies: Veel bestaande evaluatiesies bieden expliciete bewerkingsinstructies, waardoor het onmogelijk is om het vermogen van het model te testen om wijzigingen autonoom af te leiden.
Beperkte Scope: Benchmarks dekken vaak slechts specifieke typen wijzigingen (bijv. variabele koppeling) of opereren uitsluitend op functieniveau, waarbij de fijnere granulariteit van codefragmenten (bijv. loop-bodies, conditionele vertakkingen) wordt genegeerd waar copy-paste-operaties doorgaans plaatsvinden.
Gebrek aan Gecontroleerde Grondwaarheid: Taken afgeleid van echte commits combineren vaak meerdere typen wijzigingen, wat het moeilijk maakt om te isoleren welke specifieke aanpassingstypen de fouten van het model veroorzaken.

Consequentelijk blijft het onbekend hoe goed LLM's in staat zijn tot instructievrije aanpassing van codefragmenten wanneer de vereiste wijzigingen gevarieerd, gecontroleerd en gepresenteerd worden op verschillende niveaus van complexiteit en context.

Methodologie

De auteurs stellen een Mutatie-Injectie-Framework voor om een gecontroleerde, schaalbare dataset te construeren voor het evalueren van instructievrije code-aanpassing. De methodologie verloopt als volgt:

1. Dataset Constructie

Bron: Volwassen open-source Java-repositories (minimaal 500 sterren, 70% lijndekking via JaCoCo, Maven-buildbaar) verspreid over ten minste vijf verschillende applicatiedomeinen.
Fragment Extractie: Met behulp van het Spoon-framework extraheren de auteurs syntactisch volledige, aaneengesloten codefragmenten (3–20 statements) die gedekt worden door testgevallen en die ten minste twee non-keyword identifiers bevatten.
Seed Selectie: Fragmenten dienen als "ground-truth seeds" die de doeltoestand vertegenwoordigen.

2. Mutatie Injectie (Omgekeerde Aanpassing)

In plaats van modellen te vragen code aan te passen naar een doel, begint het framework met het doel (de seed) en past het aanpassingsoperatoren in omgekeerde richting toe om een gemuteerd fragment ( $F'$ ) te creëren.

Taxonomie: Een gecureerde set van negen mutatie-operatoren afgeleid van empirische studies naar het gedrag van ontwikkelaars (bijv. Zhang et al., Roy et al.). Deze omvatten:
- Identifier-niveau: Variabele hernoeming, constante updates, identifier resolutie.
- Statement-niveau: Guard-insertie, type wijzigingen, try/catch bewerkingen.
- Structureel/Semantisch: Besturingsstroom modificatie, API substitutie, logica aanpassing.
Validatie: Mutaties worden gevalideerd om te garanderen dat de resulterende code compileert en, cruciaal, ten minste één bestaande testcase in de repository doet falen. Dit zorgt ervoor dat de mutatie een semantische defect introduceert die de LLM moet oplossen.
Complexiteitsniveaus: Taken worden gecategoriseerd op complexiteit ( $L1$ tot $L4$ ) op basis van het aantal en de combinatie van geïnjecteerde mutaties.

3. Taak Formulering

LLM's worden gepresenteerd met het gemuteerde fragment ( $F'$ ) en een prompt met de instructie om "het fragment aan te passen aan de omliggende context". Er worden geen expliciete lijst met bewerkingen of stapsgewijze begeleiding verstrekt.

Context Granulariteit: De studie evalueert drie contextniveaus:
- C1: Geen context (alleen het fragment).
- C2: Methode context (de omliggende methode body).
- C3: File context (het volledige bronbestand).

4. Evaluatie Metrieken

Functionele Correctheid: De output van de LLM wordt opnieuw ingevoegd op de oorspronkelijke locatie in de codebase, waarna de testsuite van de repository wordt uitgevoerd. Succes wordt gemeten via pass@1 en pass@5 (waarbij elke van de 5 gegenereerde outputs succesvol is).
Aanpassings-niveau Correctheid: Een fijnmazige inspectie controleert of specifieke geïnjecteerde mutaties correct zijn teruggedraaid, gebruikmakend van de tijdens de injectie geregistreerde JSON-metadata.
Statistische Analyse: Mixed-effects logistische regressie wordt gebruikt om interacties tussen model, aanpassingstype, context en complexiteit te analyseren.

Belangrijkste Bijdragen

Instructievrij Evaluatieparadigma: De studie verschuift de focus van expliciete bewerkingsbegeleiding naar autonome inferentie, wat de real-world scenario's van codehergebruik beter reflecteert.
Fragment-niveau Granulariteit: In tegen door function-level benchmarks, richt dit framework zich op sub-methode eenheden (loops, conditionals), wat overeenkomt met hoe ontwikkelaars daadwerkelijk code kopiëren en plakken in IDE's.
Gecontroleerde Grondwaarheid via Mutatie-injectie: Door operatoren in omgekeerde richting toe te passen, weten de auteurs precies welke wijzigingen vereist zijn. Dit maakt een precieze attributie van modelprestaties aan specifieke aanpassingstypen mogelijk, een capaciteit die ontbreekt in benchmarks gebouwd uit verstrengelde echte commits.
Schaalbaar, Herbruikbaar Framework: De taxonomie wordt geoperationaliseerd als programmeerbare mutatie-operatoren, waardoor toekomstige onderzoekers nieuwe tools op schaal kunnen evalueren zonder handmatige annotatie.

Onderzoeksvragen

De studie is gestructureerd rond drie verkennende vragen:

RQ1 (Moeilijkheidsgraad van Aanpassingstype): Welke categorieën van aanpassing zijn het moeilijkst voor LLM's om uit te voeren zonder expliciete instructies?
RQ2 (Aanpassingscomplexiteit): Hoe schaalt prestatie met het aantal en de combinatie van geïnjecteerde wijzigingen? Creëert het combineren van eenvoudige wijzigingen een emergente moeilijkheidsgraad?
RQ3 (Context Granulariteit): Hoeveel omliggende context is vereist voor succesvolle aanpassing, en varieert deze vereiste per aanpassingstype?

Betekenis en Claims

Het artikel positioneert zichzelf als een Registered Report, waarbij de nadruk ligt op de rigueur van het experimentele ontwerp en de vooraf geregistreerde aard van het analyseplan.

Het Gat Dichten: De auteurs beweren dat bestaande benchmarks er niet in slagen om gelijktijdig instructievrije taken, fragment-niveau granulariteit, gecontroleerde veranderingstypen en schaalbaarheid te bieden. Hun framework is ontworpen om dit gecombineerde gat te vullen.
Praktische Impact: De resultaten beogen de ontwikkeling van toekomstige code-hergebruik tools en IDE-plugins te sturen door te identificeren bij welke specifieke aanpassingstypen huidige LLM's moeite hebben en door te bepalen wat de optimale contextvensters zijn voor verschillende typen aanpassingen.
Reproduceerbaarheid: De auteurs verbinden zich ertoe de volledige dataset, het mutatie-framework en de evaluatiescripts publiekelijk beschikbaar te maken om replicatie en uitbreiding te ondersteunen.

Het papier claimt niet het probleem van code-aanpassing te hebben opgelost, maar stelt een systematische methode voor om de huidige stand van zaken van LLM's in dit domein te meten, wat een baseline biedt voor toekomstige verbeteringen. Het erkent beperkingen, zoals de restrictie tot Java/Maven en de potentiële divergentie tussen synthetische mutaties en natuurlijke ontwikkelaarsadaptaties, waarbij wordt opgemerkt dat het framework is ontworpen om in de toekomst naar andere talen en buildsystemen uitgebreid te worden.