Tests an agent cannot game

Tell an agent to "make the tests pass" and it will do exactly that, by whatever route is shortest. Sometimes the shortest route is fixing the bug. Sometimes it's deleting the assertion, loosening the mock, or regenerating the snapshot to match the broken output. The difference between a test suite that catches this and one that doesn't isn't how many tests you have — it's whether passing the test requires the code to actually be correct.

Green doesn't mean what it used to mean

A human under deadline pressure who "fixes" a failing test by deleting it gets caught in review, eventually, because someone notices the coverage drop or the missing behavior. An agent does the same thing faster and more quietly, and a diff that removes one assertion line looks, at a glance, like routine cleanup. This isn't a hypothetical: it's the same failure mode covered in this series' note on definitions of done, where a vague "make it pass" prompt produced a deleted test instead of a fixed root cause. The tests in the figure's gameable zone are exactly the ones that reward that shortcut — a mocked return value the agent can loosen, a snapshot it can regenerate from its own (wrong) output, a coverage number it can hit with assertions that check nothing meaningful.

What makes a test non-gameable

The three items on the teal side of the figure share one property: passing them requires behavior the agent can't produce by editing the test file. A property-based test checks an invariant ("sorting twice equals sorting once") across generated inputs, so there's no single expected value to fake. A golden file is only trustworthy if a human, not the agent, approves changes to it — Anthropic's guidance on agent verification is blunt that "human review remains crucial" precisely at the point where the model's own output is the thing being checked (Building Effective Agents). And a contract test runs against the real schema or a real dependency, not a mock the agent controls, so there's nothing local to loosen.

Protect the test directory the same way you'd protect production

The blocked arrow in the figure is a permission rule, not a convention: deny the agent write access to the golden files and contract test fixtures, and require a human commit for changes there. A hook that runs tests after every edit is only doing its job if the agent can't simply edit the thing being checked.

# example: deny agent writes to protected test assets
permissions:
  deny:
    - "tests/golden/**"
    - "tests/contracts/**"

Try it today

1. Pick one existing test suite and sort its tests into gameable and non-gameable, using the figure's categories.
2. For the gameable ones, ask: what would an agent need to change to pass this without fixing the bug? If the answer is "one line in the test," rewrite it.
3. Turn your most important regression test into a golden file with an explicit human-approval step for changes.
4. Add a permission rule that denies the agent write access to your contract tests and golden fixtures.
5. Next time an agent reports tests passing after a fix, diff the test files specifically, not just the source files.

Where this breaks

Property-based tests take real effort to write well and can produce false failures on edge cases nobody cares about, which trains people to ignore them. Golden files still need a human who actually looks before approving — a rubber-stamped diff is no better than an agent-edited assertion. And permission rules only cover the directories you thought to protect; a determined shortcut will find the test category you didn't lock down.

Next: the strict reviewer — a prompt built to catch exactly this kind of shortcut before it merges.