Comparing Developer and LLM Biases in Code Evaluation

Probleemstelling

Naarmate Large Language Models (LLMs) steeds vaker worden ingezet als "rechters" (judges) om code te evalueren, is er een groeiende behoefte aan betrouwbare evaluatiemethoden die realistische, interactieve ontwikkelomgevingen nabootsen. Bestaande onderzoeken richten zich vaak op statische settings, zoals gepolijste code uit GitHub-repositories of competitieve programmeertaken. Deze benaderingen missen echter de "rommelige" en ongedefinieerde context waarin ontwikkelaars daadwerkelijk code evalueren en verfijnen.

De kernvraag van dit onderzoek is: Welke biases vertonen LLM-rechters bij het evalueren van code, en hoe verhouden deze zich tot de voorkeuren van menselijke ontwikkelaars? De auteurs stellen dat huidige evaluaties niet voldoende rekening houden met functionele correctheid in combinatie met ontwikkelaarsintenties, beperkingen en workflow-verwachtingen.

Methodologie: TRACE Framework

De auteurs stellen TRACE (Tool for Rubric Analysis in Code Evaluation) voor, een raamwerk dat is ontworpen om LLM-rechters te evalueren en te interpreteren in realistische developer-workflows. TRACE werkt in drie stappen:

1. Meting van Menselijke Voorkeuren:
   Het framework verzamelt paarsgewijze voorkeuren (pairwise preferences) van menselijke ontwikkelaars over twee code-responsen ($y_A, y_B$) gegeven een context ($x$). Vervolgens wordt gemeten in hoeverre verschillende LLM-rechters deze menselijke voorkeuren kunnen voorspellen. Er wordt rekening gehouden met positionele bias (de volgorde waarin antwoorden worden gepresenteerd) door elke sample tweevalueren.

2. Identificatie van Rubric Items (Evaluatiecriteria):
   Om de redenen voor afwijkingen te begrijpen, genereert TRACE automatisch interpreteerbare "rubric items" (evaluatiecriteria). Dit gebeurt door:

   • Het analyseren van verschillen tussen responsen met behulp van LLM's (gebaseerd op VibeCheck).
   • Het integreren van menselijke annotatie-rationales.
   • Het aggregeren van deze criteria tot een gestructureerde lijst van kwaliteitsdimensies (bijv. "Robuustheid", "Duidelijkheid van comments").

3. Vergelijking van Biases:
   De auteurs trainen logistische regressiemodellen om de voorkeuren van zowel mensen als LLM-rechters te voorspellen op basis van de scores van de rubric items. Door de coëfficiënten ($\beta$) van deze modellen te vergelijken, kunnen ze kwantificeren welke criteria een LLM-rechter over- of onderwaardeert ten opzichte van menselijke ontwikkelaars. Een significante afwijking wordt gedefinieerd wanneer het 95% betrouwbaarheidsinterval van de LLM-coëfficiënt de menselijke coëfficiënt uitsluit.

Experimenteel Opzet

Het onderzoek omvat drie representatieve interactiemodi, elk met datasets van meer dan 500 samples:

• Code Completion: IDE-autocomplete (bron: Copilot Arena).
• Instructed Code Editing: Code aanpassen op basis van instructies (bron: EDIT-Bench).
• Chat-based Programming: Open-ended coderingsvragen (bron: Chatbot Arena, gefilterd voor code).

Er werden 13 verschillende LLM-rechters geëvalueerd, waaronder:

• Algemene third-party modellen (GPT-5, GPT-4o, Claude Sonnet 4, DeepSeek-R1).
• Gespecialiseerde judge-modellen (Prometheus 2, Atla Selene, Skywork Critic).
• Reward-modellen (PairRM, GRM).

Belangrijkste Resultaten

1. LLM-rechters presteren systematisch slechter dan mensen:
   De beste LLM-rechters presteren 12-23% slechter dan menselijke annotatoren in het voorspellen van menselijke voorkeuren. Geen enkel model domineert consistent over alle modi. Opmerkelijk genoeg presteren gespecialiseerde judge-modellen niet betrouwbaar beter dan algemene modellen, wat suggereert dat de huidige tekortkomingen niet alleen liggen aan de trainingsdata.

2. Significante misalignments in specifieke criteria:
   TRACE identificeerde 35 significante bronnen van misalignement tussen mensen en rechters. De biases variëren per modus:

   • Code Completion: Rechters geven te veel gewicht aan functionele logica en te weinig aan leesbaarheid en expliciteit binnen een bestaand bestand. Mensen geven de voorkeur aan code die duidelijk is en goed past bij teamconventies, zelfs als het iets minder "minimaal" functioneel is.
   • Chat-based Coding: Rechters belonen generieke uitleg en lange commentaarblokken. Mensen geven echter de voorkeur aan contextbewuste oplossingen met minder overbodige uitleg.
   • Code Editing: Rechters zien edits vaak als een taak om instructies te volgen (constraint satisfaction) en negeren de noodzaak voor heldere, onduidelijke code. Mensen zien edits als kansen om de algehele codekwaliteit en leesbaarheid te verbeteren.

3. Misalignement met gevestigde software-engineeringcriteria:
   Van de 16 geïdentificeerde thema's corresponderen er 11 met gevestigde software-engineeringcriteria (zoals syntaxis, formatting, robuustheid). Toch vertonen LLM-rechters significante misalignments op 6 van deze 11 thema's. Dit suggereert dat er fundamentele kloven bestaan in hoe LLM's "goede code" definiëren ten opzichte van menselijke ingenieurs, zelfs op basisgebieden.

4. Positiebias:
   LLM-rechters vertonen een sterke positiebias (ze kiezen vaker voor het eerste of tweede antwoord afhankelijk van de volgorde), terwijl reward-modellen hier minder last van hebben omdat ze scalare scores gebruiken.

Bijdrage en Significantie

• Nieuw Evaluatiekader: TRACE biedt een methodologie om niet alleen de nauwkeurigheid van LLM-rechters te meten, maar ook de oorzaken van hun fouten te verklaren via automatisch gegenereerde rubrics.
• Inzicht in Realistische Contexten: Het paper benadrukt dat evaluaties in statische benchmarks (zoals JudgeBench) niet noodzakelijk vertalen naar realistische, interactieve ontwikkelomgevingen.
• Richting voor Toekomstig Onderzoek: De bevindingen suggereren dat het verbeteren van geautomatiseerde code-evaluatie vereist dat rechters worden getraind met rubric-aware objectives of dat er kalibratielagen worden toegevoegd om de biases van de rechters af te stemmen op menselijke voorkeuren.
• Praktische Implicatie: Voor ontwikkelaars die LLM-tools gebruiken, is het cruciaal om te beseffen dat de "rechter" van de AI mogelijk andere prioriteiten heeft dan de menselijke gebruiker, wat kan leiden tot frustratie en minder effectieve hulpmiddelen.

Kortom, het paper concludeert dat er een aanzienlijke kloof bestaat tussen hoe LLM's code beoordelen en hoe menselijke ontwikkelaars dit doen, en dat deze kloof niet opgelost wordt door simpelweg grotere of gespecialiseerdere modellen te gebruiken zonder inzichtelijke aanpassing van de evaluatiecriteria.