Harness Engineering: The Real Skill Behind Coding Agents
Most conversations about coding agents obsess over the model — which one writes better code, which one hallucinates less. A recent essay on martinfowler.com by Birgitta Böckeler (Distinguished Engineer at Thoughtworks) makes a convincing case that we're looking at the wrong layer. The differentiator isn't the model. It's everything you build around it — what she calls the harness. These are my notes and takeaways from the piece.
The core idea: if you want agents to work with less supervision, don't try to remove humans from the loop — build systematic controls that direct human attention to where it actually matters, and let automation handle the rest.
What is a harness?
The harness is everything in an agentic system except the model itself. Part of it ships with your agent — the system prompt, the built-in tools, how it retrieves code. But the part you control is the outer harness: the rules files, custom checks, review agents and pipelines your team builds for its own codebase and workflow. That outer layer is where engineering teams can actually compete, because it encodes knowledge no vendor has: your architecture, your conventions, your definition of "good".
Guides and sensors
The essay frames every control as one of two things. A guide steers the agent before it acts — conventions, templates, rules that raise the odds of a correct first attempt. A sensor observes what the agent did — tests, linters, review agents — so it can self-correct. You need both: sensors without guides means the agent keeps making the same mistakes and burning tokens fixing them; guides without sensors means you never find out whether your guidance actually works.
Orthogonal to that split is how a control runs. Computational checks (type checkers, linters, structural tests) are deterministic, fast and cheap — you can run them constantly. Inferential checks (LLM-as-judge, code-review agents) understand semantics but are slow, costly and non-deterministic — you deploy them selectively. Knowing which kind of check belongs where is, to me, the actual craft here.
Three things worth regulating
- Maintainability — internal code quality. Computational sensors reliably catch duplication, complexity and architectural drift; inferential ones partially catch over-engineering and redundant tests.
- Architecture fitness — fitness functions, performance budgets, observability and logging conventions enforced as checks rather than tribal knowledge.
- Behaviour — does the code do the right thing? Böckeler is honest that this is the weak point today. Specs and AI-generated test suites only get you so far, and the highest-impact failures — a misdiagnosed bug, a misunderstood requirement — slip past both kinds of sensor.
Keep quality left
The CI wisdom we already know transfers directly: run fast, cheap checks pre-commit; push expensive sensors like mutation testing and deep review agents into the post-integration pipeline; and keep monitoring at runtime for drift, log anomalies and SLO regressions. The agent workflow doesn't replace the pipeline — it makes the pipeline more important, because the pipeline is now feedback for the agent, not just for humans.
The idea that stuck with me: harnessability
Not every codebase can be harnessed equally. Strong typing, clear module boundaries and mature frameworks give agents — and your checks — something to grip. Legacy codebases face a cruel paradox: they need harnesses the most and support them the least. The essay borrows Ned Letcher's term ambient affordances for this: the structural properties that make an environment legible to an agent. I've felt this firsthand — the same agent that flies through a typed Next.js + FastAPI project flails in an untyped legacy script with no tests. The codebase itself is part of the harness.
My takeaways as a builder
- Write guides before adding sensors. A rules file that encodes your conventions is the cheapest control you will ever ship.
- Prefer computational checks wherever possible. Reach for an LLM judge only when a linter or structural test genuinely can't express the rule.
- Choose stacks for harnessability. TypeScript over loose JS, typed APIs over ad-hoc JSON — not for the humans, but because agents govern better in typed, bounded systems.
- Behaviour is still on you. No harness yet catches a correctly-implemented wrong idea. That review is where human attention belongs.
The whole essay is worth your time — it's the clearest mental model I've seen for working with coding agents beyond prompt tricks.
Read the original on martinfowler.com