💻 computer science

BulkPR-Bench: Benchmarking Queue-Level Governance of Interacting Pull Requests

Dit artikel introduceert BulkPR-Bench, een nieuwe benchmark voor het evalueren van programmeeragenten op hun vermogen om interagerende pull requests te beheren door gezamenlijk veilige merge-volgordes te bepalen, wat onthult dat huidige modellen moeite hebben met het bereiken van betrouwbare governance over de gehele wachtrij, ondanks verbeteringen in het afhandelen van relationele afhankelijkheden.

Oorspronkelijke auteurs: Zetong Xiong, Qiao Zhao, Jun Zhang, Xueying Lyu, Zhi Li, Yixiang Tu, Xiaowen Yang, Yunjie Zhang, Yufeng Wang, Zhe Zhang, Kaize Yu, Hanwen Du, Zhongkai Sun, Zhuoxin Liu, Zekun Lin, Jianwen Yang, Ruinin

Gepubliceerd 2026-08-05

📖 3 min leestijd☕ Koffiepauze-leesvoer

CC BY 4.0

Oorspronkelijke auteurs: Zetong Xiong, Qiao Zhao, Jun Zhang, Xueying Lyu, Zhi Li, Yixiang Tu, Xiaowen Yang, Yunjie Zhang, Yufeng Wang, Zhe Zhang, Kaize Yu, Hanwen Du, Zhongkai Sun, Zhuoxin Liu, Zekun Lin, Jianwen Yang, Ruining Chen, Ying Zhang, Tingxuan Pan, Ke Chen, Shubin Han, Chuanhao Sun, Yehua Yang

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 een enorme, chaotische bouwplaats voor waar honderden teams tegelijkertijd aan verschillende kamers in dezelfde wolkenkrabber proberen te bouwen. In de wereld van software worden deze "kamers" Pull Requests (PR's) genoemd—voorgestelde wijzigingen aan een codebase. Meestal controleert een teamleider (of een geautomatiseerd systeem) één voorstel tegelijk. Als het er goed uitziet, laten ze het toe. Als het er slecht uitziet, sturen ze het terug. Dit werkt prima wanneer iedereen aan afzonderlijke, geïsoleerde taken werkt.

Maar wat gebeurt er als de teams met elkaar gaan interfereren? Misschien is Team A bezig met het bouwen van een nieuwe deur, terwijl Team B een raam vlak naast die deur probeert te installeren, en Team C de muur probeert te verstevigen waar zowel de deur als het raam aan vast moeten zitten. Als je ze één voor één binnenlaat zonder naar het hele plaatje te kijken, eindig je misschien met een deur die niet past, een raam dat de deur blokkeert, of een muur die instort. Dit is het probleem van interacterende pull requests. De grote vraag voor computerwetenschappers is: Kunnen we een "slimme manager" (een AI-agent) bouwen die niet alleen één kamer tegelijk controleert, maar de hele bouwplaats overziet, uitzoekt welke teams met elkaar vechten, welke teams moeten samenwerken, en de perfecte volgorde bepaalt om ze allemaal binnen te laten zonder dat het gebouw instort?

Dit is precies waar het artikel BulkPR-Bench zich mee bezighoudt. De onderzoekers hebben een gigantische, lastige test ontwikkeld om te zien of huidige AI-coderingsassistenten als deze slimme managers kunnen optreden. Ze zetten een scenario op met 18 verschillende real-world softwareprojecten en 581 nieuwe, lastige wijzigingen. Het doel was niet alleen om te zien of de AI een enkele bug kon oplossen, maar om te zien of de AI een hele wachtrij aan wijzigingen kon beheren, de verborgen relaties tussen hen kon ontdekken (zoals "Team B kan pas beginnen als Team A klaar is") en ze veilig kon samenvoegen (mergen).

De resultaten waren een mix van "niet slecht" en "nog een lange weg te gaan." De AI-agenten waren verrassend goed in het opsporen van sommige probleemgebieden. De beste AI-modellen slaagden erin om ongeveer 66,6% van de lastige groepen wijzigingen die ze moesten afhandelen, veilig samen te voegen, wat beter is dan de oude, eenvoudige methoden die simpelweg één voor één controleren (die slechts ongeveer 53,1% haalden). Echter, wanneer het kwam bij het ultieme doel—het succesvol samenvoegen van elke afzonderlijke wijziging in een hele wachtrij zonder ook maar één fout te maken—had de AI moeite. Van de 324 pogingen om een volledige wachtrij te beheren, waren er slechts 8 perfect.

Het artikel suggereert dat hoewel deze AI-"managers" beter worden in het begrijpen van hoe verschillende codewijzigingen met elkaar samenhangen, ze nog niet betrouwbaar genoeg zijn om op zichzelf al een hele bouwplaats te runnen. Ze missen vaak verborgen conflicten of krijgen de volgorde verkeerd, wat leidt tot onveilige samenvoegingen. De onderzoekers ontdekten dat het de AI meer informatie tegelijk geven (het tegelijkertijd zien van meer wijzigingen) hielp, maar dat het het probleem niet volledig oploste. Kortom, de AI leert een goede voorman te zijn voor kleine groepen, maar is nog niet klaar om de hoofdaannemer voor het hele gebouw te zijn.

Technische Samenvatting: BulkPR-Bench

Probleemstelling

Huidige benchmarks voor coding-agents richten zich steeds meer op langetermijn-, end-to-end- en interactieve ontwikkelingstaken. Deze benchmarks richten zich echter doorgaans op een enkele gevraagde uitkomst of een vaste sequentie van wijzigingen. In de echte software engineering bestaat ontwikkeling vaak uit een wachtrij van interagerende Pull Requests (PR's). Wanneer PR's met elkaar interageren, kunnen ze syntactische of semantische conflicten, afhankelijkheden, dubbel werk of "alles-of-niets"-groeperingen vertonen.

Sequentiële policies die PR's één voor één verwerken (bijv. greedy no-deferral) schieten in deze context vaak tekort. Ze kunnen combinaties samenvoegen die de publieke Continuous Integration (CI) passeren, maar die falen bij verborgen veiligheidscontroles, zij het dat ze geldige wijzigingen verwerpen die alleen samen werken, of er niet in slagen de maximale veilige subset van wijzigingen te leveren. De kernuitdaging is queue-level governance: een agent moet consequentiële relaties tussen PR's herstellen, een veilige subset selecteren om te mergen, en een uitvoerbare volgorde bepalen, terwijl hij opereert onder een begrensde, rollende zichtbaarheid van de wachtrij.

Methodologie: BulkPR-Bench

De auteurs introduceren BulkPR-Bench, een uitvoerbare benchmark ontworpen om agents te evalueren op deze queue-level governance taak.

Constructie van de Benchmark

Dataset: De suite bestaat uit 581 nieuw geautoriseerde kandidaat-PR's verdeeld over 18 echte repositories (dekend de Python, Go, en TypeScript/Node/Bun ecosystemen).
Counterfactual Ground Truth: In tegen tegenstelling tot historische PR-data, die geen waarheid kan bieden voor ongeteste combinaties, construeert BulkPR-Bench kandidaten op bevroren repository-snapshots.
- Uitvoerbare Validatie: De benchmark valideert de "gold relation graph" via geregistreerde repository-executie. Het gebruikt verborgen verifiers die gebonden zijn aan productgedrag om publiek onzichtbare conflicten te detecteren.
- Oracle: Een exacte solver berekent de grootste veilige subset (OPT) en een maximum-safe witness set voor elke pool, wat de grondwaarheid vaststelt voor de scoring.
Taakprotocol:
- Rolling Visibility: PR's worden onthuld in batches van grootte $K$ (bijv. $K=32$ ). Toekomstige batches zijn verborgen voor de agent.
- Interactie: De agent dient atomaire merge-voorstellen, deferrals in en werkt een getypeerd relationeel grootboek bij (het bijhouden van conflicten, afhankelijkheden, alles-of-niets groepen, etc.).
- Scoring: De evaluatie is gebaseerd op het gerealiseerde mergeplan dat door de executor wordt geaccepteerd, niet op het geclaimde plan van de agent. Voorstellen zijn atomair; als een batch faalt bij de publieke gate, wordt geen enkel lid van die batch geaccepteerd.

Metrieken en Diagnostiek

Het artikel definieert verschillende metrieken om prestaties te evalueren:

Relational Delivery Score (RDS): De primaire ranking-metriek. Het scoort veilige levering en correcte afwijzing over relation groepen (verbonden componenten van constraints). Dit zorgt ervoor dat een fout in één groep niet een correcte beslissing in andere groepen bestraft.
Global Safety-Gated Yield (Global-SGY): Een strikte metriek die de levering van het volledige gerealiseerde wachtrijplan meet, inclusief relation-vrije kandidaten. Het vereist dat het gehele plan geldig, veilig en uitvoerbaar is.
Exact Completion: Een binaire certificering die aangeeft of de agent exact de optimale veilige subset in de juiste volgorde heeft samengevoegd zonder fouten.
Diagnostiek:
- CriticalRecall: Meet het vermogen van de agent om consequentiële relaties te herstellen, gewogen door de kritikaliteit van de relatie (d.w.z. hoeveel het weglaten ervan leidt tot onveilige beslissingen).
- Gold-fed: Een diagnostische arm waarbij de agent wordt voorzien van de betrouwbare gold subgraph van relaties die tot nu toe zijn gezien, om de resterende "headroom" te meten na het herstel van relaties.

Belangrijkste Bijdragen

Taakdefinitie: Formaliseert de queue-level governance taak, waarbij relation recovery, subset selectie, uitvoerbare ordening en begrensde rolling visibility aan elkaar worden gekoppeld.
Infrastructuur: Biedt een uitvoerbare relationele constructie-pipeline die nieuwe kandidaten op echte snapshots autoreert en hun relaties en veilige optima valideert via repository-executie.
Evaluatiekader: Introduceert RDS als de enige ranking-metriek voor relationele levering, naast Global-SGY en Exact Completion voor de inzetbaarheid van de gehele wachtrij.
Empirisch Bewijs: Presenteert een formele evaluatie over 18 repositories met behulp van zes state-of-the-art coding agents.

Experimentele Resultaten

De evaluatie omvatte zes modellen (Claude-Opus-4.8, DeepSeek-V4-Pro, GLM-5.2, GPT-5.4, Kimi-K3, Qwen3.7-Max) en drie deterministische sequentiële baselines.

RDS Prestaties: Onder het primaire gebufferde protocol ( $K=32$ ) bereikten de top drie modellen RDS-schattingen van 66,6% (Claude), 62,0% (GPT) en 57,9% (GLM). De sterkste sequentiële baseline (CI-Fixedpoint) scoorde 53,1%.
Whole-Queue Success: Ondanks verbeteringen in RDS, was Exact Completion extreem zeldzaam. Slechts 8 van de 324 modelruns (over alle modellen en repositories) voltooiden een wachtrij exact.
Global-SGY: Het topmodel (GPT-5.4) behaalde een Global-SGY van 13,0%, terwijl alle sequentiële baselines een score van 0,0% behaalden.
Relation Recovery: CriticalRecall varieerde van 35,2% tot 57,7%.
Gold-Fed Gap: Wanneer voorzien van gold-relaties, verbeterde de RDS aanzienlijk (variërend van 77,5%–99,1%), wat duidt op aanzienlijke headroom voor verbetering indien agents relaties perfect zouden kunnen herstellen.
Foutmodi: De dominante uitkomst was unsafe merging (69,8% van de runs), gevolgd door het niet mergen van iets (18,2%). Slechts 8,3% van de runs produceerde inzetbare, niet-lege plannen.

Betekenis en Claims

Het artikel stelt dat hoewel huidige coding agents verbetering laten zien ten opzichte van sequentiële baselines in het afhandelen van relationele constraints (hogere RDS), zij deze winsten nog niet vertalen naar betrouwbare queue-level governance.

Kloof tussen Lokaal en Globaal: Hoge RDS-scores op relation groepen garanderen geen succesvol, veilig en uitvoerbaar plan voor de gehele wachtrij.
Bottlenecks: Het bewijs suggereert dat onvolledige relation recovery een significante factor is, maar het isoleert dit niet van andere bottlenecks zoals subset selectie, ordening of feedback-gestuurde revisie.
Beperkingen: De auteurs benadrukken dat de benchmark een doelgerichte suite van geconstrueerde PR's gebruikt, en geen natuurlijk monster van productie-wachtrijen. De resultaten karakteriseren de prestaties op deze specifieke pools in plaats van te generaliseren naar alle software-repositories. De evaluatie richt zich op de veiligheid van de repository-status (tests/verifiers) in plaats van op de zakelijke waarde of claims van de ontwikkelaarspopulatie.

Concluderend stelt BulkPR-Bench vast dat queue-level governance een uitdagend, onopgelost probleem blijft voor huidige agents, gekenmerkt door een disconnect tussen gedeeltelijk relationeel succes en het vermogen om een veilig, optimaal mergeplan voor een gehele wachtrij uit te voeren.