Select Claude Models, Design Verification Loops, and Recover from Failure

Quick answer

Choose a model according to task complexity, latency, and cost—not status. Use a capable general model for routine implementation and escalate reasoning for ambiguous architecture, difficult debugging, or high-cost decisions. More importantly, give every task a verification oracle: a test, build, typecheck, benchmark, screenshot, security check, or reproducible observation. Model strength cannot compensate for an undefined finish line. Anthropic's best-practices guide centers the same explore-plan-implement-verify discipline.

Match model effort to uncertainty

Three dimensions matter:

Breadth: how many components and constraints interact?
Ambiguity: is the desired behavior specified or still being discovered?
Cost of error: is this a local test refactor or a production data migration?

Use the session's /model control or CLI model flag after checking current availability. Escalate when the reasoning bottleneck is real. Do not use an expensive model to compensate for noisy prompts, missing tests, or a poorly scoped repository.

A useful staged pattern is:

Fast exploration to locate relevant code and facts.
Stronger reasoning for competing designs or a stubborn root cause.
Routine implementation against an accepted plan.
Independent review using a fresh context.

Create verification at three levels

Focused verification proves the changed behavior: a regression test, one endpoint request, or one component interaction.

Integration verification catches broken contracts: typecheck, service tests, schema validation, or a browser flow.

Repository verification catches collateral damage: full build, lint, test suite, generated-file check, and git diff --check.

Define exact commands in the prompt:

Acceptance criteria:
- The failing case is reproduced by a test before the fix.
- `pnpm test auth/session-expiry.test.ts` passes after the fix.
- `pnpm typecheck` and `pnpm build` pass.
- No API response shape changes.
- Show the commands, exit status, and changed-file summary.

For UI work, combine DOM assertions, screenshots at meaningful viewports, console-error checks, and keyboard interaction. “Looks good” is not a test.

Diagnose failure by phase

If Claude edits the wrong layer, the context or contract was weak. If the solution is plausible but wrong, the verification oracle was weak. If it repeats approaches, the session context may be polluted. If tools cannot act, inspect permissions, environment, and dependencies. If a correct local change fails in CI, compare runtime versions, environment variables, working directory, network access, and generated artifacts.

Never respond to failure with “try harder.” Supply a discriminating observation:

Stop editing. The regression still reproduces only when two refresh requests overlap.
Trace the concurrent path, list shared mutable state, and propose a deterministic test.
Do not change the public API.

Use adversarial review

After implementation, ask a fresh reviewer to disprove correctness:

Review this diff as a skeptical maintainer. Find concrete cases where it violates the
acceptance criteria, security boundary, transaction semantics, or existing conventions.
Do not rewrite code unless you first cite evidence. Rank findings by severity.

Separate implementation and evaluation when stakes are high. A second context is less anchored to the original approach.

Mastery lab

Choose one flaky test. First reproduce and classify it without editing. Write a deterministic failing test, repair the root cause, run focused and repository checks, then have a fresh session review the diff. Record which verification caught each defect and which model/effort level actually changed the outcome.

FAQ

Is a passing test suite proof of correctness?

It proves only the encoded properties under that environment. Review missing cases, production differences, and security invariants.

When should I switch models mid-session?

Switch when the task's reasoning profile changes, not simply after one failed attempt. First improve evidence and scope.

What evidence should a handoff include?

The root cause, accepted constraints, files changed, commands run, exact results, remaining risks, and any checks that could not run.