WebDevJudge: Evaluating (M)LLMs as Critiques for Web Development Quality

Dit paper introduceert WebDevJudge, een systematische benchmark voor het evalueren van de betrouwbaarheid van (multi-modale) LLM's als beoordelaars voor webdevelopmentkwaliteit, waarbij wordt aangetoond dat er een aanzienlijke kloof bestaat tussen deze modellen en menselijke experts door fundamentele beperkingen in het herkennen van functionele equivalentie en het verifiëren van taakhaalbaarheid.

De kern

Stel je voor dat je een nieuwe app of website hebt gebouwd. Je wilt weten of hij goed werkt, of hij mooi is en of hij doet wat de klant wilde. Vroeger huurde je daarvoor een team van menselijke experts voor in, maar dat is duur, traag en lastig te schalen.

Nu hebben we slimme computers (LLMs) die dit werk voor ons kunnen doen. Ze fungeren als een rechter die oordeelt of een website goed is. Maar hoe goed zijn die digitale rechters eigenlijk? Kunnen ze net zo goed oordelen als een mens, vooral als het gaat om complexe, interactieve websites?

Dit is het verhaal van WEBDEVJUDGE, een nieuwe test die precies dat onderzoekt.

1. De Grote Uitdaging: De Digitale Rechter

Stel je voor dat je twee verschillende versies van een boekbesprekingssite hebt. De ene is gemaakt door Model A, de andere door Model B.

• De menselijke rechter: Kijkt naar de site, klikt op de knoppen, leest de tekst en zegt: "Model A is beter omdat de knoppen makkelijker te vinden zijn."
• De digitale rechter (LLM): Kijkt naar de code en de screenshots en moet een oordeel vellen.

Het probleem is dat deze digitale rechters vaak vastlopen in complexe situaties. Ze zijn geweldig in simpele taken (zoals "is er een rode knop?"), maar falen vaak bij dingen die verandering en interactie vereisen.

2. De Testbaan: WEBDEVJUDGE

De auteurs van dit paper hebben een enorme testbaan gebouwd, genaamd WEBDEVJUDGE.

• De "Vergelijkingsarena": Ze hebben duizenden voorbeelden verzameld waar twee websites naast elkaar staan.
• De "Gouden Standaard": Menselijke experts hebben deze websites beoordeeld met een heel streng en gedetailleerd scorebord (een rubric). Dit scorebord is als een recept: het zegt niet alleen "maak een taart", maar "de taart moet 3 lagen hebben, de glazuur moet glad zijn, en de bessen moeten vers zijn".
• De Test: Vervolgens laten ze de digitale rechters (zoals GPT-4, Claude, en andere AI-modellen) deze websites beoordelen en kijken ze of hun oordeel overeenkomt met dat van de menselijke experts.

3. De Verbluffende Resultaten: De Digitale Rechter valt flink door de mand

De uitkomsten zijn verrassend en een beetje zorgwekkend:

• De kloof is groot: De beste digitale rechters halen ongeveer 70% overeenstemming met de menselijke experts. Dat klinkt hoog, maar in de wereld van AI betekent dit dat ze in 1 op de 3 gevallen een verkeerd oordeel vellen. Mensen doen dit veel beter.
• Vergelijken werkt beter dan scoren: Als je de AI vraagt om twee websites direct met elkaar te vergelijken ("Welke is beter?"), doen ze het beter dan als je ze vraagt om elke website apart een cijfer te geven (zoals een 7 of een 8). Het lijkt erop dat AI's beter zijn in het zeggen "deze is beter dan die" dan in het zeggen "dit is een 7".
• Agenten zijn niet de oplossing: Sommige mensen dachten: "Laten we de AI een robot-uitvoerder geven die echt op de site klikt en test!" (een agentic workflow). Maar dit bleek juist slechter te werken. Waarom? Omdat de robot vaak vastloopt of een knop mist, en dan denkt dat de website kapot is, terwijl hij het gewoon niet goed heeft gevonden. Het is alsof je een blindeman de opdracht geeft om een schilderij te beoordelen door er tegenaan te lopen; hij struikelt en denkt dat het schilderij slecht is.

4. Waarom Lukt het Ze Niet? (De Zwakke Plekken)

De onderzoekers hebben gekeken waar de digitale rechters precies falen:

1. Ze zijn te letterlijk: Stel, de opdracht was: "Maak een knop met de tekst 'Start'". De website heeft een knop met de tekst 'Begin'. Een mens denkt: "Ah, dat is hetzelfde." De AI denkt vaak: "Fout! Het woord is niet 'Start'." Ze begrijpen niet dat functie belangrijker is dan woorden.
2. Ze zien niet of iets werkt: Als een AI alleen naar de code kijkt, denkt hij vaak dat alles werkt. Als hij de site echt moet bezoeken (interactief), mist hij vaak knoppen of denkt hij dat iets niet werkt omdat hij zelf niet goed kan navigeren.
3. Voorkeur voor de eerste optie: Soms kiezen ze zomaar voor het eerste voorbeeld dat ze zien, puur omdat het eerst komt, niet omdat het beter is.

5. De Conclusie: Nog Even Geduld

De boodschap van dit paper is helder: We kunnen nog niet volledig vertrouwen op AI om te oordelen over complexe, interactieve software.

Het is alsof we een beginnende kok hebben die een recept kan lezen, maar nog niet goed kan proeven of snijden. We moeten nog veel leren over hoe we deze digitale rechters slimmer kunnen maken, zodat ze niet alleen naar de code kijken, maar ook begrijpen wat de gebruiker eigenlijk wil.

Kort samengevat:
WEBDEVJUDGE is de "rijbewijstest" voor AI-rechters. De test laat zien dat ze nog niet rijvaardig genoeg zijn om alleen te rijden in het drukke verkeer van moderne websites. Ze hebben nog veel meer training nodig voordat ze menselijke experts kunnen vervangen.

Technische samenvatting

Probleemstelling

Het paradigma van "LLM-as-a-judge" (waarbij grote taalmodellen menselijke evaluaties simuleren) heeft bewezen effectief te zijn voor gestructureerde, statische taken. Echter, de betrouwbaarheid van deze modellen in open-ended, dynamische omgevingen met complexe interacties blijft onvoldoende onderzocht. Webontwikkeling vormt een ideaal testveld voor dit probleem omdat het niet alleen afhankelijk is van statische code, maar ook van real-time interactie, visuele weergave en functionele logica. Bestaande benchmarks missen vaak de noodzakelijke validatie voor deze complexe, interactieve scenario's, wat leidt tot een kloof tussen de verwachte prestaties van geautomatiseerde beoordelaars en de werkelijkheid.

Methodologie: WEBDEVJUDGE

De auteurs introduceren WEBDEVJUDGE, een systematische meta-evaluatie benchmark specifiek ontworpen om de prestaties van LLMs als beoordelaars in webontwikkeling te testen.

1. Data Collectie en Filtering:

• De dataset is afgeleid van webdev-arena-preference-10k, maar onderworpen aan een strikt tweestaps-filterproces:
  • Query-gebaseerd: Verwijdering van dubbele, onveilige, onduidelijke of niet-uitvoerbare queries.
  • Omgevingsgebaseerd: Elke webimplementatie wordt gedeployed in een uniforme omgeving. Instances met deploy-fouten, lege pagina's of afhankelijkheidsproblemen worden verwijderd.
• Het resultaat is een hoogwaardige dataset van 654 instances met gepaarde webimplementaties en menselijke voorkeurslabels.

2. Annotatie via Rubric Trees:
Om subjectiviteit te minimaliseren en de grondwaarheid (ground truth) te waarborgen, gebruiken de auteurs een gestructureerde Rubric Tree-methode:

• Structuur: De beoordelingscriteria worden opgesplitst in drie dimensies: Intention (doel), Static Quality (UI/UX, code) en Dynamic Behavior (interactie).
• Generatie: Rubrics worden zowel handmatig als gegenereerd door LLMs (gemini-2.5-pro) om schaalbaarheid te garanderen.
• Validatie: Deze aanpak resulteerde in een inter-annotator overeenstemming van 89,7%, wat aanzienlijk hoger is dan de 63% die vaak wordt gerapporteerd in vergelijkbare benchmarks (zoals MT-Bench).

3. Evaluatie Paradigma's:
De benchmark test beoordelaars onder twee condities:

• Pairwise Comparison: Het model kiest de beste van twee implementaties.
• Single Answer Grading: Het model geeft een score aan een enkele implementatie.
• Observatievormen: Beoordelingen gebeuren op basis van code, screenshots, of een combinatie daarvan, en soms met interactieve agenten.

4. Evaluators:
Er wordt een breed scala aan beoordelaars getest, waaronder:

• Statische (M)LLMs (bijv. GPT-4.1, Claude-4, DeepSeek, Qwen).
• Agente workflows (Planner-Executor-Summarizer), waarbij UI-TARS-1.5 wordt gebruikt als uitvoerende agent.

Belangrijkste Bijdragen

1. WEBDEVJUDGE Benchmark: Een nieuwe, uitgebreide benchmark die zowel statische code-analyse als interactieve agent-navigatie ondersteunt voor webontwikkeling, met hoogwaardige, menselijk geverifieerde voorkeurslabels.
2. Uitgebreide Empirische Evaluatie: Een diepgaande analyse van diverse (M)LLMs en agente workflows, die aantoont dat huidige modellen nog niet het niveau van menselijke experts bereiken.
3. Foutanalyse en Diagnose: Identificatie van systematische zwaktes, waaronder het onvermogen om functionele equivalentie te herkennen en tekortkomingen in het verifiëren van de uitvoerbaarheid van taken.
4. WebDevJudge-Unit: Een gespecialiseerd diagnostisch dataset van 502 testcases om de capaciteit van beoordelaars om taakuitvoerbaarheid te verifiëren, te evalueren.

Resultaten en Bevindingen

De experimenten leveren enkele kritieke inzichten op:

• Kloof met Menselijke Experts: Er is een significante prestatiekloof van ongeveer 15% tussen de beste LLM-beoordelaars en menselijke experts. De hoogste overeenstemming (GPT-4.1 in pairwise modus) ligt rond de 70,34%, terwijl menselijke beoordelaars een overeenstemming van 84,56% tonen.
• Pairwise vs. Single Answer: Het pairwise comparison paradigma presteert consistent beter (gemiddeld >8% verbetering) dan single-answer grading. Dit suggereert dat relatieve oordelen (A vs. B) een ingebouwde capaciteit van modellen zijn, terwijl absolute scores (Likert-schalen) een moeilijk te kalibreren interne standaard vereisen.
• Beperkingen van Agente Workflows: Hoewel agenten geschikt lijken voor interactieve taken, presteren ze niet beter dan statische modellen. Dit komt door foutenaccumulatie in de planner-executor-summarizer keten (breekbare planning en onbetrouwbare uitvoering).
• Fundamentele Tekortkomingen:
  1. Functionele Equivalentie: Modellen falen vaak om te begrijpen dat verschillende implementaties (bijv. andere tekstlabels maar dezelfde functionaliteit) aan dezelfde eis voldoen. Ze houden zich te strikt aan letterlijke interpretaties.
  2. Verificatie van Uitvoerbaarheid: Statische code-analyses hebben een hoge recall maar lage precisie (ze zien code die eruitziet alsof het werkt, maar is het niet). Interactieve agenten hebben hoge precisie maar lage recall (ze falen door eigen operationele beperkingen, niet omdat de taak onmogelijk is).
• Observatie Modality: Code is de kritiekste invoermodus. Het weglaten van code leidt tot een grotere prestatiedaling dan het weglaten van screenshots.

Betekenis en Conclusie

WEBDEVJUDGE legt bloot dat het "LLM-as-a-judge" paradigma nog niet klaar is om menselijke evaluatie volledig te vervangen in complexe, interactieve domeinen zoals webontwikkeling. De paper benadrukt dat het verbeteren van beoordelaars niet alleen gaat om het verfijnen van prompts of rubrics, maar om het aanpakken van fundamentele tekortkomingen in kalibratie, contextueel redeneren (herkennen van equivalentie) en operationele betrouwbaarheid.

De auteurs concluderen dat een ideale beoordelaar waarschijnlijk een hybride aanpak vereist die de uitgebreide dekking van statische code-analyse combineert met de grondige verificatie van interactieve testing. Deze benchmark biedt een cruciale basis voor toekomstig onderzoek naar het ontwikkelen van betrouwbaardere geautomatiseerde evaluatoren voor de volgende generatie AI-systemen.