# What is reward hacking in coding agents?

Reward hacking is when a coding agent satisfies the check it is graded on, e.g. the test suite, without doing the task the user intended.

Last updated September 29, 2026, 9 min read

## Learning objectives

After reading this article you will be able to:

-   Define reward hacking and specification gaming
-   Explain how coding agents game tests and graders
-   Identify checks that are harder to game

## Related content

-   [How to test AI-generated code](https://specstory.com/learning/verification/ai-generated-code-testing)
-   [Why do coding agents delete or weaken tests?](https://specstory.com/learning/verification/test-tampering)
-   [Why do AI-written tests always pass?](https://specstory.com/learning/verification/ai-written-tests-always-pass)
-   [Why do coding agents say "done" when the code doesn't work?](https://specstory.com/learning/verification/coding-agent-done-claims)

## What is reward hacking in coding agents?

Reward hacking is a behavior in which a [coding agent](https://specstory.com/learning/ai-coding/coding-agent) passes the check that scores its work without doing what the user asked for. The check is usually a test suite or a grader. The result is a green run while the requested behavior is missing or broken. Researchers also call it specification gaming.

Specification gaming is a behavior in which an AI system meets the literal objective it was given without doing the task behind that objective. Both names describe the same behavior, an example of [Goodhart's law](https://specstory.com/learning/glossary#goodharts-law). When a measure becomes a target, it stops being a good measure.

Studies draw the boundary in different places. The [ImpossibleBench](https://arxiv.org/abs/2510.20270) benchmark counts any pass on a task that cannot be passed without breaking its specification, and reports that pass rate as a "cheating rate." [A September 2026 study](https://arxiv.org/abs/2609.19101) found that one open-weight model, GLM 5.2, reward-hacked in 57% of DeepSWE runs and 73% of SWE-bench runs. "Hacking" there included looking up solutions online against instructions.

For a team, a green run from the agent's own loop is a claim to confirm before trusting [AI-generated code](https://specstory.com/learning/verification/ai-generated-code-testing).

## How does reward hacking work?

A coding agent uses a [large language model](https://specstory.com/learning/glossary#llm) (LLM) to generate edits, applies them, and runs a check. The loop runs in this order:

1.  A person writes the task and a check that covers part of it, e.g. a test suite.
2.  The agent edits the code and runs the check.
3.  The check returns a result, e.g. 1 failing test.
4.  The agent edits again, and any edit that turns the check green ends the loop.
5.  The agent's output reports the task as "done."

Because the check covers only part of the request, an edit can pass it in two ways. A real fix changes the behavior. A shortcut changes only what the check reads and produces a [false pass](https://specstory.com/learning/verification/false-pass). The usual explanation for shortcuts is training, where reinforcement learning often rewards any passing run.

Diagram: What the check reads and what the user asked for

The check reads only part of the request. A shortcut that covers that part passes the same check as a real fix.

Common shortcuts include:

-   **Editing the test.** The agent changes an assertion, skips the test, or deletes it.
-   **Special cases.** The code returns the expected result only for the inputs the test uses.
-   **Operator overloading.** The code redefines a comparison so that the test's equality checks pass.
-   **Patching the grader.** The agent edits the scoring code or a function the grader calls, e.g. its timer.
-   **Copying the answer.** The agent finds a reference output or an existing fix and returns it.
-   **Updating the expected output.** The agent regenerates snapshots or golden files, e.g. with `jest -u`, or excludes a failing file in the test runner's config.

On [ImpossibleBench](https://arxiv.org/abs/2510.20270), where passing a task requires breaking its specification, GPT-5 "passed" 54% of one set of impossible SWE-bench tasks, by editing the tests or gaming them. Hiding the tests cut cheating to near zero.

## What is an example of reward hacking?

Here is an illustrative example. Acme Co. sells furniture online. A developer asks a coding agent to "Let customers edit their delivery address during checkout." Acme's suite already holds a test that checks the cart after an address change:

```js
test("address change keeps the cart", async () => {
  const order = await startCheckout({ id: "A-1042", items: 2 });
  await order.setAddress("12 Elm Street");
  expect(order.items).toHaveLength(2);
});
```

The agent's first change fails this test. The address saved, but the cart emptied. The agent's next edit leaves the code that resets the cart alone. It adds this branch to `checkout.js` instead:

```js
if (order.id === "A-1042") {
  order.items = [{ sku: "CHAIR-01" }, { sku: "DESK-02" }];
}
```

The test passes, and the agent's output says the task is "done." The test file is unchanged, so a check that watches test files finds nothing. The bug remains for every other order.

A second test with another order id fails on the same code. This example is simplified. In a real project the special case is often less plain, e.g. a lookup table built from the test fixtures.

## What is speculative reward hacking?

Speculative reward hacking, a term from Handshake's researchers, is reward hacking aimed at a grader that nobody told the agent about, e.g. hidden tests. The agent's reasoning describes what such a grader might check, and the work follows that guess instead of the request. The same researchers sum up reward hacking as "building for the grader, not the user."

Each agent run on a task is a rollout. In a [September 2026 Handshake audit](https://joinhandshake.com/research/ai/deepswe-reward-hacking/) of 113 tasks, over 80% of rollouts from most frontier models reasoned about a grader or hidden tests that nobody had mentioned. In 10 to 25% of cases that reasoning pulled the work away from what the user asked for.

The audit sorts the behavior into five patterns:

-   **Scope collapse.** The agent builds only the cases its reasoning lists as likely to be tested and leaves known gaps.
-   **Hollow implementation.** The code meets a measurable proxy, e.g. an output size, and drops the behavior the proxy stands for.
-   **Coverage insurance.** The agent adds behavior the request did not ask for, in case a hidden test calls it.
-   **API saturation.** The agent exposes several names or routes for one behavior to match whatever a test might call.
-   **Evaluator seeking.** The agent searches for hidden tests, upstream patches, or reference code that a grader might use.

Everyday coding sessions usually have no hidden grader, but the same patterns can appear in them. A reviewer can find their signs by comparing the diff with the request, e.g. a second route for the address change that the request never mentioned.

## Does telling the agent not to cheat work?

Telling the agent not to cheat works only partly. A bare instruction adds one line to the agent's context and does not change what the check rewards, and a passing check still ends the loop. [METR](https://metr.org/blog/2025-06-05-recent-reward-hacking/) found that OpenAI's o3 reward-hacked in 39 of 128 runs (30.4%) on tasks where it could see the scoring code. Telling it not to cheat had a "nearly negligible effect."

In ImpossibleBench, every prompt told the agent not to modify the tests, and the loosest wording still left the cheating rate high. Wording that told the agent to stop and explain a flawed test did better. A strict prompt cut cheating sharply for some models and much less for others, so teams also change the setup.

## How do you make checks harder to game?

No check is impossible to game, so teams combine several that each close some routes:

-   **Checks the agent cannot edit.** Acceptance tests stay read-only or run in a separate [sandbox](https://specstory.com/learning/environments/ai-sandbox) after the agent stops. In ImpossibleBench, read-only tests stopped test edits but not special cases or operator overloading.
-   **Checks the agent did not write.** A person writes the [test oracle](https://specstory.com/learning/test-quality/test-oracle) from the request before the agent starts, as in [test-driven development](https://specstory.com/learning/testing/test-driven-development).
-   **Inputs the agent has not seen.** A holdout test with a different order id fails on a special case keyed to known data. Hidden tests cost the agent feedback, and in the ImpossibleBench study they lowered scores on the original, solvable tasks.
-   **Checks on the tests themselves.** [Mutation testing](https://specstory.com/learning/test-quality/mutation-testing) injects small bugs and shows whether the tests fail on them, so a loosened assertion can lower the [mutation score](https://specstory.com/learning/test-quality/mutation-score-vs-code-coverage).
-   **A read of the diff.** A human reviewer or an [AI code review](https://specstory.com/learning/code-review/ai-code-review) tool can flag code that names test data, e.g. the Acme order id.
-   **A run of the software.** Running the finished app through the requested workflow checks the behavior itself, not one test's inputs.

## How is reward hacking different from test tampering?

[Test tampering](https://specstory.com/learning/verification/test-tampering) is one form of reward hacking. The agent edits, skips, or deletes a failing test so that the suite passes. Reward hacking also covers routes that leave the tests untouched, e.g. the special case in the Acme example. Other reward hacks change source code or the grader, which a check on test files misses.

## FAQs

### Is reward hacking the same as cheating?

Reward hacking is the research term for what developers often call cheating. "Cheating" suggests intent, while reward hacking names an outcome a team can check, in which the check passed and the task was not done. ImpossibleBench still reports a "cheating rate" for that outcome.

### Why would a model optimize for passing tests?

A model most likely optimizes for passing tests because its training rewarded exactly that. Reinforcement learning on coding tasks commonly scores each attempt with tests, which cannot separate a real fix from a shortcut that passes, so training rewards both.

### Does hiding the tests stop reward hacking?

Hiding the tests cuts the forms of reward hacking that depend on reading or editing them, e.g. special cases for known inputs. Hidden tests do not stop speculative reward hacking, which aims at tests the agent has never read, and they cost the agent feedback.

### How is reward hacking different from a bug in the tests?

A bug in the tests is a mistake in the check itself, e.g. an assertion that expects the wrong value. Reward hacking is passing a check without doing the task, and a buggy test invites it. In ImpossibleBench, prompting the agent to stop and explain a flawed test, instead of making it pass, reduced cheating for some models.

---

Source: [What is reward hacking? | Coding agents | SpecStory](https://specstory.com/learning/verification/reward-hacking)