SWE-bench Verified og måling af AI-kodning

SWE-bench Verified er et kendt mål for, hvor godt AI-modeller løser softwarefejl, men OpenAI vurderer nu, at benchmarken er blevet for forurenet og upræcis til frontier-sammenligninger. Det gør testkvalitet, træningsdata og menneskelig kontrol vigtigere end endnu en ny topscore.

Hvad er den nye kritik af SWE-bench Verified?

Den centrale nyhed er, at OpenAI den 8. juli 2026 meldte ud, at virksomheden ikke længere vil bruge SWE-bench Verified som sit foretrukne mål for frontier-kodningskapacitet. Ifølge OpenAI afspejler fremgang på benchmarken ikke længere nødvendigvis bedre evner til softwareudvikling i praksis.

Kritikken går i to retninger. For det første afviser en del tests løsninger, som funktionelt kan være rigtige. For det andet er benchmarken så kendt og så tæt knyttet til åbne kodebaser, at modeller kan have set problemer, patches eller centrale detaljer i træningen.

Hvad er SWE-bench, Verified og Pro?

SWE-bench er en familie af benchmarks til at måle, om sprogmodeller og agentiske systemer kan løse rigtige softwareproblemer ud fra GitHub-issues og eksisterende kode. Det gør benchmarken relevant for agentiske AI-systemer, der skal læse et problem, ændre kode og bestå tests uden løbende menneskelig styring.

Pointen er derfor ikke, at al benchmarkmåling er værdiløs. Pointen er, at et benchmark kan blive så populært, at det mister noget af sin værdi som uafhængigt mål.

Hvorfor siger OpenAI, at benchmarken ikke længere måler reelle fremskridt?

OpenAI skriver, at virksomheden auditerede en del af de problemer, modeller ofte fejlede på, og fandt to hovedproblemer: dårlige tests og kontaminering. Når begge dele er til stede, bliver det uklart, om en høj score skyldes reel softwareforståelse eller bare et heldigt match med et kendt datasæt.

OpenAI fremhæver også, at fremgangen på SWE-bench Verified er fladet ud. Hvis de tilbageværende fejl i høj grad skyldes datasættets egen konstruktion, bliver benchmarken mindre egnet til at skelne mellem små, men vigtige forbedringer i nye modeller.

Hvilke fejltyper fandt OpenAI i testene?

OpenAI beskriver især to fejlmønstre. Nogle tests er for smalle og afviser løsninger, fordi de forventer en bestemt implementering frem for en korrekt funktion. Andre tests er for brede og kræver sideeffekter eller relaterede ændringer, som ikke står tydeligt i selve opgaven.

I OpenAI’s audit af 138 problemer, som o3 ikke løste stabilt over 64 uafhængige kørsler, blev hver sag gennemgået af mindst seks erfarne softwareingeniører. Virksomheden skriver, at mindst 59,4 procent af de gennemgåede problemer havde fejlbehæftede tests, som kunne afvise funktionelt korrekte svar.

• En model kan løse det beskrevne problem, men stadig dumpe, fordi testen kræver en bestemt kodeform.
• En model kan mangle skjulte antagelser i issue-teksten, selv om en menneskelig udvikler ville afklare dem undervejs.
• Miljøforskelle og svagt dækkede tests kan gøre resultatet mere følsomt over for benchmarkopsætningen end over for selve modelkvaliteten.

Hvad betyder træningskontaminering i denne sammenhæng?

Træningskontaminering betyder her, at en model kan have set dele af opgaven eller løsningen, før den bliver evalueret. Det er et særligt problem for benchmarks, der bygger på offentlige issues, commits, release-noter og kode fra populære open source-projekter.

OpenAI skriver, at alle de frontier-modeller, virksomheden testede, kunne genskabe enten den menneskeskrevne patch eller meget specifikke problemformuleringer i nogle tilfælde. Hvis en model allerede kender opgaven, siger en høj score mindre om dens generelle evne til at analysere ny kode.

Det er også derfor, at feltet bevæger sig mod flere private eller nyforfattede opgaver. Når et benchmark er offentligt og bredt diskuteret, bliver det sværere at bevise, at en model virkelig generaliserer til nye fejl.

Hvad viser forskningen om lignende problemer?

OpenAI står ikke alene med kritikken. En tidligere forskningsanalyse af SWE-bench+ pegede på både solution leakage og svage tests som væsentlige problemer i den oprindelige benchmarkfamilie. Analysen fandt blandt andet, at 32,67 procent af de succesfulde patches bar præg af lækage, og at 31,08 procent så mistænkelige ud på grund af utilstrækkelige tests.

Forskerne viste samtidig, at løsningsraten for SWE-Agent plus GPT-4 faldt fra 12,47 procent til 3,97 procent, når problematiske opgaver blev filtreret ud. Det betyder ikke, at alle moderne kodningsbenchmarks er upålidelige, men det understreger, at tredjeparts-evalueringer af AI-modeller kun er nyttige, hvis datasæt og scoringslogik også tåler kritisk eftersyn.

Hvad kan benchmarken stadig bruges til?

SWE-bench Verified bliver ikke automatisk værdiløs af denne kritik. Benchmarken kan stadig bruges som historisk reference, som fælles testmiljø og som input til intern regressionstest, hvis du ved, hvad den faktisk måler og ikke måler.

Problemet opstår, når en enkelt score bliver behandlet som et endeligt svar på, hvilken model der er bedst til softwareudvikling. I praksis bør benchmarken læses sammen med omkostninger, fejltyper, menneskelig review, værktøjsbrug og kvaliteten af de opgaver, modellen møder uden for benchmarken.

Det er samme grund til, at teams ofte vurderer kodningsassistenter som GitHub Copilot på egne repositories og arbejdsgange i stedet for kun på leverandørens mest favorable testresultater.

Hvad betyder det i praksis for udviklere og organisationer?

Nyheden ændrer mest for dem, der køber, sammenligner eller styrer AI-værktøjer til softwarearbejde. Hvis en leverandør fremhæver en høj benchmarkscore, bør du spørge, hvilken benchmark der er brugt, hvor frisk den er, om modellen kan have set opgaverne før, og hvordan resultaterne er kontrolleret.

• Brug flere typer evaluering: standardbenchmarks, egne kodeopgaver og manuel review.
• Se på fejlmønstre, ikke kun på én samlet procentscore.
• Test på repositories, hvor krav, dependencies og testmiljø ligner dit eget.

For softwareteams betyder det også, at intern måling bliver vigtigere. En model, der scorer højt på en offentlig benchmark, kan stadig være svag til dit frameworks build-system, dine sikkerhedskrav eller den måde dine issues bliver skrevet på.

Hvilke lokale forhold kan få betydning?

For organisationer i Danmark er pointen mindre, hvilken amerikansk benchmark der vinder, og mere hvordan AI-værktøjer bliver dokumenteret og kontrolleret, før de får adgang til kode, tickets og interne repositorier. Hvis et værktøj bruges i væsentlige arbejdsgange, kan krav om risikovurdering, styring og dokumentation under EU AI Act få praktisk betydning, afhængigt af anvendelsen.

Derudover kan softwareprojekter indeholde både forretningshemmeligheder og personoplysninger i issues, commits eller testdata. Derfor er spørgsmålet om GDPR og AI-træningsdata ikke kun relevant for modeltræning, men også for de datakilder en kodningsassistent får adgang til under evaluering og drift.

På uddannelsesinstitutioner og offentlige arbejdspladser kan nyheden også læses som en påmindelse om, at benchmarkresultater ikke bør stå alene, når nye værktøjer vælges til undervisning, udvikling eller indkøb.

Hvordan adskiller dette sig fra almindelige modeltoplister?

Mange modeltoplister viser et rangnummer, en samlet score og måske en pris. Denne nyhed handler derimod om selve linealen. Hvis linealen er skæv, bliver forskellen mellem første- og andenplads mindre troværdig, uanset hvor præcis ranglisten ser ud.

Det gør benchmarkkritik mere grundlæggende end en almindelig produktnyhed. Når feltet diskuterer testdesign, kontaminering og bedømmelse, handler det om, hvordan hele AI-branchen dokumenterer fremskridt over for kunder, forskere og myndigheder.

Hvad sker der sandsynligvis nu?

OpenAI skriver, at virksomheden i de seneste måneder er gået over til at rapportere resultater fra den offentlige del af SWE-bench Pro og samtidig investerer i nye, privat forfattede benchmarks. Det peger mod et marked, hvor leverandører i stigende grad må kombinere offentlige benchmarks med mere kontrollerede interne evalueringer.

Du kan derfor forvente flere diskussioner om benchmarkhygiejne, flere forsøg på privat eller semiprivat testdata og større vægt på menneskelig bedømmelse. For læsere, der følger AI-kodning tæt, er nyheden vigtig, fordi den flytter fokus fra modelreklame til kvaliteten af den dokumentation, modellerne bliver solgt på.

Hvilke kilder ligger til grund?

Artiklen bygger på OpenAI’s egen gennemgang af SWE-bench Verified, den officielle oversigt over SWE-bench-familien og leaderboardet samt forskningsartiklen SWE-Bench+: Enhanced Coding Benchmark for LLMs, som dokumenterer tidligere problemer med lækage og svage tests.