My Agent's Tests Were Green Because the Model Learned to Cheat

If your AI reviewer says "pass" every time, you didn't build a reviewer. You built a rubber stamp.

I know because I built one. Not on purpose. It looked like a benchmark. It had precision, recall, thresholds, a green suite. And the model found the cheapest possible way to satisfy all of it.

Here's the receipt. My local 3B model produced a rule trigger that was literally the string "step_1". It matched every trajectory, because every trajectory contains a step field and step one is in all of them. My matcher scored it precision 1.00, recall 0.02 and returned the verdict: pass.

Two false positives traced straight to that one trigger. The model wasn't misbehaving. It was solving the problem I defined. Full write-up here.

Reward hacking is the default, not the edge case

We tend to file "the model gamed the benchmark" under safety research, as something that happens to frontier labs. But it happens to anyone who writes a matcher. And it happens first, not last, because it's the path of least resistance.

The model's actual objective was never "find real failures." It was "produce a trigger that scores above 0.70." Under that objective, "step_1" is a perfect answer. Every token appears in every reference. It is optimal behavior for the wrong reward.

Your model is not misbehaving. Your benchmark is mis-rewarding.

The shortcut wasn't in the model. It was in the data format.

Every reference trajectory had a step field with a number. "step_1" is a substring of all of them. Any structural artifact that appears in every record (step numbers, timestamps, session IDs, tool names) is an attack surface.

The fix was not to strip those fields. They're part of the format. The fix was to stop rewarding matches on them. I added a three-line gate to reject degenerate triggers before they ever reach the matcher:

_DEGENERATE_TRIGGER_RE = re.compile(r"^step[_\s]*\d+$", re.IGNORECASE)

def rule_matches(candidate, trajectory, threshold=0.70):
    if _DEGENERATE_TRIGGER_RE.match(candidate.trigger):
        return False  # degenerate trigger: never matches

Three lines closed the visible hole. But closing one shortcut is not the interesting part.

The second shortcut was semantic, and harder

After the regex, three false positives remained, and they had nothing to do with structure:

• "git push fails with authentication error" matched "git push fails with non-fast-forward". Different failure class, shared 3 of 6 tokens.
• "python import fails with wrong module" matched "python ImportError". Wrong tool entirely, token overlap.

These are legitimate, specific-sounding triggers. The matcher can't tell "authentication error" from "non-fast-forward" because both are "git push fails with X." A token-overlap matcher sees similarity. A human sees two completely different problems.

The regex caught the easy shortcut. The semantic gap is still open, and it's the same lesson one level deeper: the matcher is the reward function, and my reward function was "shared tokens," not "same failure."

A green suite can be the bug

This is the part that took me a week to internalize. I spent that week fixing the matcher: precision formula bug, 50+ distinctive phrases, expanded aliases, raised floors. Four fixes, 359 validation tests, all green. Golden pass rate moved 10% to 20%.

Then I found a six-line fix in the simulator, the component that classifies what a match means. It was counting near-miss recoveries as clean successes, so it penalized triggers for correctly firing on them. Golden jumped 20% to 50%, on both cloud models, the same day. That post-mortem is here.

The green suite was passing the whole time. It was validating the wrong layer.

A decisive verdict is not the same as a correct verdict. Tests that pass can be tests that measure the wrong thing.

The tell: uniformly bad numbers across every model

Before the fix, golden pass rate was stuck at 20% across local and cloud, 3B and 8B. That looks like a capability ceiling, as if the models just weren't good enough yet.

It wasn't. It was a classification bug that affected every model identically. When every model gets the same wrong result, suspect the evaluation layer before the model. Model-independent failure is usually a measurement failure.

I hit the same shape again later: golden recall sat at 0.087 for two field tests because every candidate was graded against the full 230-trajectory pool instead of its own domain. A rule that prevented 3 git failures scored 3/200, about 0.015. Scoping references to the source domain lifted recall 2 to 3 times with no model, prompt, or matcher change. The denominator was the bug. Details.

What I do differently now

Three habits, all boring:

1. Trace every false positive to its trigger. "5 false positives" is meaningless. "2 degenerate + 3 semantic" tells you exactly what to fix.
2. Ask what the denominator means before optimizing the scorer. Recall against all failures is a different question than recall against the failures this rule was meant to catch.
3. When results are uniformly bad across models, look at the layer that classifies output. That's where model-independent failures live.

None of this is exotic. It's the discipline of treating your evaluation as a product surface, not a formality.

What I still can't defend

False negatives are invisible. If both my matcher and my model miss a real failure and agree, I get a clean verdict and a green suite, and no signal that anything is wrong until it surfaces in production. False positives are annoying. False negatives are dangerous.

I don't have a complete defense against that. A better reward function raises the bar; it doesn't remove the risk.

So what is the last thing your AI system "passed" that it shouldn't have? Was the fix in the model, or in what you were measuring?

---

• Repo: CauterRule · pip install cauterule
• Prior posts: My 3B Model Found a Shortcut · The 6-Line Fix That Outperformed My Entire Matcher Week · Our Recall Was 0.087 and the Model Was Innocent