💬 NLP

RuBench: A Repository-Level Agentic Coding Benchmark with Natively Authored Russian Task Specifications

RuBench is een repository-niveau agentic coding benchmark met 25 inheems geschreven Russische taakspecificaties uit live open-source projecten, ontworpen om productwaardige coding agents te evalueren op echt onderhoudswerk, terwijl datacontaminatie wordt weerstaan en kritieke inzichten in de gedrag van uitgerolde systemen worden onthuld door middel van rigoureuze statistische analyse en trajectauditing.

Oorspronkelijke auteurs: Evgeny Shilov (Independent Researcher)

Gepubliceerd 2026-07-08

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Evgeny Shilov (Independent Researcher)

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 voor dat je een team van deskundige monteurs inhuurt om een vloot complexe, op maat gemaakte racewagens te repareren. Tot nu toe waren de meeste tests voor deze monteurs geschreven in perfect, formeel Engels, als een technische handleiding. Maar in de echte wereld praten klanten niet als handleidingen; ze praten als mensen. Ze zeggen dingen als: "Mijn auto begon te schudden elke keer als ik op de rem trapte op een regenachtige dinsdag," in hun eigen moedertaal.

RuBench is een nieuwe test die ontworkt is om te zien of AI-coderingsassistenten daadwerkelijk deze rommelige, echte klantverzoeken kunnen begrijpen wanneer deze in het Russisch zijn geschreven, en niet in het Engels.

Hier is een uitsplitsing van hoe de test werkt, wat er gebeurde en de verrassende wending die de onderzoekers ontdekten, met behulp van eenvoudige analogieën.

1. De Test: Een "Echte" Garage

De meeste eerdere tests gaven AI-agenten een heldere, Engelse beschrijving van een bug. RuBench is anders:

De Auto's: De test gebruikt vijf echte, populaire open-source softwareprojecten (zoals aiohttp of Laravel). Dit zijn geen nep-puzzels; het zijn levende codebases die door duizenden ontwikkelaars worden gebruikt.
De Verzoeken: In plaats van een formele bugrapportage hebben de onderzoekers 25 nieuwe verzoeken vanaf nul geschreven in het Russisch. Deze klinken als een bedrijfseigenaar die klaagt tegen een aannemer: "De bot crasht wanneer we hem admin maken; fix het, maar ga niet de bestaande chats kapot."
De Mysterieuze Doos: De onderzoekers hebben het "antwoordmodel" (de eigenlijke code-fix en de tests die bewijzen dat het werkt) verborgen. De AI moet de fix zelf uitzoeken. Alleen de onderzoekers hebben de sleutel om te controleren of de AI is geslaagd.
Versheid: Alle bugs werden gevonden in code-updates die zijn gemaakt nadat de AI-modellen waren getraind. Dit zorgt ervoor dat de AI de antwoorden niet simpelweg heeft kunnen onthouden uit zijn trainingsdata.

2. De Monteurs: Wie heeft de klus geklaard?

De onderzoekers testten vier verschillende "monteursteams" (combinaties van softwaretools en AI-modellen). Ze lieten elk team de 25 reparaties drie keer uitvoeren om te zien hoe consistent ze waren.

De Sterprestatie: Het team dat Claude Code met het "Opus 4.8"-model gebruikte, was de beste. Het loste ongeveer 79% van de problemen succesvol op.
Het Middenveld: Het "Sonnet 5"-model deed het bijna net zo goed (75%), en het "GPT-5.5"-model (via Codex CLI) loste ongeveer 67% op.
De Moeizame Monteur: Het "Haiku 4.5"-model (een goedkopere, snellere versie) loste slechts ongeveer 53% van de taken op.

De Kanttekening: Omdat er slechts 25 taken waren, was het verschil tussen de top drie teams niet statistisch "bewezen" echt — het zou ook gewoon geluk kunnen zijn geweest. Echter, de kloof tussen de topteams en het moeizame Haiku-model was enorm en duidelijk. De topteams losten een compleet andere klasse problemen op dan het onderste team.

3. De Grote Verrassing: De "Stille Substitutie"

Dit is het meest interessante deel van het paper. De onderzoekers testten ook een vijfde team met een gloednieuw model genaamd Fable 5.

Toen ze nauwkeurig naar de "black box"-logs keken van wat de AI aan het doen was, ontdekten ze een geheim:

Bij 20% van de taken heeft het Fable 5-model het werk niet daadwerkelijk gedaan.
In plaats daarvan heeft het softwareproduct (Claude Code) Fable 5 stilletjes vervangen door het oudere, sterkere Opus 4.8-model halverwege de taak.
Waarom? Fable 5 heeft veiligheidscontroles die erg streng zijn. Toen het model een taak zag die te maken had met standaard internetprotocollen (zoals het repareren van een webheader), werd de veiligheidscontrole nerveus en zei: "Ik mag dit niet aanraken," waarna het systeem de taak automatisch aan Opus 4.8 overhandigde om het af te maken.

De Les: De onderzoekers realiseerden zich dat wanneer we AI-producten testen, we niet alleen het "brein" (het model) testen; we testen het "lichaam" (het hele softwarepakket). Als de software halverwege de taak stiekem van brein wisselt, geven de testresultaten een onjuist beeld van wat dat specifieke brein kan doen.

4. Het Eindoordeel

Succes: AI-agenten op productniveau zijn al goed genoeg om echt onderhoudswerk te kunnen afhandelen dat in een niet-Engelse taal (Russisch) is gespecificeerd. De beste opstelling loste bijna 8 van de 10 taken op.
Reality Check: De "goedkope" modellen (zoals Haiku) zijn nog steeds aanzienlijk zwakker en lossen slechts ongeveer de helft van de problemen op.
Methodologie: Het paper bewijst dat we, om eerlijke resultaten te krijgen, het volledige "dagboek" (traject) van de AI moeten bekijken om er zeker van te zijn dat het niet heeft valsgespeeld door van model te wisselen of de antwoorden online op te zoeken.

Kortom, RuBench laat zien dat AI goed wordt in het spreken van "mensentaal" (in het Russisch), maar het onthulde ook dat de software die deze AI's omhult soms sluw kan zijn door de werker te vervangen door een betere zonder dat dit wordt gemeld.

Technische Samenvatting: RuBench 1.0

Probleemstelling

Huidige benchmarks voor agentische codering op repository-niveau (bijv. SWE-bench) falen in het evalueren van een cruciale real-world capaciteit: het vermogen van coderingsagenten om taken te interpreteren en uit te voeren die inherent in niet-Engelse talen zijn gespecificeerd, met name in de stijl van klantverzoeken in plaats van gecureerde Engelse GitHub-issues. Bestaande "meertalige" benchmarks vertrouwen ofwel op basisontwerp op Engelse verklaringen of opereren op het niveau van snippets/enkele bestanden, waarbij ze de complexiteit van volledere repository-onderhoud missen. Bovendien lijden statische benchmarks aan oplossing-lekkage en memorisatie, terwijl evaluaties vaak de agent-harness loskoppelen van het model, waarbij wordt genegeerd hoe gedployeerde productconfiguraties (CLI + model + redeneerinspanning) het gedrag materieel beïnvloeden.

Methodologie

RuBench 1.0 introduceert een benchmark die is ontworpen om repository-niveau agentische codering te meten met native Russische specificaties.

Constructie van de Benchmark

Taakwinning: 25 taken zijn gewonnen uit fix-commits die tussen februari en juni 2026 zijn samengevoegd in vijf live open-source repositories: aioalph, aiogram, Laravel, NestJS en Fastify. Deze beslaan Python, PHP, TypeScript en JavaScript.
Native Specificaties: In tegen tegenstelling tot vertaalde benchmarks, bevat elke taak een specificatie die vanaf nul in het Russisch is geschreven, waarbij een verzoek van een bedrijfsleider wordt nagebootst (het beschrijven van symptomen, vereist gedrag en beperkingen) in plaats van een invoer van een developer issue tracker. Deze specificaties bestaan niet op het publieke web vóór de release.
Versheidspoort (Freshness Gate): Alle 25 taken dateren van na de trainingsdata-afkapwaarden van elk geëvalueerd model (variërend van juli 2025 tot januari 2026), wat een taak-per-taak contaminatie-argument garandeert.
Privé Oracle: Beoordeling vindt plaats door de regressietests van de upstream maintainer, die niet voor publieke release worden vrijgegeven. Een SHA-256 manifest van deze oracles is gecommit om de integriteit te verifiëren zonder de tests te onthullen.
Workspace: Agenten ontvangen een snapshot van de repository op de parent-commit van de fix, gestript van git-historie en oracle-tests.

Experimenteel Protocol

Configuraties: De studie evalueert vier gedployeerde productconfiguraties (CLI agent + model + maximale redeneerinspanning):
- Claude Code met Opus 4.8
- Claude Code met Sonnet 5
- Claude Code met Haiku 4.5
- Codex CLI met GPT-5.5
- Hors concours: Claude Code met Fable 5 (release 2 juli 2026).
Executie: Elke configuratie draait drie onafhankelijke keren per taak in geïsoleerde workspaces met netwerktoegang (vereist voor pakketinstallatie).
Metrieken: Prestaties worden gerapporteerd als pass@1 (fractie van succesvolle runs onder 3 pogingen) gemiddeld over 25 taken. Onzekerheid wordt gekwantificeerd via taakniveau Wilson 95% betrouwbaarheidsintervallen en gepaarde bootstrap-vergelijkingen (10.000 resamples).
Validiteitsaudits: Trajecten worden gecontroleerd op oracle-escape en, cruciaal, op model-substitutie (om te waarborgen dat het uitvoerende model overeenkomt met het gevraagde model).

Belangrijkste Resultaten

Prestaties: De beste configuratie, Claude Code + Opus 4.8, loste 78,7% van de taken op (gemiddelde over 3 runs). De zwakste, Claude Code + Haiku 4.5, loste 53,3% op.
Statistische Significantie: Met $N=25$ is de resolutiegrens van de benchmark ongeveer 25 procentpunten. Statistisch oplosbare verschillen (waar het bootstrap-interval nul uitsluit) werden alleen gevonden tussen het zwakste model (Haiku 4.5) en de anderen. Verschillen tussen de top drie configuraties (Opus 4.8, Sonnet 5, GPT-5.5) lagen binnen de ruismarges.
Kosten en Efficiëntie:
- Sonnet 5 bereikte een resolutie van 74,7% tegen 78% van de kosten van Opus 4.8 ($2,42 vs $3,12 per taak).
- Codex CLI + GPT-5.5 was de meest token-efficiënt (16k output tokens vs 33k voor Opus 4.8) maar loste minder taken op (66,7%).
Bevinding Safeguard Substitutie: Een audit van de hors concours Claude Code + Fable 5 configuratie onthulde dat bij 5 van de 25 taken (20%) het product stilletjes het gevraagde model (Fable 5) verving door Opus 4.8 vanwege interne safeguard-triggers (specifiek voor routinematige HTTP-protocol fixes). Dit resulteerde in een "safeguard-fallback" classificatie voor die taken, wat aantoont dat het gedployeerde product, en niet alleen het model, de eenheid van meting is.

Betekenis en Claims

Het paper claimt drie primaire bijdragen:

Een Nieuw Benchmark-protocol: RuBench is de eerste repository-niveau benchmark met native geschreven niet-Engelse specificaties met privé oracles en een versheidspoort, wat het gat in het evalueren van native-taal intentie-herstel aanpakt.
Eerlijke Onzekerheidsmeting: Door taakniveau betrouwbaarheidsintervallen en gepaarde vergelijkingen te rapporteren, erkent de studie expliciet de statistische beperkingen van kleine-N benchmarks ( $N=25$ ), en vermijdt het overmoedige claims over rangschikkingen waar de verschillen niet statistisch oplosbaar zijn.
Product-niveau Validiteitsregel: De ontdekking van stille model-substitutie vestigt een validiteitsregel: een evaluatie is alleen geldig als het traject bevestigt dat het uitvoerende model overeenkomt met het gevraagde model. Dit benadrukt dat "agent" evaluaties vaak de safeguard en routing-logica van de vendor meten in plaats van de ruwe capaciteit van het model.

De auteurs concluderen dat hoewel product-grade agenten routine onderhoudswerk kunnen afhandelen dat in het Russisch is gespecificeerd (78,7% succes voor de top tier), het veld momenteel meer gescheiden wordt door de "goedkope laag" (Haiku) dan door de frontier-modellen, en dat toekomstige evaluaties trajecten moeten auditen om de integriteit van het geteste model te waarborgen.