💻 computer science

SpecBench: Evaluating Specification-Level Reasoning for Software Engineering LLM Agents

Dit artikel introduceert SpecBench, een nieuwe benchmark die de vaardigheid van software-engineeringagenten evalueert om gebreken te identificeren en onvolledige of ambiguïteit bevattende systeemspecificaties te verbeteren door middel van expertniveau-redenering, waarmee een kritieke lacune wordt aangevuld die door bestaande op code-generatie gerichte benchmarks is achtergelaten.

Oorspronkelijke auteurs: Grant Hamblin, Kevin Song, Zhanda Zhu, Anand Jayarajan, Sihang Liu, Nandita Vijaykumar, Gennady Pekhimenko

Gepubliceerd 2026-05-29

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Grant Hamblin, Kevin Song, Zhanda Zhu, Anand Jayarajan, Sihang Liu, Nandita Vijaykumar, Gennady Pekhimenko

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

Het Grote Plaatje: Van "Bouwen" naar "Plannen"

Stel je voor dat je een robot huurt om een huis te bouwen.

Oude benchmarks (zoals SWE-Bench): Deze tests geven de robot een perfect, gedetailleerd blauwdruk en vragen: "Kun je de muur precies bouwen zoals getekend?" De robot hoeft alleen maar de bakstenen te leggen. Als het blauwdruk zegt "rode baksteen", legt de robot een rode baksteen.
Het probleem in de echte wereld: In het echte leven is het blauwdruk waarmee je begint vaak rommelig. Het kan zeggen "zet hier een deur" zonder te specificeren of het een voor- of achterdeur is, of het kan vergeten te vermelden dat de fundering dieper moet vanwege het bodemtype. Als de robot gewoon begint te bouwen op basis van dat rommelige blauwdruk, kan het huis later instorten.
De nieuwe benchmark (SpecBench): Dit paper introduceert een test die de robot niet vraagt om het huis te bouwen. In plaats daarvan vraagt het de robot om het rommelige blauwdruk te lezen en de fouten aan te wijzen voordat de bouw begint. Het test het vermogen van de robot om te zeggen: "Hé, dit plan mist een deur," of "Deze muur raakt een boom," of "Je hebt niet gezegd welk soort hout je moet gebruiken."

Wat is SpecBench?

SpecBench is een nieuwe test die is ontworpen om te evalueren hoe goed AI-agenten (slimme computerprogramma's) kunnen redeneren over specificaties van software.

In software-engineering schrijven ze, voordat iemand code schrijft, een "specificatie" (een plan). Bij grote projecten zoals Linux, Kubernetes of React doorlopen deze plannen een proces dat een RFC (Request for Comments) wordt genoemd. Dit is als een gemeentehuisvergadering waar experts het plan bespreken, bekritiseren en verfijnen totdat het perfect is.

SpecBench simuleert deze gemeentehuisvergadering. Het geeft een AI:

Het initiële, rommelige plan (de RFC).
De geschiedenis van hoe het project in het verleden heeft gewerkt.
De huidige code van het project.

De taak van de AI is om te fungeren als een senior engineer en de fouten in het plan te vinden. Het moet dingen vinden die:

Ontbreken: "Je bent vergeten te zeggen wat er gebeurt als het internet uitvalt."
Verwarrend zijn: "Je zei 'snel', maar bedoelde je 1 seconde of 1 minuut?"
In strijd zijn: "Je zei dat deze functie veilig is, maar het breekt die andere regel."
Verkeerd zijn: "Dit idee botst met hoe we het altijd hebben gedaan."

Hoe hebben ze de test gebouwd?

De onderzoekers keken naar vijf echte software-reuzen: Kubernetes, React, Rust, TVM en vLLM.

Ze namen echte historische documenten waar mensen nieuwe functies voorstelden. Vervolgens keken ze naar de echte discussies waar menselijke experts die voorstellen uit elkaar haalden en de gaten vonden. Deze "gaten" werden de Golden Set (de juiste antwoorden).

De uitdaging van "menselijke variatie":
Soms geeft één expert om snelheid, terwijl een ander om beveiliging geeft. Om dit op te lossen, gebruikten de onderzoekers een panel van AI-rechters om te stemmen welke kritiek het belangrijkst was. Ze verdeelden de fouten in twee groepen:

Kernfouten: De grote, duidelijke fouten waar bijna iedereen het over eens is (zoals een ontbrekende fundering).
Uitgebreide fouten: Kleinere, genuanceerdere problemen die sommige experts kunnen opmerken en andere misschien niet.

Het "Open World"-probleem:
In een codetest faalt de robot als het verkeerde code schrijft. Maar in een planningstest kan de robot een nieuwe fout vinden die de oorspronkelijke mensen hebben gemist. De onderzoekers besloten: "Als de robot een fout vindt die niet in ons antwoordensleutel staat, kunnen we niet zeggen dat het verkeerd is, maar we kunnen er ook geen punten voor geven." Dus gaven ze de robot een beperkt aantal gokken (een budget) en scoorden ze alleen op hoeveel van zijn gokken overeenkwamen met de bekende "Gouden" fouten.

Hoe presteerde de AI?

De onderzoekers testten de slimste beschikbare AI-agenten (zoals GPT-5.4, Claude en Codex).

De score: De beste AI behaalde ongeveer 44,4% nauwkeurigheid.
Wat dit betekent: Zelfs de slimste AI mist nog steeds meer dan de helft van de kritieke fouten in complexe softwareplannen. Ze worden beter in het schrijven van code, maar ze zijn nog steeds niet erg goed in het plannen van code.
Het gat: De AI was veel beter in het vinden van de "Kern"-fouten (de grote, duidelijke) dan de "Uitgebreide"-fouten (de subtiele, lastige).

Waarom is dit belangrijk?

Momenteel hebben we AI die geweldig is in het volgen van instructies (Implementatie). We hebben nog geen AI die geweldig is in het ontwerpen van de instructies (Specificatie).

Dit paper laat zien dat terwijl AI goed wordt in het zijn van een "bakker", het nog steeds worstelt met het zijn van de "architect". Als we willen dat AI volledige softwareprojecten runt, moet het leren hoe het de gaten in het plan kan opsporen voordat de eerste regel code is geschreven.

Kortom: SpecBench is een rapportkaart die laat zien dat onze AI-architecten nog steeds leren hoe ze de blauwdrukken moeten lezen voordat ze beginnen met bouwen.

Technische Samenvatting: SpecBench

Probleemstelling

Huidige benchmarks voor software-engineering (SWE), zoals SWE-Bench, evalueren voornamelijk redenering op implementatieniveau: het vermogen van een agent om code te genereren die tests doorloopt, gegeven een vaste, nauwkeurige en als correct veronderstelde specificatie. Deze formulering negeert een kritieke fase in de softwareontwikkeling in de praktijk: ontwerp van specificaties. In complexe systemen zijn initiële ontwerpproposals vaak onvolledig, dubbelzinnig of gebrekkig, wat uitgebreide expertreview en herziening vereist voordat implementatie kan plaatsvinden. Bestaande benchmarks meten niet het vermogen van een agent om deze tekortkomingen te identificeren of te redeneren over systeemontwerp zonder uitvoeringsfeedback.

Methodologie

De auteurs introduceren SpecBench, een benchmark ontworpen om redenering op specificatieniveau te evalueren. De gemeten kerncapaciteit is het vermogen om volledige, eenduidige, consistente en correcte systeemspecificaties te genereren door tekortkomingen in initiële ontwerpproposals te identificeren.

Constructie van de Dataset

Bron: Taken zijn afgeleid van de Request for Comments (RFC)-processen van vijf diverse open-source repositories: Kubernetes, React, Rust, TVM en vLLM.
Invoer: Voor elke taak ontvangt een agent:
1. Het initiële RFC-ontwerpvoorstel.
2. De projectcodebase (bij de commit voorafgaand aan het RFC-voorstel).
3. De geschiedenis van eerdere RFC-discussies en beslissingen.
- Agents hebben geen toegang tot internetbronnen of Git-geschiedenis na de datum van het voorstel.
Taak: De agent moet tekortkomingen in de specificatie (weglatingen, dubbelzinnigheden, inconsistenties of onjuiste aannames) in het initiële voorstel identificeren.
Classificatie van Tekortkomingen: Tekortkomingen worden gecategoriseerd op basis van IEEE Std. 1028-1997 en eerdere werken in vier klassen:
- Weglating: Ontbrekende noodzakelijke informatie.
- Dubbelzinnig: Informatie met meerdere interpretaties.
- Inconsistent: Wederzijdse tegenstrijdigheden binnen het voorstel of met het bestaande systeem.
- Onjuist: Tegenstrijdigheden met voorgaande documenten of informatie.

Constructie en Evaluatie van de Benchmark

Gouden Set: De grondwaarheid bestaat uit tekortkomingen die door oorspronkelijke bijdragers zijn aangekaart tijdens historische RFC-discussies.
Omgaan met Expertvariatie: Om ruis door verschillende expertprioriteiten aan te pakken, gebruiken de auteurs een op LLM gebaseerd expertpanel om geëxtraheerde tekortkomingen te beoordelen op een 5-punts Likertschaal. Tekortkomingen worden gelabeld als "core" (gemiddelde score ≥ 3,0 en ≥ 2/3 expertgoedkeuring) of "extended". Core-items krijgen dubbele gewichting in de scoring.
Validatie in Open Wereld: In tegenstelling tot deterministische testsets is de ruimte van geldige specificatiekloven open-ended. De auteurs hanteren een methodologie voor Informatieretrieval (IR):
- Voorspellingen die overeenkomen met de gouden set zijn verifieerbaar geldig.
- Voorspellingen die niet in de gouden set staan, worden behandeld als onbeoordeeld (niet per se onjuist) in plaats van als vals-positieven.
- Er wordt een begrensde voorspellingsbegroting opgelegd ( $N = \lceil 1,25 \times |G| \rceil$ ) om te voorkomen dat agents de evaluatie overspoelen met kwalitatief slechte gokken.
Beoordelingsmechanisme: Om semantische matching tussen vrijtekstvoorspellingen en gouden sets te hanteren, wordt een tweestapsproces gebruikt:
1. Gestructureerde Decompositie: Tekortkomingen worden ontleed in Onderwerp (systeemcomponent), Predicaat (aard van de tekortkoming) en Impact (gevolg).
2. Ensemble-beoordeling: Twee onafhankelijke LLM-beoordelaars (GPT-5.4 en Sonnet 4.6) voeren vier trials per taak uit. Een match wordt geaccepteerd als deze in ten minste 3 van de 4 trials voorkomt.

Belangrijkste Bijdragen

SpecBench Benchmark: De eerste benchmark die specifiek gericht is op redenering op specificatieniveau, ontkoppeld van code-implementatie.
Nieuwe Evaluatieprotocol: Een methodologie voor het evalueren van open-ended specificatiekritieken met behulp van een begrensde voorspellingsbegroting, gewogen scoring op basis van expertconsensus en gestructureerde semantische matching (SPI-tripels) om linguïstische variatie te hanteren.
Empirische Baselines: Evaluatie van state-of-the-art SWE-agents (inclusief Codex, Claude en Gemini-varianten) op deze nieuwe taak, waarbij significante gaten in de huidige capaciteiten aan het licht komen.

Resultaten

Algemene Prestatie: De best presterende agent, GPT-5.4 (verwezen naar als Codex-5.4 in het resultatenhoofdstuk), behaalde een nauwkeurigheid van 44,4%. Alle geëvalueerde agents bleven onder de 45%, wat aangeeft dat er aanzienlijke ruimte voor verbetering is.
Core versus Extended: Agents presteerden significant beter op core-tekortkomingen (hoge expertconsensus) dan op extended-tekortkomingen, wat overeenkomt met de constructie van de dataset.
Variatie per Repository: De prestaties varieerden per repository, waarbij de beste agent de grootste voorsprong liet zien bij React- en vLLM-taken.
Betrouwbaarheid van de Beoordelaar: De onderlinge overeenstemming tussen beoordelaars werd gemeten met behulp van paarsgewijze Jaccard-similariteit, met plannen om de diversiteit van beoordelaars in toekomstige versies te vergroten.

Betekenis en Claims

Het artikel beweert dat SpecBench een kritieke kloof in de evaluatie van SWE-agents aanpakt door de focus te verschuiven van het uitvoeren van duidelijke eisen naar het ontwerpen ervan. De auteurs betogen dat:

Software-engineering in de praktijk vereist dat agents gemeenschapswaarden begrijpen (bijvoorbeeld geheugenveiligheid in Rust versus API-stabiliteit in React) en historische ontwerpbeslissingen, niet alleen codegeneratie.
Huidige benchmarks uitgaan van "perfecte specificaties", wat de realiteit van complexe systemen niet weerspiegelt waar initiële proposals vaak gebrekkig zijn.
SpecBench redenering op specificatieniveau isoleert, distinct van de redenering op implementatieniveau die in eerdere werken zoals SWE-Bench wordt benadrukt.

De auteurs merken op dat dit een vroege versie van de benchmark is die zich richt op het identificeren van tekortkomingen. Toekomstig werk zal SpecBench uitbreiden met herzieningstaken (het corrigeren van de specificaties) en menselijke expertvalidatie opnemen om menselijke prestatiebaselines vast te stellen en de overeenstemming tussen mens en LLM te meten.