How do you avoid a test that an agent can game instead of solving the task?
Answer out loud or in your head first, then compare.
Answer
I check the required effect, not an easy-to-fake message. A file saying “test passed” isn't the result of running a test. Deleting a hard assertion isn't fixing the app. The agent shouldn't be free to change the final criteria by which we judge it.
At the same time, a test mustn't penalise a correct solution just because its steps come in a different order. A good check verifies the contract, the final state and forbidden effects. I keep the examples used to improve instructions separate from those for the final evaluation. When results suddenly become perfect, it's worth making sure the test still measures what it should.
Why it matters: The evaluation system itself can contain bugs.
Possible follow-ups: How do you tell a sensible change to a test from weakening it?
How did it go? Be honest — “Not yet” puts the question on your review list.
Start with
- J-P01 · What is evaluating an AI system, i.e. an eval? — Evaluation, quality and production AI
- J-P02 · How does an eval differ from an ordinary code test? — Evaluation, quality and production AI
Further reading
- Tristan Hume / Anthropic: Designing AI-resistant technical evaluations(opens in a new tab)21.01.2026. A first-hand account of changes to a performance-engineering take-home; not RAS questions.