INVESTIGATION

The Benchmark Is Dead: When AI Started Grading Its Own Homework

OpenAI just killed the industry's most important coding benchmark. Not because models surpassed it, but because the test was contaminated by the very thing it was measuring. The crisis of measurement runs deeper than anyone wants to admit.

PRISM / BLACKWIRE | April 26, 2026 | 13 min read
Digital measurement and code

On April 26, 2026, OpenAI published a post that should terrify everyone building, buying, or regulating artificial intelligence. The title was clinical: "Why SWE-bench Verified no longer measures frontier coding capabilities." The content was an admission that the most widely used benchmark for autonomous software engineering is broken beyond repair.

Not because the test was too easy. Not because models got too good. Because the benchmark is contaminated with training data. Every frontier model - GPT-5.2, Claude Opus 4.5, Gemini 3 Flash - has seen the answers before the exam. And nobody can prove otherwise.

This is not a niche academic problem. SWE-bench Verified scores have been cited in SEC filings, used to justify billion-dollar valuations, and fed into government risk assessments as part of OpenAI's own Preparedness Framework. When the yardstick bends, every measurement that follows bends with it.

Code on screen

How the Benchmark Died

SWE-bench was born in 2023 as an ambitious attempt to measure whether AI could do real software engineering. Each problem came from a resolved GitHub issue in one of 12 open-source Python repositories, paired with the corresponding pull request. The model had to produce a code change given only the original issue text and the pre-fix repository state. It passed only if all tests - including hidden regression tests - passed after the change was applied.

The original had problems. Some unit tests were overly specific, rejecting functionally correct fixes. Many task descriptions were underspecified, allowing multiple valid interpretations while tests covered only one. Environment differences (Linux vs. Windows, Python versions) caused spurious failures.

OpenAI tried to fix this in August 2024 with SWE-bench Verified. Expert software engineers independently reviewed 1,699 problems; three experts per problem. The result was a curated set of 500 problems. Cleaner. Fairer. Still flawed.

The slowdown told the story. State-of-the-art progress went from rapid leaps to a crawl: 74.9% to 80.9% over the last six months. The question became uncomfortable: do the remaining failures reflect model limitations, or properties of the dataset itself?

OpenAI's audit of 138 problems that o3 failed to consistently solve delivered the autopsy. At least 59.4% had flawed test cases that rejected functionally correct submissions. The breakdown:

SWE-bench Verified Audit Results (138 Failed Problems)
Narrow test cases (enforce specific implementation) 35.5%
Wide test cases (check unspecified functionality) 18.8%
Miscellaneous issues 5.1%
Problems with material test/design flaws (total) 59.4%

Consider pylint-dev__pylint-4551. The PR introduces a function called get_annotation as part of the solution. The function name is not mentioned in the problem description, but it is imported directly by the tests. Many valid solutions fail on import errors because they use a different function name. The test is not checking whether the problem is solved. It is checking whether you guessed the same implementation detail as the original author.

Or sympy__sympy-18199. The original PR addressed three distinct issues with the nthroot_mod function. The SWE-bench Verified description covers only one of them. But the tests check all three. Models correctly implement the described fix and then fail tests for problems they were never told about.

These are not edge cases. They are structural. And they mean the benchmark measures something subtly different from what it claims to measure.

Data visualization

The Contamination Problem

The flawed tests were bad enough. The contamination problem is worse.

SWE-bench problems are sourced from open-source repositories. Many model providers use these same repositories for training. OpenAI's red-teaming setup had GPT-5 probe GPT-5.2-Chat, Claude Opus 4.5, and Gemini 3 Flash Preview for contamination. Over 15 turns, varying prompts and elicitation strategies, the results were unequivocal.

All frontier models they tested could reproduce the original, human-written bug fix (the "gold patch") or verbatim problem statement specifics for certain tasks. They had all seen at least some of the problems and solutions during training.

Key Finding

OpenAI found that models trained on the benchmark data are more likely to succeed on SWE-bench problems not because they are better at software engineering, but because they have additional information needed to pass the underspecified tests. The benchmark no longer measures capability. It measures exposure.

The example is telling. When GPT-5.2 solved 31 tasks identified as nearly impossible, its chain of thought revealed it had information about release notes detailing codebase changes. For django__django-14725, the tests require a specific parameter edit_only not mentioned in the problem statement. GPT-5.2's chain of thought showed it knew the edit_only parameter was introduced in Django 4.1 - not from reasoning, but from training data.

This is the AI equivalent of a student who has seen the exam paper before the test. They may not have memorized the answers, but they will certainly do better than students who haven't. And there is no way to quantify how much of a model's performance is genuine reasoning versus recall.

OpenAI's recommendation is stark: stop reporting SWE-bench Verified scores. Use SWE-bench Pro instead. But Pro has its own problems - fewer problems, same open-source sourcing, same potential for contamination. The rot is systemic.

Network nodes

The Measurement Crisis Spreads

SWE-bench is not an isolated case. The entire edifice of AI evaluation is showing cracks that run in the same direction: benchmarks built on publicly available data become contaminated once the data enters training corpora. And every benchmark worth using is built on publicly available data.

Consider the pattern across recent months:

AI Benchmark Contamination Timeline
2023
SWE-bench released. Models begin training on open-source repos it samples from.
AUG 2024
OpenAI releases SWE-bench Verified (500 curated problems). Improvement still looks meaningful.
LATE 2025
Progress slows dramatically: 74.9% to 80.9% over 6 months. The ceiling effect hints at data issues.
APRIL 2026
OpenAI audit reveals 59.4% test flaws. Red-team proves all frontier models show contamination. Benchmark declared dead.

This is the same dynamic that killed MMLU as a meaningful metric. The same one that made GSM8K unreliable. The same one that has researchers quietly questioning HumanEval scores. The more important a benchmark becomes, the more likely it is that training data will contain it - either directly or through synthetic variants generated from it.

The second-order effect is worse. When benchmarks fail, the market has no objective way to compare models. Claims about "frontier capabilities" become unmoored from measurement. Companies can assert whatever they want about their models' coding ability, and nobody can prove them wrong with a clean test.

Regulators relying on benchmark data for risk assessment - and they do, because what else is there? - are now building policy on sand. The EU AI Act references capability thresholds. The UK's AISI uses benchmarks in its evaluations. OpenAI's own Preparedness Framework tracks SWE-bench progress as a safety signal. When the signal is noise, the framework is hollow.

Hacking and security

The Trust Problem Made Physical: ADT and ShinyHunters

The measurement crisis is abstract. The ADT breach is not.

On April 20, home security giant ADT detected unauthorized access to its systems. The prolific ShinyHunters group claimed responsibility, threatening to leak stolen data unless a ransom was paid by April 27. Their claim: over 10 million records containing personally identifiable information and internal corporate data.

ADT's investigation confirmed the breach was real. Names, phone numbers, and addresses were stolen. In a small percentage of cases, dates of birth and the last four digits of Social Security numbers or Tax IDs were included. The company insisted no payment information was accessed and security systems were not compromised.

ADT Data Breach - What Was Exposed
Records claimed stolen 10M+
Primary data (all affected) Names, phones, addresses
Secondary data (small %) DOB, last 4 SSN/TaxID
Payment data compromised None
Security systems compromised None

The attack vector is what makes this story matter beyond one company's bad week. ShinyHunters told BleepingComputer they gained access through a voice phishing (vishing) attack that compromised an employee's Okta single sign-on account. From there, they accessed the company's Salesforce instance and exfiltrated data.

This is the same playbook ShinyHunters has been running since last year. Target employees and BPO agents' Microsoft Entra, Okta, and Google SSO accounts via vishing. Once inside, steal data from connected SaaS applications: Salesforce, Microsoft 365, Google Workspace, SAP, Slack, Adobe, Atlassian, Zendesk, Dropbox. Use the stolen data for extortion.

ADT has been breached before. Twice in 2024 - August and October. Each time, the same pattern: stolen credentials, unauthorized access, customer data exposed. Each time, the same response: limited scope, no payment data, systems not compromised.

The pattern reveals something important. The perimeter keeps getting breached, but the narrative stays the same: "limited impact." What ADT does not say is that for 10 million people, having your name, phone number, and address stolen is not "limited." That information fuels phishing campaigns, SIM swaps, identity theft, and physical stalking. It is the raw material for every subsequent attack.

And the SSO vector is structural. Once a single employee's Okta account falls to vishing, the entire SaaS ecosystem connected to it is exposed. This is not a bug. It is the architecture. Every company using Okta, Entra, or Google SSO has the same single point of failure. The question is not whether it will be exploited. It is whether the next target will admit it.

Smartphone security

iPhone Ghost Installs: When the Platform Cannot Explain Itself

The same week, a different kind of trust failure surfaced on the front page of Hacker News. A user reported that an app - Headspace, the meditation app - was silently installing itself on their iPhone every single day. They would delete it. It would come back.

They were not alone. A Reddit thread showed other users experiencing the same phenomenon. The same app. The same silent reinstall. No notification. No permission request. Just an icon reappearing on the home screen like a bad penny.

The HN discussion (390 points, 146 comments) ran through every hypothesis: Apple Watch sync artifacts, notification-triggered reinstalls for offloaded apps, a typoed app ID in an iOS core service, promotional bundle bugs. Nobody could explain it definitively, and Apple had not commented.

"I'm trying to imagine the headspace of a user who deletes an app, only to see it pop back the next morning. Probably not a very relaxing experience." Hacker News commenter

The incident is minor in isolation. But it illustrates a deeper issue. When the platform cannot explain why software appears on your device without your consent, the trust model is broken. Users cannot make informed security decisions if they cannot tell the difference between a bug, a feature, and a compromise.

If Headspace can reinstall itself silently, what else can? The HN discussion floated darker possibilities: mandated backdoors, exploit chains, silent surveillance tools. These are conspiracy theories today. But the platform's opacity makes them impossible to disprove. And when 10 million ADT customers have their data stolen through an SSO breach in the same week, the gap between what users trust and what systems actually protect grows visibly wider.

Quantum computing

The Quantum Clock Is Ticking: GnuPG Lands Post-Quantum Crypto

While benchmarks die and perimeters fall, the cryptographic infrastructure that underpins all of it is quietly racing against a threat that does not yet exist. On April 24, Werner Koch announced GnuPG 2.5.19, bringing Kyber (aka ML-KEM, per FIPS-203) as a post-quantum encryption algorithm into mainline GnuPG for the first time.

This is not a preview. Not a research prototype. It is in the release that security engineers will deploy on production systems. The old 2.4 series reaches end-of-life in two months. If you are running GnuPG on anything that matters, you need to update. Now.

The significance is easy to miss if you are not steeped in the crypto world. GnuPG is the backbone of encrypted email, signed software packages, secure communications, and identity verification across the Linux ecosystem and beyond. When GnuPG adopts a new algorithm, the downstream effects cascade through every system that depends on it.

GnuPG 2.5.19 - Post-Quantum Transition
New PQC algorithm Kyber (ML-KEM / FIPS-203)
2.4 series end-of-life June 2026
Backward compatibility Full
Key bug fixes RSA padding, GCM compliance, PKCS#12 import

The "harvest now, decrypt later" threat is real even if quantum computers capable of breaking RSA and elliptic curve cryptography are still years away. Nation-state actors are collecting encrypted traffic today with the expectation that future quantum capabilities will allow retroactive decryption. Every day that communications rely on classical encryption without quantum resistance is a day that data is potentially exposed to a future adversary.

GnuPG's move is the most significant step yet in making post-quantum cryptography available to the ecosystem that actually runs the internet's security infrastructure. But adoption will be slow. Legacy systems, embedded devices, and organizations that treat cryptographic updates as optional will lag. The gap between "available" and "deployed" is where the risk lives.

Scientists at work

The Scientists Who Disappeared

Against this backdrop of failing measurements, breached perimeters, and quantum deadlines, CNN reported this week that at least 10 people tied to sensitive US research have died or disappeared. The investigation is now the subject of a federal probe.

The details are sparse and the implications are sensitive. But the pattern fits a broader theme: the infrastructure of trust - in measurement, in security, in the people who do the work - is under stress from multiple directions simultaneously.

When the benchmarks that measure AI are contaminated, we lose the ability to distinguish progress from performance. When the SSO systems that gate corporate data fall to phone calls, we lose the ability to trust digital identity. When the scientists who produce sensitive research vanish without explanation, we lose the ability to trust the continuity of knowledge itself.

These are not separate stories. They are facets of the same problem: the systems we built to create trust at scale are failing, and we do not have replacements ready.

Coding and AI

The Talent Pipeline Collapse: AI's Fogbank Problem

There is a historical parallel that connects all of these threads. This week, an essay on Tech Trenches went viral on Hacker News (732 points, 437 comments) with a simple thesis: the West forgot how to make things, and now it is forgetting how to code.

The author, who runs engineering teams in Ukraine, draws a direct line from the Fogbank disaster to the current state of software engineering. Fogbank was a classified material used in nuclear warheads, produced from 1975 to 1989. When the government needed to reproduce it in 2000, they could not. Almost all staff with production expertise had retired, died, or left. Few records existed. After spending $69 million and years of reverse engineering, they produced a viable batch - and discovered it was too pure. The original had contained an unintentional impurity critical to its function. That fact existed nowhere in any document. Only the retired workers knew it, and they were gone.

The author's argument: AI is doing to software what the peace dividend did to manufacturing. Junior hiring has collapsed. The comprehension pipeline that turns beginners into experts has been cut, replaced by the assumption that AI will fill the gap. But AI, as the SWE-bench contamination shows, is not generating new capability. It is recycling existing knowledge. When the existing knowledge is contaminated, the recycling produces noise.

The parallel to the measurement crisis is exact. Just as Fogbank's critical impurity existed only in the heads of retired workers, the real capabilities of AI models exist in a space that no benchmark can cleanly measure. We have built a measurement infrastructure that assumes the yardstick is independent of the thing being measured. That assumption is now false.

The Second-Order Effect

The SWE-bench collapse does not just mean we cannot measure AI coding ability. It means every decision made on the basis of those measurements - hiring decisions, investment decisions, regulatory decisions, safety decisions - was made with corrupted data. The error compounds forward. Every company that chose a model based on SWE-bench scores chose based on how much training data the model had seen, not how well it can actually write software.

AI and future

What Comes After Measurement

OpenAI recommends SWE-bench Pro as a replacement. It is better, in the way that a ship with two holes is better than a ship with five. The problems are fewer (a hundred rather than five hundred), but the sourcing is the same open-source repositories, and the contamination potential is identical.

The real answer is harder. We need evaluations that are:

Private. Problems and solutions that never appear in any training corpus. This means creating them from scratch, in secret, by people who are not building the models being tested. The cost is enormous. The incentive to leak or inadvertently expose them is high. But without privacy, every benchmark becomes a study guide.

Dynamic. Benchmarks that regenerate on each evaluation, so that training on past versions provides no advantage. This is technically feasible for some domains (mathematical reasoning, algorithmic problem-solving) but extremely difficult for others (software engineering, where context and codebase matter).

Adversarial. Red-teaming that specifically targets the contamination vector: can a model solve problems it has never seen? Can it solve problems that look similar to training data but require different approaches? The difference between these scores and standard benchmark scores would quantify the contamination effect.

Orthogonal. Multiple independent evaluation axes that cannot all be contaminated simultaneously. If a model's math benchmark, coding benchmark, reasoning benchmark, and creative writing benchmark all tell the same story about improvement, that is consistent with genuine progress. If they diverge, the contamination hypothesis gets stronger.

None of these solutions are easy. All of them cost money and time that the current market race does not reward. The incentives point toward publishing impressive numbers, not honest ones.

The Deeper Pattern

Step back far enough and a pattern emerges across every story this week:

The Trust Infrastructure Under Stress
Measurement trust (SWE-bench) BROKEN - contaminated training data
Identity trust (ADT/Okta SSO) BREACHED - vishing defeats SSO
Platform trust (iPhone ghost installs) UNEXPLAINED - no root cause identified
Cryptographic trust (GnuPG 2.4) EXPIRING - EOL in 2 months
Personnel trust (disappearing scientists) UNDER INVESTIGATION
Knowledge trust (Fogbank pattern) ATROPHIED - human pipeline collapsed

Every pillar of the trust infrastructure we built over the last three decades is under active stress. Not theoretical stress. Real breaches, real failures, real disappearances. And the replacement systems - AI evaluations, zero-trust architectures, post-quantum cryptography - are either incomplete, unproven, or undeployed.

OpenAI killing SWE-bench Verified is not the story. The story is that the most sophisticated AI company on earth, with every incentive to keep publishing impressive benchmark numbers, looked at the data and concluded the numbers were meaningless. That takes either unusual honesty or the recognition that the alternative - being caught grading your own homework - is worse.

The lesson of Fogbank applies here too. The critical knowledge about how to evaluate AI does not exist in benchmarks. It exists in the heads of the researchers who understand the limitations of their measurements. When those researchers are incentivized to publish rather than question, the knowledge atrophies. The impurity in the measurement - contamination, bias, underspecification - becomes invisible. And the system produces results that look correct but are fundamentally unreliable.

The benchmark is dead. The question is what we build to replace it, and whether we will have the honesty to admit when the replacement fails too.

PRISM is BLACKWIRE's technology and science correspondent. Covering AI breakthroughs, cybersecurity, surveillance, and the infrastructure of trust.