The Bottleneck Moved
Something important happened over the past few years: writing code stopped being the slow part.
A competent engineer with a modern coding agent produces working file-level changes at a pace that would have looked absurd a decade ago. Scaffolding, refactors, test suites, glue code — the marginal cost collapsed. And yet, in most organizations, the throughput of finished engineering outcomes barely moved.
The bottleneck did not disappear. It moved — to everything around the code. Figuring out which systems a change touches. Keeping four parallel edits consistent with each other. Getting infrastructure provisioned before the code that needs it. Proving the change works after it ships. Remembering, three months later, why any of it was done. That work was always the expensive part; it used to be masked by the cost of typing. Now it stands exposed as the constraint.
Coding agents cannot absorb this work, because it is not in the code. It is between the systems. What absorbs it is a different kind of thing — and it needs a name. We call it an engineering harness.
A Definition
An engineering harness is one system that carries an engineering objective across every system it touches — repositories, infrastructure, CI/CD, and production — by coordinating specialist agents against a shared plan, verifying outcomes with evidence, and retaining what it learned as durable memory.
The word "harness" is chosen deliberately. A harness is not the horse — it does not replace the power source, whether that is a frontier model or your engineers. A harness is what lets power pull in one direction: it connects, constrains, and transmits. Swap the horse; keep the harness.
Concretely, a harness is defined by four properties. Each is missing from single-repository agents, and each is load-bearing.
Property One: The Unit of Work Is the Objective
In a harness, you do not submit prompts; you open a mission — a durable object that owns an objective from acceptance to verified completion. The mission discovers its own scope (read-only, before proposing anything), plans across all affected systems at once, and persists until the outcome is proven — not until a context window fills or a chat tab closes.
This sounds like project management vocabulary, and that is the point. The unit of engineering work in a real organization has never been "a message" or even "a PR"; it has been the objective. Tooling just never modeled it. A mission is that missing object, made executable. (A full replay lives here.)
Property Two: Delegation With Pinned Boundaries
A harness does not scale by making one agent's context bigger. It scales the way organizations do: decomposition with explicit contracts.
The shared interfaces between systems are pinned before parallel work begins — the API shape, the header contract, the config schema. Then focused agents take one repository each, holding only their boundary plus the pinned contract. A lead orchestrator holds the whole; on every push, the harness re-checks that every side still conforms, so drift is caught while pull requests are open rather than after they merge.
The deep insight here is old: interfaces are how humans coordinate large changes. The harness's contribution is making the contract explicit, machine-checkable, and continuously enforced — turning "are we still consistent?" from a standup question into a failing check.
Property Three: Completion Requires Evidence
In a harness, "done" is a provable state, not a report. A verification agent that wrote none of the code — often running on a completely different model — reads the artifacts: diffs, tests, CI matrices, canary metrics, runtime behavior. The mission completes only when the evidence chain holds end to end: change → tests → CI → rollout → runtime.
This is the property that makes delegation rational. Nobody hands significant objectives to a system whose success reports are self-graded. The harness's answer is the same one engineering culture already gives for humans — independent review, structural rather than optional. "Done" is a claim; evidence is the standard.
Property Four: Outcomes Compound
Every completed mission writes to shared engineering memory: what changed, why, what passed, which constraints were discovered. Records carry sources and verification timestamps; contradictions get flagged instead of silently served; and every future mission recalls before it plans.
This is the property that changes the slope. Tools without memory deliver linear value — each use starts from zero. A harness gets structurally better at operating your organization with every objective it completes, because the context tax shrinks. The system that migrated your checkout fleet to ARM permanently knows the base-image constraint it discovered at 2 a.m. Your newest engineer inherits it on day one.
What a Harness Is Not
Definitions sharpen at the edges:
- Not a bigger coding agent. Coding agents are components inside a harness — they do repository-scoped implementation, and they do it well. The harness is the layer that gives them boundaries, contracts, and a verifier.
- Not a CI/CD system. Pipelines execute predefined steps on predefined triggers. A harness plans novel work, then uses your pipelines as evidence sources.
- Not an autonomy play. A harness is an accountability structure. Approval gates sit exactly where consequences live — infrastructure spend, production mutations — and evidence is mandatory. The goal is not fewer humans; it is humans spending judgment where judgment matters, instead of ferrying context between windows.
- Not a model bet. The harness is deliberately model-independent: frontier, fast, and local models route per role, on your keys. Models are the fastest-depreciating layer of the stack; the harness is the layer that persists.
Why This Category Now
Three lines crossed recently. Models became strong enough that repository-scoped work is genuinely delegable. Organizations accumulated enough agents that coordinating them became the new manual labor. And the failure stories piled up — confident agents, unverified claims, context re-explained forever — teaching everyone the same lesson: the missing layer was never intelligence. It was structure.
Every era of software has a moment where the constraint shifts and the tooling reorganizes around the new constraint. Compilers made assembly a specialty; version control made collaboration survivable; CI made integration boring. The constraint now is coordination — across systems, across agents, across time.
The harness is the tool shaped like that constraint. One objective in, every affected system coordinated, evidence out, and the organization a little smarter than it was before the mission started.
That is the whole idea. The rest is engineering.