Harness Over Model
You control the harness far more than the model. Why the fundamentals that worked for thirty years still win in the agent era.
Two things you're actually working with
Every session with Claude Code has two separate parts, and it's easy to conflate them. There's the model — the reasoning engine, upgraded by Anthropic on their schedule, out of your hands. And there's the harness — the repo, the docs, the tests, the guardrails, the prompts. That's yours.
You control the harness far more than you control the model. Model quality is a rising tide that lifts every user equally — you didn't earn it and you can't direct it. Harness quality is the one lever that's entirely yours, and it's what actually separates people getting real leverage from people stuck re-prompting the same broken task all week.
A faster engine in a bad car is still a bad car
Think of the model as the engine and the harness as everything else — chassis, tires, the pit crew, the track itself. A new engine drops in every few months (Sonnet, Opus, whatever ships next) and every driver on the road gets it at the same time. It's not a competitive edge; it's a floor that keeps rising under everyone.
They arrive for free, apply to every user equally, and you have zero say in when or how much. Betting your whole workflow on "the model will just get smarter" is betting on someone else's roadmap.
A clearer CLAUDE.md, a test suite that actually catches regressions, an interface that hides complexity instead of leaking it — these compound. They make every future session better, on any model, and nobody can take them back.
When an agent does something wrong, the instinct is to blame the model and re-roll the prompt. Often the real bug is in the harness — an unclear instruction, a missing test, a file the agent never should have been allowed to touch. Fix the harness once and the failure mode is gone for good, on every model you ever swap in.
Nothing here is new — that's the point
Look at what actually makes a harness good, and none of it is AI-specific. It's the same discipline software engineers have argued for since before language models existed. Version control. Tests. Clear interfaces. Small diffs. Written-down context. The agent era didn't invent these — it made skipping them expensive again.
A test suite is a harness the agent can't argue with. It either passes or it doesn't — no persuading, no confident-sounding wrong answer gets through.
Commits, branches, reflog. The full undo ladder means you can let an agent work fearlessly, because nothing it does is unrecoverable.
Ousterhout's strategic-programming idea from decades ago. A codebase with clean seams lets a cheaper, dumber model still do good work in it — the interface does the thinking a smarter model would otherwise have to.
Docs, ADRs, a CONTEXT.md. This used to be "for the next engineer." Now the next engineer might read it in eleven seconds and act on it immediately — the payoff arrived faster, the practice didn't change.
A change you can actually read end to end is a change you can actually verify. Agents will happily produce a 2,000-line diff if you let them — the discipline of keeping changes small was always yours to enforce.
Reproduce, isolate, form a hypothesis, test it. An agent that guesses randomly at a fix is doing what an undisciplined human does — the fundamentals fix both.
You've already been building this harness
This isn't abstract — you can point at the harness pieces already sitting in this workspace. Each one is exactly the "fundamentals that still win" idea, wearing a Claude Code costume.
CLAUDE.md
git (restore / reset / reflog / worktree)
/verify skill
tests + typecheck before commit
CONTEXT.md / domain docs
loop guardrails (budget caps, dead-letter)Every one of those existed as good practice for engineers working alone, long before any of this. Adding an agent to the loop didn't change what "good" looks like — it just made bad practice fail louder and faster, and good practice pay off sooner.
The question to ask when something goes wrong
Next time an agent does something dumb, resist the reflex to just re-prompt harder or switch models. Ask instead: is this a model problem, or a harness problem? Almost every time, it's the harness.
Harness problem. There was no test forcing it to notice the mismatch, or no doc telling it which pattern is current.
Harness problem. Nothing in the setup constrained scope — no permission boundary, no explicit instruction about what's off-limits.
Harness problem. There was no verify step, no test, nothing forcing a real check before the claim.
The rare true model problem. Everything else on this list, fix the harness first — it's cheaper, it's permanent, and it works on whichever model you're running next month.
Model or harness?
Three situations. Diagnose where the real fix belongs.
An agent says "done, tests pass" — but you check and the tests were never actually run.
What's the real fix?
You have an hour to spend improving how well agents work in a messy module.
Which gives more durable leverage?
A junior dev asks why "harness engineering" — tests, docs, clean interfaces — suddenly matters so much in the agent era.
The most accurate answer?
Pick one repo you work in with agents. Find the last time one of them did something wrong, and ask the diagnostic question from Screen 5: model problem or harness problem? Fix the harness gap — a test, a doc, a boundary — and it stays fixed no matter which model you're running next month.