Service 06 / 06
Your team has coding agents. The review queue is the bottleneck.
A harness is everything an agent needs except the model: the map of your codebase it reads first, the checks that run before you ever see its work, the conventions enforced by the build rather than asked for in a prompt, and the hard boundaries on what it may touch. It is what turns more pull requests into more shipped code instead of a longer queue.
What I build
- A short, current map of the codebase the agent reads first, and the deeper notes it opens only when the task needs them
- Checks that run before you ever see the work: types, tests, linters, your own architecture rules
- Conventions enforced by the build rather than asked for in a prompt: an agent can ignore a sentence, not a failing check
- Hard boundaries on what an agent may touch, which changes still need a human, and a record of what it did
What you get
A repo your agents work well in, and the habit that keeps it that way: every mistake they make becomes a check, so it can't happen the same way twice.
Good fit ifyour team already codes with agents and the review queue is where it stalls.
Most of a harness isn't a product you buy: it's your own codebase made legible to an agent. Which is also why it outlives whichever model you're using this quarter.
What is a coding agent harness?
A harness is the engineered environment around a coding agent: the term settled in early 2026 on the shorthand "agent = model + harness", and the harness is the half you own. The model changes every quarter. The harness is what keeps working when it does.
Concretely it is four things: context the agent reads before it starts, checks it must pass before a human looks, conventions that fail the build rather than living in a style guide, and limits on blast radius.
Why more pull requests made things slower
Because review capacity did not grow with generation capacity. Every developer on the team now produces work at several times their previous rate, and each of those changes is plausible, passes its tests, and is slightly not how your codebase does things. The reviewer is the one who has to notice "slightly", on every one of them, all day.
You cannot fix that by reviewing harder. The only durable answer is to move as much of the review as possible in front of the human, into checks that an agent cannot talk its way past.
An agent can ignore a sentence. It cannot ignore a failing check.
This is the load-bearing principle, and it is what separates a harness from a prompt. A convention written in a document is a request. The same convention expressed as a check that fails the build is a fact about the codebase.
The practical version is that every recurring mistake becomes a check the first time it happens twice. This repository does that to itself: the build refuses to produce a page whose head could not be stamped correctly, refuses a blog post whose metadata is malformed, and refuses a picture wearing another page's alt text: each of those is a mistake that was made once and can now never ship silently.
The context layer is a map, not a manual
The most common failure in agent context is a single instructions file that has grown to thousands of lines nobody prunes, which costs tokens on every task and buries the ten rules that actually matter.
What works better is a short, current map that is always read, pointing at deeper documents that are opened only when the task touches them. This repository is built that way, and the split is visible in it: one map file, a table of topic documents, and a rule that new lessons land in the topic document rather than back in the map.
What you get, and what you keep
A repository your agents work well in, plus the habit that keeps it that way. The habit is the deliverable that outlasts the engagement: every mistake becomes a check, so it cannot happen the same way twice.
Most of a harness is not a product you buy: it is your own codebase made legible to an agent. That is also why it survives whichever model you are using this quarter.
Questions people ask
- Is this just writing a CLAUDE.md or AGENTS.md file?
- That file is the smallest part, and on its own it is the thing that decays. A harness is mostly executable: type checks, tests, linters and architecture rules that fail the build, plus explicit limits on what an agent may change without a human. The instructions file works because those exist, not instead of them.
- How is this different from the linting and CI we already have?
- It is the same idea aimed at a different reader. Existing CI is tuned to catch what humans get wrong; agents get different things wrong: plausible code that ignores a local convention, a second way of doing something the codebase already does once, a boundary crossed because nothing said it was a boundary. The work is finding those and making them mechanical.
- Will this slow the team down?
- It moves time from review to setup, and the trade is usually strongly positive once more than one person is generating code. The failure mode to avoid is checks that fire on style nobody agreed on. Every rule should be traceable to a real mistake that was actually made.
- Does it work with any coding agent?
- Yes, because almost all of it is in your repository rather than in a vendor. Checks, conventions and documented context are read by whichever agent your team uses, and stay useful when they switch, which they will.
- How do you stop an agent breaking something important?
- By deciding in advance what it may touch unsupervised and enforcing that boundary mechanically, rather than trusting an instruction. Some paths need a human on every change, some changes need a second check, and everything an agent did should be recoverable, which is a policy question first and a tooling question second.