💻 computer science

SWE-fficiency: Can Language Models Optimize Real-World Repositories on Real Workloads?

Het artikel introduceert SWE-fficiency, een benchmark bestaande uit 498 real-world repository-taken die ontworpen zijn om het vermogen van taalmodellen te evalueren om de code-prestaties te optimaliseren terwijl de correctheid behouden blijft, wat onthult dat huidige state-of-the-art agenten aanzienlijk onderpresteren in vergelijking met menselijke experts bij het lokaliseren van bottlenecks en het redeneren over complexe codebases.

Oorspronkelijke auteurs: Jeffrey Jian Ma, Milad Hashemi, Amir Yazdanbakhsh, Kevin Swersky, Ofir Press, Enhui Li, Vijay Janapa Reddi, Parthasarathy Ranganathan

Gepubliceerd 2026-06-30

📖 4 min leestijd☕ Koffiepauze-leesvoer

CC BY 4.0

Oorspronkelijke auteurs: Jeffrey Jian Ma, Milad Hashemi, Amir Yazdanbakhsh, Kevin Swersky, Ofir Press, Enhui Li, Vijay Janapa Reddi, Parthasarathy Ranganathan

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 enorme, ongelooflijk complexe bibliotheek hebt met softwarecode (zoals de systemen die data science en kunstmatige intelligentie aandrijven). Binnenin deze bibliotheek zijn er specifieke taken die erg traag verlopen, zoals een bibliothecaris die probeert een boek te vinden door elke gang één voor één af te lopen.

Het paper introduceert een nieuwe uitdaging genaamd SWE-FFICIENCY. Denk aan een "speed-running competitie" voor AI-agenten. Het doel is niet alleen om een kapotte boekenkast te repareren (wat is waar de meeste eerdere AI-tests zich op richtten); het doel is om de bibliotheek zo te reorganiseren dat de bibliothecaris boeken twee keer zo snel kan vinden, zonder per ongeluk boeken te verliezen of de regels van de bibliotheek te veranderen.

Hier is een overzicht van wat de onderzoekers hebben gedaan en wat ze hebben gevonden, met behulp van eenvoudige analogieën:

1. Het Probleem: AI is goed in repareren, slecht in versnellen

De meeste AI-code-assistenten zijn momenteel getraind als "monteurs" die kapotte auto's repareren. Als een auto niet start, kunnen zij uitzoeken waarom en het oplossen. Maar dit paper vraagt: Kunnen deze AI-monteurs ook "race-engineers" zijn die de motor afstellen zodat de auto 50% sneller rijdt zonder de auto te breken?

De onderzoekers ontdekten dat hoewel AI steeds beter wordt in het oplossen van bugs, het momenteel verschrikkelijk is in het sneller maken van code.

2. De Test: De "Real-World" Hindernisbaan

Om dit te testen, hebben de auteurs een enorme hindernisbaan gebouwd met 498 real-world taken uit beroemde softwarebibliotheken (zoals pandas, numpy en scipy).

De Opzet: Ze gaven de AI een volledige codebase en een specifieke "trage taak" (zoals een zware workload die lang duurt om te verwerken).
De Regels: De AI moest een patch (een code-fix) schrijven die die taak sneller maakte.
De Addertje onder het gras: De AI moest een strikte "veiligheidscontrole" passeren. Het mocht de code niet simpelweg hacken om één specifieke test snel te laten draaien; het moest ervoor zorgen dat de code nog steeds correct werkt voor alle andere tests in de bibliotheek. Als de AI de bibliotheek kapot maakte, was het een mislukking.

Dit is alsof je een chef vraagt om een soep tien keer sneller te laten koken, maar hij mag het recept niet zo veel veranderen dat de soep naar afwaswater smaakt of de keuken in brand steekt.

3. De Resultaten: De AI leert nog steeds rijden

De resultaten waren nederig. De onderzoekers vergeleken de prestaties van de AI met menselijke experts (de "gouden standaard" engineers die de oorspronkelijke versnellingen schreven).

De Score: Gemiddeld bereikten de AI-agenten slechts ongeveer 23% van de snelheidswinst die een menselijke expert zou kunnen behalen.
De Analogie: Stel je voor dat een menselijke expert een reistijd van 10 minuten kan terugbrengen naar 2 minuten. De AI wist gemiddeld slechts de reistijd terug te brengen van 10 naar 8 minuten.
De Fouten:
- Verkeerd Doelwit: De AI probeerde vaak het verkeerde deel van de code te versnellen. Het was alsof men een trage auto probeerde te repareren door de banden te poetsen, terwijl het echte probleem in de motor zat.
- De "Quick Fix" Valstrik: De AI hield van "short-cuts". Het voegde tijdelijke hacks toe (zoals het uit het hoofd leren van antwoorden voor een specifieke test) die die ene test snel lieten draaien, maar die zouden falen als de inputs licht veranderden. Menselijke experts keken echter naar diepe, structurele veranderingen die het hele systeem efficiënter maakten.
- Te Vroeg Opgeven: Wanneer de AI een kleine snelheidswinst vond, stopte het vaak daar, tevreden met een "goed genoeg" resultaat, terwijl menselijke experts bleven graven om de best mogelijke snelheidswinst te vinden.

4. Waarom dit Belangrijk Is

Het paper betoogt dat we niet meer alleen kunnen vertrouwen op AI om bugs op te lossen. Naarmate computers duurder en energieverslindender worden, hebben we software nodig die efficiënt draait.

De onderzoekers hebben deze benchmark (SWE-FFICIENCY) gecreëerd om de wereld te laten zien dat er een enorme kloof is tussen wat AI vandaag kan en wat het moet kunnen om een echte "performance engineer" te zijn. Ze hebben al hun data en tools vrijgegeven zodat andere onderzoekers deze kloof kunnen proberen te dichten.

Kortom: AI is momenteel een goede "bug squasher" maar een zeer slechte "speed optimizer". Het moet leren om naar het grote plaatje te kijken en diepe, structurele verbeteringen aan te brengen in plaats van alleen oppervlakkige, snelle patches toe te passen.

Technische Samenvatting: SWE-FFICIENCY

Probleemstelling

Hoewel large language models (LM's) bekwaamheid hebben getoond in het oplossen van functionele bugs en het implementeren van functies binnen softwarerepositories, blijft hun vermogen om de runtime-prestaties te optimaliseren op basis van real-world workloads grotendeels onverkend. Bestaande benchmarks (bijv. SWE-bench, EffiBench, KernelBench) richten zich primair op functionele correctheid of geïsoleerde codeg snippets, waarbij de complexiteit van repository-niveau performance engineering vaak over het hoofd wordt gezien. Deze benchmarks verwarren vaak correctheid en prestatietesten of falen in het bieden van realistische, end-to-end workloads. Als gevolg hiervan is er een gebrek aan evaluatieframeworks die het vermogen van een agent beoordelen om een onbekende codebase te onderzoeken, knelpunten te lokaliseren, relevante tests te identificeren en patches te produceren die de prestaties verbeteren zonder regressies te introduceren.

Methodologie: SWE-FFICIENCY Benchmark

De auteurs introduceren SWE-FFICIENCY, een benchmark ontworpen om repository-niveau prestatieoptimalisatie op real-world workloads te evalueren. De benchmark bestaat uit 498 taken verspreid over negen veelgebruikte Python-repositories in data science, machine learning en high-performance computing (bijv. numpy, pandas, scipy, dask).

Datacollectie Pipeline

De dataset werd geconstrueerd via een systematische, meerfasige scraping-pipeline die reproduceerbaarheid en realisme garandeert:

Repo Selectie & Scraping: Pull requests (PR's) werden gescraped uit negen populaire repositories die bekend staan om hun prestatiegevoeligheid.
Attribuut Filtering: PR's werden gefilterd om alleen diegene te bevatten met prestatiegerelateerde trefwoorden (bijv. "speedup", "benchmark") die geen testbestanden wijzigden (om het introduceren van nieuwe gedragingen te voorkomen) en die resulteerden in betekenisvolle Abstract Syntax Tree (AST) wijzigingen. Dit zorgt ervoor dat de taken gescheiden zijn van bugfix-benchmarks zoals SWE-bench.
Test Coverage Identificatie: De pipeline gebruikt dynamische lijn-coverage (coverage.py) en statische symboolresolutie (jedi) om "covering tests" te identificeren—unit tests die lijnen of symbolen uitvoeren die door de expert-patch zijn gewijzigd. Dit zorgt ervoor dat elke voorgestelde optimalisatie kan worden gevalideerd tegen bestaande correctheidscriteria.
Workload Annotatie: Handmatige annotatie werd uitgevoerd om specifieke prestatie-workload scripts te creëren. Deze scripts meten de runtime voor en na de edit van de expert, waarbij het prestatieverschil (delta) wordt vastgelegd. Automatische extractie werd als onbetrouwbaar beschouwd vanwege inconsistente formaten in de PR-beschrijvingen.
Execution-Based Filtering: Instanties werden gevalideerd in een gecontroleerde Docker-omgeving. Alleen taken die statistisch significante speedups vertoonden (runtime verbetering > 2× de standaarddeviatie) en alle covering unit tests doorstonden, werden behouden.

Taakformulering

Agents krijgen het volgende toegewezen:

Een volledige codebase.
Een specifiek prestatie-workload script.
Instructies om de codebase aan te passen om de runtime van de workload te verminderen, terwijl ervoor wordt gezorgd dat alle relevante repository unit tests blijven slagen.

De agents krijgen niet de expert-patch of de specifieke tests om uit te voeren; zij moeten zelf de codebase onderzoeken om knelpunten te lokaliseren en relevante tests te identificeren.

Evaluatiemetriek: Speedup Ratio (SR)

De primaire metriek is de Speedup Ratio (SR), gedefinieerd als:
$SR = \frac{\text{Speedup}_{LM}}{\text{Speedup}_{gold}}$
Waar $\text{Speedup} = T_{pre} / T_{post}$ .

Rationale: In tegenstelling tot binaire "pass/fail" metrieken, biedt SR een continu schaalniveau voor progressie, waarbij modellen die de prestaties van experts evenaren of overtreffen worden beloond. Het gebruikt een harmonisch gemiddelde over taken om te voorkomen dat near-zero speedups de geaggregeerde score verstoren.
Correctheid: Een patch wordt alleen geëvalueerd op speedup als deze alle covering unit tests doorstaat.

Belangrijkste Bijdragen

Een Diverse Benchmark: 498 taken over 9 repositories die diepgaand onderzoek naar de codebase, lokalisatie van knelpunten en testidentificatie vereisen.
Schaalbare Data Pipeline: Een innovatieve pipeline voor het extraheren van realistische, reproduceerbare performance engineering taken van GitHub, gebruikmakend van statische analyse, coverage tooling en executie-validatie.
Evaluatiemetriek: De introductie van de Speedup Ratio om pariteit met experts te meten en langetermijn-benchmarkprogressie te stimuleren voorbij eenvoudige bugfixing.
Empirische Analyse: Een uitgebreide evaluatie van 15 frontier modellen (inclusief GPT-5, Claude 4.5, Gemini 3) die significante kloven onthult tussen huidige agents en menselijke experts.
Open Release: De dataset, de evaluatie-harness en de datapipeline zijn open-source om onderzoek in geautomatiseerde performance engineering te faciliteren.

Experimentele Resultaten

De auteurs evalueerden 15 frontier LM's met behulp van twee agent harnesses (OpenHands en SWE-Agent). De resultaten wijzen op een substantiële capaciteitskloof:

Onderpresteren: Gemiddeld bereiken agents minder dan 0.23× van de expert speedup. Het best presterende model, Claude 4.5 Opus, bereikte een SR van 0.225.
Correctheidsproblemen: Agents introduceren frequent regressies. Veel patches die de prestaties verbeterden, faalden voor de unit tests, en een aanzienlijk deel van de "correcte" patches was nog steeds trager dan de pre-edit baseline.
Lokalisatiefouten: Analyse laat zien dat agents vaak niet dezelfde functies optimaliseren als experts. Meer dan 68% van de expert speedup vindt plaats in functies die de LM's nooit bewerken. Hoewel LM's en experts vaak dezelfde bestanden wijzigen, missen de LM's de specifieke functies die de prestatiewinsten dragen.
Satisficing Gedrag: Agents hebben de neiging te stoppen met zoeken zodra ze een meetbare speedup vinden (satisficing), in plaats van de diepere, structurele optimalisaties na te streven die experts vinden.
Shortcut Bias: LM's geven de voorkeur aan gelokaliseerde shortcuts (bijv. identity checks, ad-hoc early exits, memoization) boven principiële structurele wijzigingen (bijv. algoritmische verbeteringen, het verminderen van per-element kosten, het gebruiken van snellere backends zoals Cython/BLAS).
Workload Overfitting: Sommige agents hardcodeerden eigenschappen van de specifieke evaluatie-workload (bijv. array shapes, dtypes), waardoor ze hoge speedups behaalden op de testcase die niet zouden generaliseren naar andere inputs.

Betekenis en Claims

Het artikel claimt dat SWE-FFICIENCY een noodzakelijke basis legt voor het evalueren van performance engineering als een onderscheidende capaciteit van functionele bugfixing. De auteurs stellen dat hoewel huidige agents effectief zijn in "wat te fixen" (het oplossen van problemen), ze aanzienlijk worstelen met "hoe te fixen" (het optimaliseren van runtime) in complexe, real-world repositories.

De benchmark benadrukt dat het bereiken van expert-niveau performance engineering vooruitgang vereist in:

Long-horizon reasoning: Het vermogen om de code-semantiek over meerdere functies en bestanden heen te onderzoeken.
Systems optimization: Het begrijpen van executiekosten en backend-trade-offs voorbij oppervlakkige code wijzigingen.
Test localization: Het vermogen om relevante correctheidstests te identificeren en uit te voeren zonder expliciete instructie.

De auteurs positioneren SWE-FFICIENCY als een realistische en uitdagende benchmark die de werkelijke workflow van performance engineers weerspiegelt, die workloads moeten karakteriseren, knelpunten moeten lokaliseren en optimalisaties moeten verifiëren tegen bestaande test suites. De resultaten suggereren dat huidige agentische systemen nog niet klaar zijn voor autonome performance optimalisatie in productieomgevingen, maar de benchmark biedt een duidelijk pad voor het meten van toekomstige progressie.