Technische Samenvatting: AgentLens

Probleemstelling

Huidige benchmarks voor programmeeragenten reduceren evaluatie voornamelijk tot een binaire uitkomst: heeft de agent de uiteindelijke test doorstaan? Hoewel dit voldoende is voor onderzoekslidmaatschappen (leaderboards), schiet deze "single-bit" metriek tekort bij het vatten van de realiteit van interactieve programmeerassistenten die in productie worden gebruikt. Een taak kan een nauwe verificatiecontrole passeren terwijl de agent onbetrouwbaar gedrag vertoont, overmoedig is, slecht gebruik maakt van tools of niet strookt met de intentie van de gebruiker. Omgekeerd kan een run die een uiteindelijke controle niet doorstaat, waardevolle intermediaire gedragingen hebben getoond, zoals correcte foutlokalisatie of gracieuze foutherstel.

Het kernprobleem is het gebrek aan een benchmark die de volledige trajectorie van de interactie van een agent evalueert. Ontwikkelaars moeten niet alleen begrijpen of een taak is voltooid, maar ook hoe deze is voltooid: hoe de agent instructies opvolgde, tools gebruikte, werk verifieerde, herstelde van fouten en communiceerde met de gebruiker. Bestaande benchmarks reduceren deze dynamiek vaak tot eindstatussen of vertrouwen op taken die te eenvoudig zijn om de dagelijkjes workflow van ontwikkelaars te weerspiegelen.

Methodologie

AgentLens is een in productie geteste benchmark die ontworpen is om interactieve code-agenten te evalueren door volledige interactietrajectorieën te analyseren. De methodologie combineert formele verificatie met door LLM's gestuurde kwalitatieve beoordelingen.

1. Taakset en Simulatie

• Definitie van Trajectorie: Een trajectorie omvat het volledige sessieverslag: gebruikersberichten (gesimuleerd), antwoorden van de agent, tool-aanroepen, bestandswijzigingen, commando-uitvoeringen, verificatiepogingen en de uiteindelijke repository-status.
• Taakgeneratie: Scenario's zijn afgeleid van interviews met programmeurs (terugblikkend op recent werk) en geanonimiseerde samenvattingen van productiegebruik. Deze zijn georganiseerd in workflows die inspectie van code, bewerking, documentatie, debugging en testen omvatten.
• Gebruikerspersona's: De benchmark maakt gebruik van door LLM's gesimuleerde gebruikers met verschillende persona's om de robuustheid van de agent te testen:
  • Default (Standaard): Een ontspannen gebruiker die alleen ingrijpt bij duidelijke mislukking.
  • Helpful (Behulpzaam): Een coöperatieve gebruiker die begeleiding biedt bij fouten.
  • Toxic (Giftig): Een licht gefrustreerde gebruiker die de agent uitdaagt maar de taakdoelstelling in stand houdt.
• Schaal: De initiële release bevat 16 scenario's die elk met twee persona's worden uitgevoerd, wat resulteert in 32 trajectorieën per agent.

2. Evaluatieprotocol

AgentLens evalueert elke trajectorie met behulp van twee complementaire mechanismen:

A. Formele Verificatie
Objectieve controles worden toegepast waar mogelijk, inclusief:

• Repository Status Checks: Controleren of alleen toegestane bestanden zijn gewijzigd en of de doelbestanden daadwerkelijk zijn aangepast.
• Regex Checks: Het verifiëren van specifieke patronen in code, tool-argumenten of chatgeschiedenis.
• Testuitvoering: Het draaien van testsuites (bijv. via Maven/Gradle) en het controleren van de dekking.
• Statische Analyse: Het aanroepen van IDE-tools om fouten of waarschuwingen te detecteren.
  Een run slaagt voor formele verificatie alleen als alle toepasbare verifieerders slagen.

B. LLM Judge Reviews
LLM-judges beoordelen de volledige trajectorie over vijf specifieke dimensies, waarbij zowel een score als een geschreven, op bewijs gebaseerd narratief wordt geproduceerd:

1. ENDRESULT (Eindresultaat): Volledigheid en geschiktheid voor het doel met betrekking tot de uiteindelijke uitkomst.
2. INSTRUCTIONCOMPLIANCE (Instructie-naleving): Naleving van expliciete regels, volgordebeperkingen en meta-instructies.
3. PITFALLS (Valstrikken): Identificatie van corrigeerbare gedragsfouten (bijv. misbruik van tools, niet-productieve loops, voortijdige voltooiing, ontbrekende validatie).
4. PLEASANTNESS (Aangenaamheid): Kwaliteit van de interactie met de gebruiker (helderheid, nauwkeurigheid, behulpzaamheid, productiviteit).
5. TOOLCALLS (Tool-aanroepen): Kwaliteit van het gebruik van tools, inclusief keuze, juistheid van argumenten en herstel van fouten.

C. Aggregatie en Metrieken

• Quality Index (QI): Een enkele geaggregeerde score berekend als het ongewogen gemiddelde van de vijf judge-metrieken en de formele verificatie-succesratio.
• Side-by-Side Reviews: Voor comparatieve analyse vergelijkt een paarwijze judge twee agenten op dezelfde taak, waarbij eerdere single-trajectorie beoordelingen als primair bewijs worden gebruikt om positionele bias te minimaliseren.
• Telemetrie: Harde statistieken (latentie, kosten, token-doorvoer, succesratio van tool-aanroepen) worden verzameld om operationele betrouwbaarheid te kwantificeren.

3. Betrouwbaarheids- en Biascontroles

De auteurs hebben verschillende controles uitgevoerd om robuustheid te garanderen:

• Variantieanalyse: Herhaalde runs toonden aan dat variantie geconcentreerd is in de formele verificatie (instabiele taakvoltooiing) in plaats van in de judge-scoring.
• Positionele Bias: Tests waarbij de volgorde werd omgedraaid, gaven aan dat side-by-side scores grotendeels ongevoelig zijn voor de volgorde van presentatie van de agent.
• Judge Self-Preference: Hoewel judges een lichte voorkeur vertoonden voor hun eigen modelfamilies (met name in de subjectieve "Pleasantness" metriek), was het effect klein en veranderde het de gemiddelde winnaar in vergelijkingen tussen frontier-modellen niet.

Belangrijkste Resultaten

De benchmark werd geëvalueerd op Java-coderingstaken met diverse modellen (bijv. Opus 4.7, GPT-5.5, DeepSeek V4, Gemini 3.1) over twee harnesses (Explyt AI Agent en Claude Code).

• Divergerende Ranglijsten: De AgentLens Quality Index (QI) correleert matig met publieke benchmarks (bijv. Spearman $\rho = 0.82$ met APEX-Agents), maar divergeert significant van reasoning-georiënteerde benchmarks. Modellen die geoptimaliseerd zijn voor academische redeneertaken scoren vaak lager op AgentLens, terwijl modellen die gebouwd zijn voor langdurig toolgebruik hoger scoren.
• Diagnostische Inzichten:
  • Gemini 3.1 Pro Preview: Presteerde ondermaats door problemen met de betrouwbaarheid van de agent-loop (overslaan van stappen, voortijdige wijzigingen), in plaats van door een gebrek aan code-generatiecapaciteit.
  • DeepSeek V4 Pro vs. Flash: Pro demonstreerde betere instructie-naleving en controle, terwijl Flash een hogere doorvoer en voltooiingspercentages bereikte door beperkingen te versoepelen.
  • Kimi K2.6: Rangschikte als laatste, maar de review onthulde dat de oorzaak een provider-zijde tool-parser bug was (malformed arguments), en niet een gebrek aan redeneervermogen.
  • Regressiedetectie: De nightly pipeline identificeerde succesvol een race condition in parallel tool calling die een ConcurrentModificationException veroorzaakte, wat onzichtbaar was in het uiteindelijke antwoord maar wel werd gevangen in de trajectorie-review.

Betekenis en Bijdragen

Het artikel claimt de volgende bijdragen:

1. Production-Assessed Benchmark: Een framework dat interactieve code-agenten evalueert op basis van realistische, meerstaps workflows in plaats van geïsoleerde eindstatussen.
2. Trajectorie-niveau Protocol: Een innovatieve evaluatiemethode die formele verificatie combineert met door LLM's geschreven reviews die uitleggen waarom een score is toegekend, waarbij de kwaliteit van de uitkomst wordt gescheiden van de kwaliteit van het proces.
3. Diagnostisch Nut: Het systeem is niet alleen ontworig voor ranking, maar ook voor het diagnosticeren van modelgedrag, het vergelijken van versies en het detecteren van productregressies in een continue integratie-pipeline.
4. Open Source Release: De benchmarkcode, taakfolds en de evaluatiepipeline worden publiekelijk vrijgegeven om verder onderzoek en adoptie te faciliteren.

De auteurs concluderen dat het veld van agentic coding benchmarks ondergesatureerd is wat betreft productie-achtige evaluatie. AgentLens beoogt deze niche te vullen door een "leesbare uitleg" te bieden van de prestaties van de agent, waardoor ontwikkelaars gerichter kunnen corrigeren op basis van specifieke faalmodi (bijv. tool-instabiliteit versus instructie-naleving) in plaats van op basis van een enkele, ondoorzichtige metriek.