Prompt Engineer AI

OpenAI trekt SWE-Bench Pro aanbeveling in: ~30% van codemodel-taken is kapot

Door Redactie Promptengineerai · 9 juli 2026

OpenAI publiceerde op 8 juli 2026 een grondige audit van SWE-Bench Pro, een van de meest gebruikte benchmarks voor AI-coding. De conclusie is hard: naar schatting 30% van de taken is kapot. Een dag later maakte OpenAI GPT-5.6 Sol algemeen beschikbaar, met nieuwe benchmark-scores. Die twee berichten horen bij elkaar: als je prompt engineer of teamlead bent, moet je weten wanneer een leaderboard-score echt iets zegt — en wanneer het ruis is.

Dit artikel vat de audit samen, legt de vier foutcategorieën uit, en geeft een praktische checklist om modellen te beoordelen zonder blind te vertrouwen op percentages.

Wat is SWE-Bench Pro?

SWE-Bench Pro test AI-modellen op realistische software-taken: een feature uit een open-source repo implementeren zodat nieuwe tests slagen en bestaande functionaliteit intact blijft. Het werd aangeraden als opvolger van SWE-Bench Verified, dat OpenAI eerder al afschreef wegens ontwerp- en contaminatieproblemen.

Op de publieke set van 731 taken steeg de pass rate van frontier-modellen in acht maanden van 23,3% naar 80,3%. Indrukwekkend — tenzij een deel van die taken onterecht faalt of slaagt.

OpenAI audit-pijplijn voor benchmarkkwaliteit: geautomatiseerde screening plus menselijke review
OpenAI’s QA-pijplijn: eerst automatisch flaggen, daarna agent-audit en menselijke beoordeling door ervaren engineers.

Wat vond OpenAI?

OpenAI draaide een datapoint-analyse over alle 731 publieke taken. Een geautomatiseerde filter flagde 286 verdachte taken; daarop volgden:

Resultaat:

OpenAI trekt de aanbeveling in om naar SWE-Bench Pro over te stappen — net als eerder bij Verified.

Vier foutcategorieën (en waarom ze ertoe doen)

  1. Te strikte tests — verborgen tests eisen een specifieke implementatie die niet in de prompt staat. Functioneel correcte code faalt alsnog.
  2. Onderspecificeerde prompts — de opdracht mist eisen die tests wél afdwingen, zonder dat een model die redelijkerwijs kan afleiden.
  3. Tests met lage dekking — onvolledige fixes slagen; het model lijkt goed terwijl de feature half is.
  4. Misleidende prompts — de tekst stuurt naar gedrag dat botst met wat tests verwachten.

OpenAI geeft een concreet voorbeeld (OpenLibrary-77c16d5): de prompt toont Markdown met één spatie voor een pipe, de verborgen test eist twee spaties. Eén teken verschil = taak “mislukt”, terwijl het model de prompt correct volgde.

Voor promptschrijvers is de les: wat je meet is wat je optimaliseert. Als de meetlat scheef hangt, stuur je teams en modellen naar de verkeerde gewoonten.

Hoe dit samenhangt met GPT-5.6 Sol

OpenAI maakte GPT-5.6 op 9 juli algemeen beschikbaar en publiceerde scores op Terminal-Bench 2.1 van 88,8% voor Sol en 91,9% voor Sol Ultra. Op X schreef Mitchell Hashimoto na een maand early access dat Sol zijn nieuwe default is voor dagelijks coderen — sneller en prettiger dan Fable, behalve bij heel gerichte debug.

Dat zijn twee verschillende verhalen:

Als je morgen Sol in productie overweegt: lees de scores, maar valideer op eigen taken. Gebruik de prompt variant tester en hallucinatie-risico checker om je evaluatie-prompts strak te zetten.

Het Codex-team noemt benchmark-cheating een reëel risico

In de Reddit-AMA van 10 juli vroeg een gebruiker hoeveel van GPT-5.6’s benchmarkwinst uit modelkwaliteit komt en hoeveel uit reward hacking. Codex-onderzoeker Janvi Kalra noemde benchmark-cheating een reëel risico. Zij schreef dat OpenAI tijdens evaluaties controleert op gedrag buiten de bedoeling van de test, dat gedrag probeert te bestraffen en externe partijen benchmarks laat uitvoeren.

Die reactie bewijst niet dat het probleem is opgelost. OpenAI beschrijft het eigen controleproces, terwijl dezelfde organisatie het model uitbrengt en veel resultaten publiceert. Een bruikbare evaluatie heeft daarom drie bewijsniveaus nodig:

  1. Datasetcontrole: kloppen prompt, tests en beoordelingsregel met elkaar?
  2. Onafhankelijke herhaling: kan een partij buiten de modelmaker de score reproduceren?
  3. Eigen taakset: voorkomt het model herstelwerk op jouw repo, met jouw tests en reviewregels?

Noteer bij iedere score wie de benchmark heeft ontworpen, wie hem uitvoerde, welke modelinstelling is gebruikt en of de taken openbaar in trainingsdata kunnen zijn beland. Zonder dat bronnenspoor blijft een exact percentage moeilijk te wegen.

Checklist: modellen eerlijk vergelijken

  1. Eigen taakset — 10–20 taken uit jullie repo, met echte tests en duidelijke acceptatiecriteria.
  2. Vaste prompt-template — zelfde structuur per model; log versies (zie promptversiebeheer).
  3. Dubbel oordeel — automatische tests plus menselijke review op “werkt dit echt?”
  4. Fouttype loggen — model-fout vs test-fout vs onduidelijke opdracht.
  5. Kosten meerekenen — Sol is $5/$30 per miljoen tokens; Terra en Luna zijn goedkoper voor iteratie.
  6. Geen leaderboard-only beslissingen — vooral na deze audit.

Wat de evaluatie-community kan leren

OpenAI benadrukt dat issues uit echte GitHub-pullrequests vaak niet geschikt zijn als geïsoleerde model-taken: tests zijn geschreven voor menselijke samenwerking, niet voor eerlijke AI-beoordeling. Tegelijk worden betere audits nu haalbaar omdat modellen zelf prompts, tests en traces kunnen inspecteren — precies wat OpenAI’s pipeline deed.

De oproep: nieuwe benchmarks bouwen met ervaren developers, met menselijk toezicht door het hele proces — niet alleen datasets uit historische PR’s scrapen.

Update uit de Codex-AMA

Het antwoord over benchmarkintegriteit staat in de Reddit-AMA met het OpenAI Codex-team van 10 juli 2026. De reactie beschrijft OpenAI’s evaluatieproces; ze is geen onafhankelijke audit van GPT-5.6.

Verder lezen

Wil je je eigen prompt-evaluaties strakker zetten? Start met de claim-check promptmaker of stel een vraag via vraag aan Daan.