I ended blog #14 with this question: “Are you still picking models, or are you designing a system?” Back then the post had to gesture at that “system” with component lists and layer diagrams. Now the industry widely uses a name for it: harness engineering. The term #25 only name-dropped was made concrete by OpenAI’s field report in February and Birgitta Böckeler’s design frame in April.
You might ask why one term going mainstream matters. Behind this one there’s a benchmark incident. Let’s start there.
Twenty-five places without changing the model once
In March, the LangChain team took their coding agent (deepagents-cli) from around 30th to 5th on Terminal Bench 2.0. In score terms, 52.8% to 66.5%. The model stayed gpt-5.2-codex the entire time. Everything they changed was outside it:
- They built self-verification loops into the system prompt — check your own work before answering
- They reworked tools and context injection so the agent could understand its own environment
- They added middleware hooks that detect failure patterns like doom loops — repeating the same failing action
The method isn’t flashy either. Collect traces at scale, find the failure modes, fix the harness, run again. It’s #32’s “you can’t improve what you can’t measure” applied to the harness itself.
There’s a second piece of evidence pointing the same way. Faros ran 211 real engineering tasks and found that with a properly optimized harness, open models like GLM-5.2 and Kimi K2.6 went toe-to-toe with frontier models.
Both cases point at one conclusion: the equation “benchmark rank = model quality” has broken. If the same model produces results that far apart, the difference lives entirely outside the model. The bottleneck has moved.
The harness: everything but the model
Böckeler’s formula is the cleanest definition. Agent = Model + Harness. Everything in an agent that isn’t the model — tool interfaces, context delivery, planning artifacts, verification loops, memory, sandboxes — is harness: the control apparatus that stops an agent before it produces unwanted results, and helps it self-correct when it does.
Put this on a timeline and the last four years compress into one story:
| Period | Bottleneck | What it deals with |
|---|---|---|
| 2022–23 | Prompt engineering | Language — how to ask |
| 2024–25 | Context engineering | Information — what to show |
| 2026– | Harness engineering | Environment & control — where and how it works |
Context engineering, covered in #30, was the second phase. The harness doesn’t replace it; it contains it — if context is “what to feed in,” the harness is the entire plumbing and valves that context flows through.
One thing worth flagging early: harness engineering is not a new discipline. Look at the list again — linters, tests, CI, code review, observability. All of it is what software engineering has used for thirty years. What’s new isn’t the tooling but the consumer. The primary user of these devices changed from humans to agents, and that changed the spec. A lint error for a human can just say “fix this.” A lint error for an agent is the prompt.
Guides × Sensors — the harness is a control system
The real contribution of Böckeler’s piece isn’t the term; it’s the frame. Treat the harness not as a parts list but as a control system. There are only two kinds of parts.
Guides (feedforward) — things that steer the agent before it goes wrong. Rule files like AGENTS.md and CLAUDE.md, skill documents, bootstrap scripts, architecture definitions. Most of #30’s context design lives here.
Sensors (feedback) — things that observe results and drive self-correction. And here there’s a distinction that matters:
| Sensor type | Nature | Speed & cost | Examples |
|---|---|---|---|
| Computational | Deterministic | ms–seconds, cheap | Linters, type checkers, tests, structural tests |
| Inferential | Judges meaning | Seconds–minutes, expensive | AI code review, LLM judges |
The field reports already exist. OpenAI uses a roughly 100-line AGENTS.md as a map into structured in-repository documentation, enforces its layered architecture with custom linters and structural tests, and periodically scans documentation for drift. Stripe pulls Minions’ feedback ahead of CI with local checks and pre-push linting. Spotify reports more than 1,500 AI-generated PRs merged into its production codebase through Honk.
One design principle falls straight out of the frame: every rule written in a guide should be enforced by a sensor. With instructions but no verification, a probabilistic engine will eventually forget the instructions. If AGENTS.md says “don’t import across layers,” a structural test that catches exactly that should exist as its pair. Guides give direction; sensors do the enforcing.
Why now — AI code fails in a different kind of way
One observation showing why harnesses matter comes from security vendor Apiiro’s published analysis. Apiiro says its proprietary engine analyzed tens of thousands of repositories and several thousand developers across Fortune 50 enterprises; it reports AI-assisted developers committing at 3–4x the rate while monthly new security findings rose from about 1,000 to over 10,000, a 10x jump. The raw data and an independent reproduction are not public, so the figures below should be read as vendor observations from that sample, not universal laws.
But the composition matters more than the total:
| Defect type | Change |
|---|---|
| Syntax errors | −76% |
| Logic bugs | −60% |
| Privilege-escalation paths | +322% |
| Architectural design flaws | +153% |
AI code actually produces fewer of the defects that compilers and linters catch. What grew is precisely the other side — defects of meaning and structure, the kind computational sensors are in principle blind to. #31 argued that AI code is plausible but subtly wrong; this is that sentence in statistical form.
The implication for harness design follows immediately. Computational sensors alone no longer cut it — the growing defect classes pass right through that net. But running inferential sensors on every commit is slow and expensive. So the central problem of harness design becomes: filter as far left as possible with cheap computational sensors, and spend expensive inferential sensors only on what the computational ones can’t see. Böckeler says the same thing — a good harness doesn’t remove human involvement; it redirects human judgment to where it matters most.
In practice: you can start a harness on Monday
“Harness” sounds grand, but the starter recipe in Augment’s guide is a one-day job.
1) Reopen your last five agent PRs. Look for patterns that got flagged repeatedly in review, or caused problems after merge. You’ll typically find about three recurring debt patterns.
2) Encode those patterns as lint rules. The error message is the point — include the “fix it this way” instruction in the message itself. For a human that’s a courtesy; for an agent, that message becomes the prompt for its next attempt. The error message is the guide.
3) Promote them to CI gates. No pass, no merge. From that moment the rule stops being advice and becomes enforcement, and the agent runs its own self-correction loop against it.
4) Measure before and after. Review time and defect escape rate. Without measurement, your harness too becomes what #32 called improvement by luck.
And one fact runs through all of it. Prompts vanish when the conversation ends, and models keep changing. But lint rules, structural tests, AGENTS.md, CI gates — they live in the repository. Read the LangChain result the other way and at least some of the improvement accumulated in the operating system around the model, rather than in that specific model. Models are rented; the harness is owned.
What people actually wanted
Look at the demand behind this term and the picture sharpens. Per Faros, about 75% of engineers already use AI tools, yet measurable org-level gains are thin — and in DORA’s survey, 30% of developers say they have little or no trust in AI-generated code. Adoption is done; results and trust didn’t follow. In that gap, what organizations wanted wasn’t a smarter model. It was a more predictable system. A model upgrade is something you wait for; a harness is something you design — and engineering organizations have always been better at designing than waiting.
Through this lens, the recent posts on this blog turn out to be pieces of one picture. #30 (context) was guide design, #31 (reviewing AI code) was an inferential sensor, #32 (evals) was the foundation sensors are built on, and #25 (loops) was the trigger outside the harness. The pieces now come with an assembly diagram.
To #14’s question — picking models, or designing systems? — the industry answered by coining a name. And when something gets a name, it becomes a job. Next time a benchmark chart crosses your feed, there’s one more question to ask: is that the model’s score, or the harness’s?
References: Harness engineering: leveraging Codex in an agent-first world (OpenAI), Harness Engineering for Coding Agent Users (Birgitta Böckeler, martinfowler.com, 2026-04-02), Improving Deep Agents with harness engineering (LangChain), Minions Part 2 (Stripe), Honk Part 1 (Spotify), Harness Engineering (Faros AI), 4x Velocity, 10x Vulnerabilities (Apiiro, 2025-09). Figures are as published as of 2026-07-19; vendor figures are quoted within the scope and methodology those vendors describe.