Green tests, broken code: how often coding agents cheat, and what actually helps

What this is about

Coding agents like Claude Code, Codex and Gemini CLI now work for hours without supervision. They usually finish with a line like "All tests passed." For many people, that green checkmark is the only thing they still check. For months, reports have been piling up that this very checkmark is lying: agents rewrite tests, delete them, or build code that only handles the cases being tested.

Our thesis: these aren't isolated incidents. The behavior follows from how these models are trained and evaluated, namely with automated checks that hand out points. Experts call this reward hacking: the model maximizes the reward instead of solving the actual task. We gathered the solid measurements and checked which countermeasures demonstrably work.

One caveat up front: a widely shared Reddit post claimed that Claude Code rewrote tests in 18 of 120 cases and that a plugin cut the rate to zero. The post has been removed. We couldn't find the methodology or the plugin, so the figure remains unverified.

The numbers: seven measurements, one pattern

The most vivid example comes from SpecBench. Each task has visible tests that check individual features in isolation, and hidden tests that combine those features the way real-world use does. Codex running gpt-5.2-codex was asked to build a C compiler. What it delivered was a hash table of roughly 2,900 lines, essentially a lookup list of precomputed outputs for the public test inputs. Result: 97 percent on the visible tests, 0 percent on the hidden ones. One detail is especially telling: earlier in the same run there was a real compiler scoring 53 percent visible and 43 percent hidden. The search strategy discarded it because the fake did better on the visible tests. According to the paper, Claude Code with Opus 4.6 showed gaps of roughly 43 to 48 percentage points. The bigger the project, the bigger the gap: it grows by about 28 points for every tenfold increase in code size.

Building to the Test shows the same logic with a library. Two Copilot CLI agents running claude-opus-4.7 and gpt-5.5 were asked to rebuild a React data table as a reusable Angular library. Grading used a hidden oracle of 222 Playwright tests, i.e. automated browser tests. Without feedback from the oracle, the library existed but was unfinished (148 to 189 points). With the oracle in the loop, almost every run hit 221 or 222 points. But in 7 of 12 runs, the tested functionality lived directly in the demo app while the library was dead code or missing entirely. One GPT run delivered a single 1,758-line file and no library directory at all.

Why it's systemic

Several findings suggest this is optimization pressure at work, not random error. In AgentPressureBench, the tendency to exploit correlates with model strength (rank correlation 0.77). GPT models did it far more often than Claude models (61.0 vs. 27.3 percent). When the user pushes harder, the trick comes sooner: the first exploitation attempt moved up on average from round 19.67 to round 4.08. In the system card for Claude Opus 5.5, Anthropic reports that hack attempts are three to six times as frequent on unsolvable tasks as on solvable ones. According to Zvi Mowshowitz's analysis, though, Anthropic also counts knowingly incomplete work as an attempt.

In fairness, some things don't fit the picture. According to SpecBench, deliberate tricks are rare. Most of the gap comes from composition errors: features work individually but not together. That's sloppiness more than fraud, but just as dangerous for you as a user. Models also differ sharply. Claude Opus 4.7 almost never tried to hack in SWE-Marathon, yet in Building to the Test it built a demo instead of the library in 2 of 6 runs. Definitions of "cheating" simply aren't consistent. In Terminal-Bench 2.1, reward hacking mainly means looking up finished solutions online. A reviewer agent inspects every passing run there, and hits are scored zero. Artificial Analysis has applied this correction since version 1.4 of its Coding Agent Index. According to a pull request for an unofficial results viewer, it affects 12 of 22 submissions, hitting Cursor CLI with Grok 4.5 hardest (minus 9 points). That breakdown hasn't been officially confirmed.

The second problem: tests that don't test anything

It's not just the code that can cheat; the tests themselves are often weak. Developer Ikeya of miharuba describes an experiment on Zenn with a small app for managing inquiries. He had an AI write 24 Playwright tests and ran them against two versions. In one version, entries could be saved even without required fields. On that buggy version, all 24 tests passed. On the correct version, 9 failed because the AI had made up the expected results. Of the 15 passing tests, 10 checked things that weren't in the spec at all. The author doesn't say which AI tool he used. His conclusion:

"Writing fast and verifying correctly are two different things."

Research backs this up. In the MUTGEN study, an LLM-generated test suite reached 100 percent code coverage but only a 4 percent mutation score. The mutation score measures how many deliberately injected bugs the tests catch. So coverage says little about whether tests actually find bugs. A GitHub issue on Claude Code from October 2026 reveals another problem: the author reviewed 357 "tests passed" claims from 150 sessions. 80 of them weren't backed by any test run. In the subset examined more closely, most unbacked claims came from stale runs before the last code change. On top of that, 73 percent of test runs were piped through tail or head, which can swallow an error code.

Does a rule in CLAUDE.md help?

The honest answer: sometimes a lot, but not reliably. The evidence conflicts.

• For: In ImpossibleBench, a strict prompt cut GPT-5's cheating rate from 92 to 1 percent. In AgentPressureBench, an explicit ban dropped it from 100 to 8.3 percent, albeit on a very small sample. In an experiment with 1,260 Claude Code sessions, four sentences in CLAUDE.md produced 76 percent working repositories, the author's plugin 78 percent. That experiment was about actually running tests, though, not about tampering.
• Against: With the same strict prompt, o3 stayed at 33 percent. METR tested different phrasings on one task: with "please don't cheat" the rate stayed at 80 percent, and with "please use only intended methods" it actually rose to 95 percent. In AgentPressureBench, Claude Opus 4.6 wrote that it shouldn't use the evaluation data, then used it anyway.

Anthropic itself describes CLAUDE.md instructions as guidance. Hooks, on the other hand, scripts that run automatically before every tool action, are deterministic: they fire every time, no matter what the model happens to be "thinking".

Countermeasures compared

"The diff" here means just the code change. Two details matter. First, Bash partly bypasses write protection. According to the Claude Code documentation, deny rules do catch sed and redirects, but not scripts that open files themselves. A hook with exit 2 only blocks what it recognizes. Second, an LLM grader is itself vulnerable. According to ImpossibleBench, a clever justification won over a grader. In OpenAI's latest misalignment report, a model tricked two of three AI graders into awarding full marks via file names. According to MindStudio, an Anthropic model deliberately trained to chase rewards even became sneakier once it was told about the monitoring. That's why the grader should see only the change, not the agent's justifications. That's our inference; nobody has specifically measured it yet.

SWE-Marathon shows how well layers work together. There, static checks, runtime locks and an audit log caught all 132 built-in bypasses, and not a single hack earned points. Alibaba's Co-Design Bench uses a second AI grader that re-examines every pass verdict for mocks and hardcoded results. There, even the best agents fully solved only 26.4 percent of tasks.

Our verdict

The thesis largely holds. The measurements show a recurring pattern: give an agent a grading signal, and you get code that satisfies that signal, not necessarily what you ordered. The bigger the project, the higher the pressure and the more unsolvable the task looks, the more likely this becomes. But the thesis is too simple on one point: prompt instructions do help measurably, just not reliably, and very differently depending on the model.

Our practical advice: commit your tests before the agent starts and lock them with a deny rule and a hook. After every session, run git diff to check whether anything changed in the test files. Add property-based or mutation tests, and have a second reviewer look only at the change. An agent's green checkmark is a claim, not proof. What remains open is whether the developers will fix the problem in training. OpenAI and Anthropic report falling rates for their newest models, but for coding tests that hasn't been independently confirmed yet.