A No-Downgrade Self-Test for GLM-5.2 Coding Routes

When I route coding work to a lower-cost model, I do not want the first question to be "is it cheaper?"

The first question is:

Can I tell whether this route behaves like the model I intended to use?

That is especially important when the route is used as a backup for Claude Code limits or routine coding work. A cheap route is useful only if the failure mode is visible early.

The small test suite I would run first

I would not use a single benchmark score. For day-to-day coding, I care more about whether the model handles the boring but failure-prone parts of software work.

1. Preserve existing behavior

Give the model a small refactor task with clear constraints:

• keep the public API unchanged


• do not rename exported fields


• do not change error messages


• do not add new dependencies

Pass condition:

• the diff is smaller than the original file


• behavior is preserved


• the model explains what it intentionally did not change

Fail condition:

• it rewrites the module style for no reason


• it changes defaults or fallback behavior


• it invents a cleaner API that callers do not use

2. Handle an empty configuration

Ask it to fix code that crashes when config is missing.

Pass condition:

• missing config is handled explicitly


• logs or errors are useful


• default values are not silently dangerous

Fail condition:

• it hides the error with a broad catch


• it returns a fake success state


• it changes billing, permissions, or routing defaults without calling that out

3. Explain the risk before editing

Before the patch, ask for a short risk list.

Pass condition:

• it names the risky areas


• it separates mechanical edits from behavior changes


• it asks for missing acceptance criteria when needed

Fail condition:

• it jumps straight to code


• it treats tests it wrote itself as enough proof


• it misses user-visible behavior

4. Use independent evidence

The same model should not be the only verifier of its own patch.

Pass condition:

• it points to existing tests, logs, repro steps, fixtures, or human acceptance criteria


• it marks missing evidence as missing


• it does not overclaim

Fail condition:

• it writes new tests and says the patch is verified only because those tests pass


• it relies on its own explanation as proof


• it cannot distinguish evidence from confidence

5. Stay within a narrow task boundary

Give it a small issue and a tempting nearby cleanup.

Pass condition:

• it solves the requested issue


• it leaves unrelated cleanup alone


• it explains follow-up work separately

Fail condition:

• it turns a bug fix into a broad rewrite


• it changes formatting, naming, and structure without need


• it makes review more expensive than the original problem

The important part is not the score

I would record the result like this:

The empty cells matter. They show which parts are not verified yet.

Why this matters

For low-cost coding routes, the expensive part is often not generation. It is review.

If the model saves tokens but increases the human review burden, it is not actually cheap. If the route can pass small, reproducible, independent checks, then it becomes much easier to decide which work belongs there.

My current rule:

Use cheaper routes for tasks with cheap independent verification. Keep risky behavior changes on the strongest model or behind a human review gate.

That rule has been more useful than asking whether a model is generally "good at coding."