Assessing the Impact of Code Changes on the Fault Localizability of Large Language Models

Dit paper introduceert een nieuw evaluatiekader dat aantoont dat Large Language Models bij het lokaliseren van fouten vaak afhankelijk zijn van syntactische cues in plaats van semantische redenering, aangezien 78% van de succesvolle lokaliseringspogingen faalt bij het toepassen van semantisch behoudende mutaties.

De kern

Titel: Waarom AI's "bug-vinders" zo snel in de war raken: Een simpel verhaal over code en verwarring

Stel je voor dat je een enorme, slimme robot hebt die je helpt bij het repareren van auto's. Deze robot is getraind op miljoenen handleidingen en kan perfect nieuwe auto's ontwerpen (code genereren). Maar wat gebeurt er als je hem vraagt om een bestaande auto te inspecteren en te vertellen waar de motor precies stuk is?

Dat is precies wat dit onderzoek doet. De auteurs hebben gekeken of deze slimme AI's (Large Language Models of LLMs) echt goed zijn in het vinden van fouten in code, of dat ze eigenlijk alleen maar oppervlakkig kijken.

Hier is wat ze hebben ontdekt, vertaald naar alledaagse taal:

1. Het probleem: De robot leert uit het hoofd, niet uit inzicht

De meeste tests voor AI gaan over het maken van code (zoals een chef die een nieuw recept bedenkt). Maar het vinden van fouten is anders; het is alsof je een bestaand gerecht proeft en moet zeggen: "Ah, de kok heeft te veel zout gedaan."

Het probleem is dat veel AI's de bestaande recepten (de code) al uit hun training kennen. Het is alsof je de robot een raadsel geeft waarvan het antwoord al in zijn geheugen staat. Dat geeft een vals gevoel van bekwaamheid.

2. De oplossing: Een "vermommingstest"

Om te zien of de AI echt begrijpt hoe de machine werkt, hebben de onderzoekers een slimme truc bedacht, gebaseerd op mutatie.

Stel je voor dat je de robot een defecte auto laat zien. Hij zegt: "De motorblok is kapot."
Nu doen we iets vreemds: we veranderen de auto, maar niet de motor.

• We veranderen de kleur van de motorkap.
• We hernoemen de onderdelen (in plaats van "motorblok" noemen we het "krachtcentrum").
• We voegen een stukje decoratie toe dat nergens voor dient (dode code).

Voor een mens die echt begrijpt hoe een auto werkt, maakt dit niets uit. De motor is nog steeds kapot. Maar voor de AI is dit een ramp.

3. De schokkende resultaten

De onderzoekers lieten 10 verschillende AI-modellen (zoals Claude, GPT-4 en Gemini) 750.000 keer fouten zoeken in code.

• Eerst: De AI's vonden de fouten redelijk goed.
• Daarna: Ze veranderden de code met de "vermommingen" (zoals het hernoemen van variabelen of het toevoegen van onzin-commentaar).

Het resultaat?
In 78% van de gevallen raakte de AI in de war!
De AI die net perfect had gezegd waar de fout zat, zei nu ineens: "Oh, het probleem zit hier!" (terwijl het daar helemaal niet zat).

Het is alsof de robot denkt: "Oh, de motorkap is nu blauw en er staat een sticker op, dus de motor moet daar zitten!"
De AI kijkt dus niet naar de logica van de machine, maar naar de oppervlakkige details (zoals de naam van een onderdeel of de volgorde van zinnen).

4. Waarom is dit belangrijk?

Dit onderzoek laat zien dat AI's nog niet echt "nadenken" over code zoals mensen doen. Ze zijn erg gevoelig voor:

• Verkeerde hints: Als er een opmerking in de code staat die zegt "Hier zit de fout" (maar dat is niet zo), springt de AI erop.
• Dode code: Als er stukken code zijn die nooit worden gebruikt, maar wel opvallend zijn, raakt de AI daar door in de war.
• Positie: AI's vinden fouten beter als ze aan het begin van de code staan. Als de fout diep in het document zit, "vergeten" ze het vaak.

De conclusie in één zin

Deze slimme AI's zijn geweldig in het schrijven van code, maar ze zijn nog heel kwetsbaar als het gaat om het repareren ervan. Ze vertrouwen te veel op oppervlakkige signalen en verliezen hun logische koers zodra je de "verpakking" van de code een beetje verandert, terwijl de inhoud hetzelfde blijft.

Wat betekent dit voor de toekomst?
We moeten AI's niet alleen trainen om code te schrijven, maar ze ook leren om echt te begrijpen wat de code doet, ongeacht hoe de variabelen heten of waar de commentaren staan. Pas dan kunnen we er echt op vertrouwen dat ze onze software veilig houden.

Technische samenvatting

Hier is een gedetailleerde technische samenvatting van het paper "Assessing the Impact of Code Changes on the Fault Localizability of Large Language Models", gepresenteerd op ICST 2026.

Probleemstelling

Grote Taalmodellen (LLMs) worden steeds vaker ingezet voor softwareonderhoudstaken zoals foutlokalisatie (Fault Localization - FL). Succesvolle FL vereist echter diepgaand redeneren over programmasemantiek (hoe logica en state flow werken), in plaats van alleen oppervlakkige syntactische of lexicaal kenmerken.

De huidige evaluatie van LLMs voor code heeft drie fundamentele tekortkomingen:

1. Data-contaminatie: Veel gebruikte benchmarks (zoals Defects4J en BugsInPy) zijn opgenomen in de trainingsdata van LLMs, wat leidt tot vertekende, te optimistische resultaten.
2. Gebrek aan specificaties: Bestaande datasets missen vaak duidelijke natuurlijke taal-specificaties, wat essentieel is om te bepalen of een programma correct functioneert.
3. Schalbaarheid en Robuustheid: Er ontbreekt een gestandaardiseerde, schaalbare methode om te testen of LLMs echt semantisch redeneren of slechts oppervlakkige patronen herkennen.

Methodologie

De auteurs hebben een volledig geautomatiseerd, end-to-end evaluatiekader ontwikkeld om de robuustheid van LLMs te testen. Het onderzoek volgt een vierstapsproces:

1. Verwerving van Seed-programma's:

   • Er zijn 1.307 "seed"-programma's geselecteerd (637 Python, 670 Java) uit open-source datasets die vergezeld gaan van natuurlijke taal-specificaties.
   • Programma's met minder dan 50 regels code of die al bekend waren in trainingsdata zijn uitgesloten.

2. Foutinjectie (Fault Injection):

   • Er zijn 4 soorten fouten dynamisch ingebracht in de seed-programma's (bijv. off-by-one fouten, verkeerde boolean logica, operator swaps, vroegtijdige returns).
   • Dit resulteerde in 750.013 unieke foutieve programma's.
   • Een "counterexample-driven" filter werd toegepast: alleen programma's waar ten minste één LLM de fout correct kon lokaliseren, werden behouden om te voorkomen dat onvoldoende specificaties de oorzaak van falen waren.

3. Semantisch Behoudende Mutaties (Semantic-Preserving Mutations - SPMs):

   • Voor programma's die correct waren gelokaliseerd, werden SPMs toegepast. Deze mutaties veranderen de code syntactisch maar behouden de functionaliteit en de fout.
   • De vier categorieën mutaties waren:
     • Annotatief: Misleidende commentaren.
     • Identificatie: Hernoemen van variabelen of functies.
     • Structureel: Injectie van dode code (dead code) die niet wordt uitgevoerd.
     • Niet-additief: Het herschikken van functiedefinities (alleen Java).
   • De "sterkte" van de mutatie werd gevarieerd (aantal mutaties per programma).

4. Evaluatie:

   • 10 state-of-the-art LLMs (zowel gesloten bron zoals GPT-4o, Claude, Gemini als open source zoals Llama 3.1, Phi-4, Qwen) werden getest.
   • De modellen moesten de fout opnieuw lokaliseren in de gemuteerde versies, zonder context van de vorige poging.
   • De robuustheid werd gemeten als het percentage van de oorspronkelijk correct gelokaliseerde fouten dat nog steeds correct werd gevonden na de mutatie.

Belangrijkste Resultaten

Het onderzoek, uitgevoerd op een dataset van 245 miljoen regels code en 3,8 miljard tokens, leverde de volgende cruciale bevindingen op:

• Extreme Gevoeligheid voor SPMs: In 78% van de gevallen faalde een LLM om dezelfde fout te lokaliseren nadat er semantisch behoudende mutaties waren toegepast, zelfs als het de fout eerder correct had gevonden.
• Invloed van Dode Code en Commentaar:
  • Dode code had het grootste negatieve effect, waardoor de gemiddelde nauwkeurigheid daalde tot 20,38%. Modellen neigden om de dode code als de fout te markeren.
  • Misleidende commentaren zorgden voor een nauwkeurigheid van 25,63%, wat aangeeft dat modellen te veel vertrouwen op tekstuele hints in plaats van logica.
  • Variabelen hernoemen had het minste effect (29,02%), wat suggereert dat modellen redelijk robuust zijn tegen naamswijzigingen zolang de structuur intact blijft.
• Positie Bias: LLMs presteerden aanzienlijk beter bij fouten in het eerste kwart van de code (56% van de correcte lokalisaties) vergeleken met fouten in de laatste 25% (slechts 6%). Dit wijst op een "verlies van context" of "attention decay" in lange sequenties.
• Taalverschillen: Hoewel modellen op Java vaak een hogere initiële nauwkeurigheid hadden, daalde de prestatie bij Java sterker dan bij Python na het toepassen van SPMs. Dit wordt toegeschreven aan de meer uitgebreide syntaxis van Java en de beperkingen van het contextvenster.
• Modelverschillen: Gesloten bronmodellen (Claude 4.5, Gemini 2.5) presteerden over het algemeen beter dan open-source modellen, maar zelfs de beste modellen vertoonden een significante daling in robuustheid.
• Evolutie: Nieuwere modelversies tonen slechts marginale verbeteringen (1-2%) in foutlokalisatie, wat suggereert dat schaling alleen niet voldoende is voor fundamenteel beter semantisch redeneren.

Bijdragen

1. Eerste Groot-Schalig Onderzoek: Dit is het eerste empirische onderzoek dat de robuustheid van LLMs in foutlokalisatie op deze schaal (750k+ taken) evalueert.
2. Nieuw Evaluatiekader: Een geautomatiseerd framework dat dynamisch fouten injecteert en SPMs toepast om data-contaminatie te omzeilen en robuustheid te meten.
3. Inzicht in Zwaktes: Het identificeert specifieke codepatronen (zoals dode code en misleidende commentaren) die LLMs dwalen, en toont aan dat hun redenering sterk afhankelijk is van oppervlakkige kenmerken in plaats van diepe semantiek.
4. Open Data: Het framework, de datasets en de code zijn openbaar beschikbaar gesteld via Zenodo.

Significantie en Conclusie

De studie concludeert dat de huidige LLMs, ondanks hun succes in codegeneratie, fundamenteel tekortschieten in het redeneren over bestaande code voor onderhoudstaken. Hun vermogen om fouten te lokaliseren is niet-lineair en extreem kwetsbaar voor veranderingen die voor een mens irrelevant zijn voor de logica (zoals dode code).

Dit impliceert dat:

• Huidige benchmarks voor code-LLMs onvoldoende zijn voor het evalueren van onderhoudstaken.
• Er fundamentele doorbraken nodig zijn in hoe LLMs code representeren (bijvoorbeeld via abstracte structuren zoals Control Flow Graphs in plaats van alleen token-sequenties).
• Toekomstige modellen moeten leren om semantisch irrelevante "ruis" te filteren om betrouwbare autonome agents voor softwareonderhoud te worden.

Kortom, hoewel LLMs veelbelovend zijn, zijn ze momenteel nog niet robuust genoeg voor kritieke foutlokaliseringsopdrachten in de echte wereld zonder menselijke tussenkomst of aanvullende validatiestappen.