Take two teams with the same frontier model and the same budget. One team gets code that mostly passes review. The other gets code that quietly breaks architectural rules, ignores existing utilities and fails in CI.

The model did not cause that gap. The environment around it did.

Source: Generated using AI

That observation is why a new term spread through engineering circles in early 2026: the harness. A source-code study of eleven coding agent systems says the one-line formula, Agent = Model + Harness, was popularized by Viv Trivedy’s LangChain engineering series. The same study says the term “harness engineering” entered wide use in February 2026. It also notes that Mitchell Hashimoto had used it in passing shortly before that.

The title of this article is a claim about how software gets built from here. A person supplies intent and judgment. A model supplies reasoning and code generation. A harness supplies everything that makes the model’s output reliable: context, tools, constraints, feedback loops and memory. Remove any one of the three and the system degrades in a predictable way.

This article explains what a harness is, how it works internally, what the evidence says about its value, and where it fails. It is written for engineers and technical leaders who have to decide how much autonomy to give these systems.

Background: how we got from autocomplete to agents

The first wave of AI coding tools was autocomplete. A model predicted the next few tokens from the code around your cursor. The human stayed in control of every keystroke, and the feedback loop was instant: you accepted or rejected the suggestion.

The second wave was the chat assistant. You pasted code into a conversation and got code back. This could handle larger tasks, but you were the integration layer. You copied output into files, ran tests, pasted errors back and repeated.

The third wave is the agent. An agent runs a loop. It reads files, edits them, runs commands, observes the results and decides what to do next. The loop is what changes the economics. The human no longer shuttles information between the model and the machine, because the agent does that itself.

Once the loop exists, a new question appears. What happens inside it, and who designs it? Early agents were thin wrappers around a model with a few tools. As tasks grew from single-file edits to multi-hour changes across a repository, the wrappers grew too. They gained retrieval, context compaction, permission systems, sandboxes, sub-agents and verification steps. The eleven-system study mentioned above argues that during the first half of 2026 the coding harness moved from being a tool to being a platform.

Core concepts: prompts, context and harnesses

Three terms get mixed up, so it helps to separate them. An O’Reilly essay on harness design puts it this way. Prompt engineering shapes one model call. Context engineering decides what the model sees. Harness engineering governs the whole system wrapped around those calls.

A useful mental model is a workshop. The model is a skilled but forgetful craftsperson who starts each morning with no memory of yesterday. The prompt is the instruction you give for one job. Context is what you lay on the bench. The harness is the entire workshop: labeled drawers, safety guards on the machines, a checklist on the wall, an inspector at the door, and a logbook of past mistakes.

Birgitta Böckeler’s guide on martinfowler.com, as summarized here, defines the harness as everything in an agent except the model. For coding agents she separates two layers:

• The inner harness ships with the tool. It includes the system prompt, the code retrieval mechanism and the built-in tools of products like Claude Code or Codex.
• The outer harness is what your team builds for your own codebase: rules files, custom linters, test suites, architectural checks and review agents.

You mostly cannot change the inner harness. The outer harness is where engineering teams have leverage, and it is the part that this article focuses on.

The three roles

How an agent harness works internally

Most coding harnesses share the same skeleton, even when the implementations differ. The core is a loop, and the harness is everything that feeds, guards and checks that loop.

Suggested visual: the agent loop inside a harness, with human, model, tools and verification layers labeled

Context assembly

Before the first model call, the harness decides what the model sees. This usually includes a system prompt, the user’s task, a repository instruction file such as AGENTS.md, and the results of retrieval over the codebase.

Context is the scarcest resource in the system. Model context windows are finite, and performance tends to degrade when they fill with irrelevant material. So harnesses spend real effort on context hygiene: loading information progressively, summarizing old turns (called compaction), and pushing large tool outputs to files instead of keeping them in the conversation.

The practical lesson from OpenAI’s account of its Codex experiment and from the surrounding guidance is to keep the top-level instruction file short and make it point to deeper documents. A giant rules file crowds out the task. A small map that tells the agent where to look works better.

Tools and the action space

The model can only affect the world through tools. A typical coding harness exposes file reading and editing, search, shell execution and sometimes browser or API access. Every tool is a design decision. A tool that returns too much text wastes context. A tool with a vague error message wastes a turn. A tool with too much power widens the blast radius of a mistake.

Permissions and isolation

Agents run commands, so the harness needs a security boundary. Common patterns include sandboxed execution, allow-lists for shell commands, approval prompts for risky actions, and one isolated git worktree per agent so parallel agents cannot overwrite each other. Community catalogs of harness tooling, such as this curated list, describe the “one agent, one worktree” pattern as the standard way to keep parallel work clean.

Verification

Verification is the part that turns a plausible change into a trustworthy one. It includes unit and integration tests, type checks, linters, build steps, and increasingly, custom checks that encode architectural rules. A well-designed harness makes every check runnable by the agent itself and writes failure messages as instructions the agent can act on. The error should say what to fix, not just that something broke.

Memory and persistence

Agents forget between sessions. The filesystem is the usual memory. Harnesses load files like AGENTS.md on every start, and some let the agent update them, so lessons from one session carry into the next. Addy Osmani’s April 2026 write-up argues for treating each agent mistake as a permanent signal. The fix goes into the environment, not into a one-off retry.

A walkthrough

Here is one pass through the loop, to make it concrete. A developer files an issue: “Add rate limiting to the export endpoint.”

1. The harness assembles context: the issue text, the repository’s instruction file, and a retrieval pass over files that mention exports and middleware.
2. The model reads the existing middleware and proposes a change.
3. The harness checks permissions and applies the edit inside a sandboxed worktree.
4. The agent runs the test suite. Two tests fail because a shared fixture changed.
5. The failure output goes back into context. The agent fixes the fixture.
6. A structural check runs and fails: the new code imports a database module directly from the HTTP layer, which the repository forbids. The message says which layer boundary was crossed and where the approved interface lives.
7. The agent reroutes the call through the service layer. All checks pass.
8. A review agent and then a human look at the diff, and the change merges.

Notice who did what. The human defined intent in step one and judged the result in step eight. The model did the reasoning and editing. The harness caught two errors the model would otherwise have shipped.

The evidence: what OpenAI’s experiment shows and what it does not

The most cited example is an engineering post by Ryan Lopopolo, published by OpenAI on February 11, 2026. The post describes a five-month internal experiment. A team built and shipped an internal beta product with no manually written code. By the team’s account, the repository reached roughly a million lines of code, written by Codex agents. Secondary summaries report a small team of three engineers growing to seven, and around 1,500 merged pull requests. Treat those two numbers as secondary reporting, because I could not confirm them in OpenAI’s own text.

What makes the case interesting is where the engineers spent their time. They were not typing code. They were building the environment: machine-readable documentation, telemetry the agents could query, and structural tests that enforced architecture. InfoQ’s coverage and independent summaries describe the same pattern.

OpenAI also released Symphony, described by community catalogs as a reference implementation. It is a daemon that polls issues in Linear, starts an isolated Codex agent for each one, and delivers a pull request. The slogan attached to it is that humans steer and agents execute.

There are limits to what this proves. It is one team, one product, reported by the company that sells the tools. An interview summary published by InfoQ China says the team also skipped human review before merging. That is a deliberate experiment, and it is not a recommendation that most organizations should copy, especially where regulation, safety or money is involved. The experiment shows that a heavily harnessed agent can produce a large codebase. It does not show that the codebase is cheaper to maintain or that the approach generalizes to older, messier systems.

Does the harness really matter more than the model?

Osmani’s post makes a strong claim: a decent model in a great harness can beat a great model in a poor one. He cites a Terminal Bench 2.0 comparison in which the same Claude model scored much lower inside one harness than inside a custom harness, and says Trivedy’s team moved a coding agent from roughly the top 30 to the top 5 by changing only the harness. These are secondhand benchmark claims from a practitioner blog, so read them as a signal and not as settled fact. They are consistent with the broader finding that scaffolding choices move benchmark scores substantially.

Architecture: designing an outer harness for your team

If your team uses an off-the-shelf coding agent, your engineering effort goes into the outer harness. A practical layout has five layers.

Knowledge: a short map, not a manual

A repository instruction file should be a table of contents. Here is an illustrative example:

# AGENTS.md

## Orientation
- Service code lives in /services. Shared libraries live in /libs.
- Read /docs/architecture.md before changing anything across services.

## Rules that are enforced by CI
- HTTP handlers may not import from /libs/db. Use the service layer.
- Every new endpoint needs an integration test in /tests/api.

## When you are stuck
- Search /docs/decisions for prior decisions before inventing a pattern.
- Run `make check` locally. Its output tells you what to fix.

Notice the second section. It lists rules that CI enforces. That is deliberate. A rule that exists only as text will be ignored under pressure, by agents and humans alike. A rule backed by a failing check will not.

Constraints: turn taste into code

Architectural preferences should become executable checks. The following Python sketch shows an illustrative structural test. It fails when a handler imports directly from the database layer, and it returns a message the agent can act on.

# Illustrative structural check, not tied to any specific framework
import ast
import pathlib
import sys

FORBIDDEN = {"libs.db"}
HANDLER_DIR = pathlib.Path("services/api/handlers")

def violations():
    for path in HANDLER_DIR.rglob("*.py"):
        tree = ast.parse(path.read_text())
        for node in ast.walk(tree):
            if isinstance(node, ast.ImportFrom) and node.module in FORBIDDEN:
                yield path, node.lineno, node.module

def main():
    found = list(violations())
    for path, line, module in found:
        print(
            f"{path}:{line} imports {module}. "
            "Handlers must call the service layer instead. "
            "See services/api/service_layer.py for the approved interface."
        )
    sys.exit(1 if found else 0)

if __name__ == "__main__":
    main()

The last line of the message is the important part. It tells the agent where to go next. Messages written this way shorten the loop and cut the number of wasted turns.

Feedback: make the system observable to the agent

Agents improve when they can see what their code does. Teams in the OpenAI account made logs, metrics and traces queryable by agents, so an agent could check its own change against real behavior. If an agent cannot run the application, read its logs and reproduce a bug, it is guessing.

Oversight: scale review to risk

Not every change deserves the same scrutiny. A reasonable policy might let agents merge documentation fixes after automated checks, require an agent review plus a human glance for ordinary features, and demand full human review for authentication, payments or data migrations. The skeleton looks like this:

# Pseudocode: risk-based merge gate
def merge_policy(change):
    if change.touches(["auth/", "payments/", "migrations/"]):
        return "require_human_review"
    if change.size_lines > 400:
        return "require_agent_and_human_review"
    if change.checks_passed and change.review_agent_approved:
        return "auto_merge_allowed"
    return "block"

Do agents actually make teams faster

Be careful here, because this is where claims run ahead of evidence.

In 2025, METR ran a randomized trial with experienced open-source developers. They were measurably slower with AI tools on their own repositories, even though they believed they were faster. That result became the standard skeptical citation.

In February 2026, METR published an update titled “We are Changing our Developer Productivity Experiment Design”. The title matters. METR reported that wider AI adoption had introduced strong selection effects: developers did not want to work on tasks where AI would be disallowed, which distorted the study. METR said it could no longer measure the effect reliably with the old design and was building a new one. Commentators like Rob Bowley warn against reading the update as a clean new number, such as an 18 percent speedup. METR’s own position is that tools are improving, but the 2025 design cannot show by how much.

The most defensible conclusion is that nobody has a trustworthy, general productivity multiplier for 2026 tooling. Anyone quoting “10x” without a controlled design is selling something.

The organizational evidence points the same direction. The 2025 DORA report, based on survey responses from nearly 5,000 technology professionals gathered between June and July 2025, concluded that AI’s main role is as an amplifier. It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones. It also introduced a DORA AI Capabilities Model of seven practices that amplify AI’s benefits. InfoQ’s summary notes that adoption was near 90 percent while trust in the tools remained low.

An amplifier has no opinion about what it amplifies. If your tests are weak, your architecture is undocumented and your review culture is rushed, an agent will produce more code that is wrong, faster. The harness is the mechanism through which good engineering practice becomes legible to a machine.

Comparing approaches

The last row is not free. You trade per-task effort for up-front and ongoing investment in tests, docs and checks. For a small script or a prototype that will be thrown away, that investment does not pay off. The O’Reilly essay makes a related point: the right harness depends on the job, and most agents need a simpler one than coding agents do. Do not build a long list of techniques because a blog post named them.

Security, privacy and operational risks

An agent that can run commands and read your repository is a powerful actor. The risks are practical, not hypothetical.

A related operational concern is accountability. When an agent writes the code and another agent reviews it, a human still owns the outcome. The harness should make it easy to trace which agent changed what, under which instructions and with which checks.

Limitations and engineering tradeoffs

Harnesses have real weaknesses, and a few of them are non-obvious.

Harnesses encode your past, not your future. A harness built from failure history prevents the failures you have already seen. Novel failures get through. This is why human judgment remains part of the equation.

Checks can be gamed or can drift. An agent optimizing for a green CI run may satisfy the letter of a test without meeting its intent. Tests written by the same agent that wrote the code can share its blind spots. Independent verification, such as separately authored tests or human-written acceptance criteria, reduces that risk.

Complexity is a cost. The eleven-system study describes harnesses moving toward platform-like configuration. That brings power, but also more surface area to maintain. A harness that nobody understands is its own source of failures.

Legacy codebases are harder. Agent-first experiments often start from an empty repository, where the harness and the code grow together. Retrofitting structural checks and documentation onto a decade-old system with inconsistent conventions is slower, and the agents have more to trip over.

Cost and latency add up. Long autonomous runs, retries and review agents consume tokens and time. Whether that is cheaper than a human depends on the task, and public numbers are scarce.

Advanced insight: the harness is a learning system

The most interesting idea in this area is that the harness should evolve. Each time an agent fails, you can ask what capability, document or check was missing. Then you add it. Over months, the harness accumulates your team’s tacit knowledge in a form a machine can use.

Researchers are now automating parts of that loop. The study of eleven systems cites work on agentic harness evolution and on tuning harnesses against benchmarks. This raises an uncomfortable question. If agents can improve their own scaffolding, what remains for humans? The answer, for now, is objective setting and evaluation. Someone still has to decide what counts as better, and an automated optimizer will happily exploit a badly chosen metric.

There is also a subtler point about where humans add value. In a harnessed system, a person’s most leveraged work is rarely writing code. It is writing the thing that makes code correct: the acceptance criteria, the architectural boundary, the observability that reveals a regression. This is closer to platform engineering and test design than to traditional feature development, and it rewards people who understand systems deeply.

Future outlook

It helps to separate what is demonstrated from what is speculative.

Demonstrated: Agents can complete multi-step coding tasks in a sandbox, iterate against tests and open pull requests. A well-instrumented team has reported building a large codebase with agents writing all of the code, at least in one company’s account.

Being deployed now: Issue-to-pull-request pipelines, parallel agents in isolated worktrees, agent-to-agent review, and repository instruction files as a standard practice.

Active research: Automated harness optimization, better long-horizon memory, and reliable measurement of productivity. METR’s own redesign shows that measurement is still an open problem.

Speculative: Fully autonomous maintenance of large legacy systems, and the claim that human review becomes unnecessary in general. For either to hold, verification has to become much stronger than it is today, and the cost of mistakes has to be low or insured. Neither condition is true across most industries.

What would have to change? Models need to hold up over longer horizons without compounding errors. Verification has to cover behavior and intent, not just syntax and unit tests. Organizations need ways to audit agent actions at scale. Until then, the human stays in the loop for the decisions that carry consequences.

Key takeaways

• An agent is a model plus a harness. The harness includes context, tools, permissions, verification and memory, and it strongly affects reliability.
• The outer harness is the part your team controls. Invest in a short instruction map, executable architectural checks, observable systems and failure messages written as fixes.
• Evidence on productivity is mixed and still being measured. METR’s 2025 trial and its 2026 redesign, together with DORA’s amplifier finding, suggest that tooling helps most where engineering fundamentals are already strong.
• Scale oversight to risk. Let agents move fast on low-risk changes and keep humans on authentication, payments, data and anything irreversible.
• Treat every agent mistake as a signal to improve the environment, not as a reason to retry or wait for a better model.

The title says Human + AI + Harness. The part that gets overlooked is the plus sign between the second and third terms. A model without a harness is talented but unreliable, and a harness without human judgment is rigorous about the wrong things. Reliable agentic engineering needs all three, and the teams that learn to design the third will set the terms for the other two.