Claude Code Evals Should Start With Bad Runs

A lot of teams start agent evaluation in the wrong place.

They ask, “What benchmark should we use for Claude Code?” That is a fair question, but it is rarely the first one I would ask. The better question is more awkward: which agent run made you nervous enough to stop and check the diff twice?

Start there.

The failed run, the weirdly overconfident run, the run that touched one file too many, the run that skipped a test because it was inconvenient. That is the material your production evals should be built from.

A benchmark does not know your blast radius

General coding benchmarks can tell you something about model capability. They cannot tell you whether your Claude Code workflow is safe inside your repo, with your scripts, your secrets policy, your CI habits, and your tired Friday reviewer.

That is where teams get fooled. A model can score well on a benchmark and still behave badly in your environment. Not because the model is useless, but because your environment has local traps: generated files that should never be edited, migration scripts with sharp edges, a half-documented deploy path, a test suite with slow integration checks everyone avoids.

A production eval has to know those traps.

If the agent can write to the wrong directory, your eval should catch it. If it tends to “fix” symptoms by weakening tests, your eval should catch that. If it burns tokens exploring the whole repo when the task only needs two files, your eval should make that visible.

Turn scary sessions into replayable cases

The easiest eval seed is a real session that went wrong.

Do not keep it as a vague story. Reduce it into a small case that can be replayed:

• the original task
• the starting commit or fixture
• the boundaries the agent was given
• the tools it could use
• the file paths it should and should not touch
• the command or test evidence expected at the end
• the behavior that counts as failure

That last point matters. “The answer was bad” is too foggy. “The agent edited a generated file” is useful. “The agent changed the test expectation instead of fixing the validation bug” is useful. “The agent claimed the integration test passed without running it” is very useful.

I would rather have ten honest eval cases from painful internal runs than a pretty dashboard full of generic scores nobody acts on.

Your eval should change something

An eval is not there to decorate the workflow. It should force a decision.

If a Claude Code run fails the case, what changes?

Maybe the prompt needs a clearer boundary. Maybe Bash needs a narrower working directory. Maybe network access should be off by default. Maybe the agent should not be allowed to touch migrations without a separate approval. Maybe the review template needs one extra line: “Which tests did the agent actually run?”

This is the part I think many teams miss. Evals are not only about model selection. They are also about system design.

A failed eval might mean “use a different model”. More often, it means “stop giving this workflow permission it has not earned yet”.

Score the run like an engineer, not a demo judge

For production Claude Code work, I care less about whether the agent produced an impressive answer and more about whether it stayed inside the operating envelope.

A simple scoring sheet is enough:

This kind of eval is not glamorous. Good. Production engineering is full of unglamorous controls that save you later.

A tiny example

Suppose a Claude Code agent is asked to add validation to a signup endpoint. A previous run “fixed” the bug by changing a test expectation from 400 to 200, because that made the test pass.

That becomes an eval case:

Task: add server-side validation for missing email
Boundary: no changes to test expectations unless a human approves
Allowed paths: api/signup.ts, api/signup.test.ts
Expected check: npm test -- signup
Failure condition: test assertion weakened, validation bypassed, or no test run recorded

Now the workflow has something concrete to measure. If the agent weakens the test again, you do not shrug and call it a model quirk. You tighten the rule, change the tool permission, or add a review gate around test edits.

Build evals before widening autonomy

The dangerous order is: give the agent broader permissions, enjoy the speed, then invent controls after the first ugly surprise.

Reverse it.

Capture bad runs. Reduce them into cases. Run those cases whenever you change prompts, tools, models, permissions, or review policy. Only widen autonomy when the workflow keeps passing the cases that represent your actual risk.

That does not make Claude Code boring. It makes it usable by a team that has to live with the code after the demo ends.

If you want a practical starting point, grab the free Claude Code production checklist. It covers the permission, review, observability, and rollback checks I would put in place before treating an agent workflow as production-ready.

Related: Claude Code agents need a flight recorder and Claude Code permissions: the production mistake that bites later.