The Foundations of Harness Engineering

Much of the conversation around AI-assisted development focus on the model, but the model is only one part of the equation. The codebase, the environment the agent operates in, and the harness around it, all have a major impact on the agent ability to succeed.

Give a capable agent a well-structured repository, reliable tests, fast feedback loops, clear interfaces and observable runtime behavior, and it can often make surprisingly large and correct changes with little supervision. In that environment, even a smaller, cheaper model may be successful because the system has already made much of the reasoning work easier.

However if you put a frontier model in a repository full of undocumented conventions and brittle tests, it will struggle to succeed, consuming much more tokens along the way.

The harness

A useful way to think about these systems is:

Codebase → what the agent can understand and change

Environment → what the agent can run, inspect and interact with

Harness → the tools, constraints and feedback loops that guide the agent towards a correct outcome

Together with the model and agent, these determine how much autonomy the system can actually support. Imagine asking an agent to add a new capability to an existing application. Before it writes any code, it needs to answer several questions:

• What is the desired behaviour?
• Which part of the architecture owns it?
• Which existing abstractions should it use?
• What constraints must the implementation respect?
• How can it verify that the implementation works?
• How can it inspect failures?
• How can the change be released safely?

Humans answer many of these questions using context they accumulate over months or years.

They know that a particular service should not be called directly or which component is the canonical implementation despite three similar alternatives existing in the repository. Much of this knowledge never appears explicitly in the code.

As we ask agents to operate more autonomously, these ambiguities compound. The foundations of harness engineering are about systematically removing them.

1. Make intent legible

An agent needs to know what success means.

“Implement the new checkout flow” leaves a lot of room for interpretation. The agent needs concrete acceptance criteria, examples and constraints that it can inspect and verify.

The goal is not more documentation. It is less ambiguity. The less the model has to infer about the desired outcome, the more reliably it can act.

2. Make the architecture explicit

Once the agent understands the goal, it needs to understand where the change belongs. Clear domain boundaries, predictable module structures and explicit dependency directions dramatically reduce the space an agent has to explore.

But those boundaries should not exist only as conventions. If an architectural rule can be automatically verified, do not leave it only in prose.

Architectural guidance becomes much more valuable when it can be enforced mechanically.

3. Make knowledge executable

Agents work best when they can discover the system rather than reconstructing it every time. Types, schemas, API specifications, component manifests and design tokens are all forms of machine-readable engineering knowledge.

Instead of telling an agent: “Ensure usage of our design system.” The environment can expose through tooling:

• available components,
• typed props,
• approved design tokens,
• canonical examples,
• accessibility constraints,
• interaction tests,
• visual regression checks.

Now the agent does not have to infer what the design system expects. It can discover the available interfaces and validate its implementation against them. Move knowledge out of the reasoning loop and into the engineering system itself.

4. Shorten the feedback loop

The agent also needs to know whether what it wrote actually works. That means giving it useful signals as early and as fast as possible: type checks, linting, focused tests, browser state, logs, integration tests and eventually full CI.

Humans already benefit from fast feedback. Agents amplify that benefit because their workflow is naturally iterative. An agent may try an implementation, run the system, inspect the failure, modify the code and repeat the cycle several times before presenting the final change.

Every minute added to that loop multiplies across iterations. Make errors cheap to discover and cheap to correct.

5. Make the system runnable and inspectable

Agents cannot reliably change a system they cannot reliably run. When an agent can create an isolated environment, install the application, run it, reproduce a failure and execute the test suite without relying on a developer's machine, it can operate far more autonomously.

But being able to run the system is only half of the problem. The agent also needs to see what happens when it runs: logs, traces, metrics, network requests. An agent that can run the system and inspect its state can investigate it.

6. Make the safe path the easy path

More capable agents create another problem. They produce more changes, and increasingly larger ones.

That means the engineering system also needs to constrain their blast radius: Sandboxed environments, limited credentials, preview deployments, feature flags, progressive rollout and easy rollback are not separate concerns from agent productivity. They are what make higher levels of autonomy possible.

7. Use evals to measure the whole system

Take a representative set of tasks:

• add a new form using the design system,
• modify an API without breaking compatibility,
• fix a known regression,
• implement a new component,
• diagnose a runtime failure,
• add a feature flag and preview deployment.

Then evaluate agents against those tasks.

Measure:

• successful completion,
• retries,
• wall-clock time,
• tokens consumed,
• cost,
• test failures,
• human intervention.

Now something interesting becomes possible. You can evaluate not only models, but improvements to the engineering system itself. If the same tasks can now be completed more reliably, with fewer retries, fewer tokens or a smaller model, you have measurable evidence that the harness improved.

Evals are therefore not only a way to compare models. They are the feedback loop for harness engineering itself.

Agent readiness is a systems property

Investments that were already hallmarks of good engineering: clear boundaries, reliable tests, reproducible environments and observable systems, suddenly have another consumer:

the coding agent.

Harness engineering is about designing the entire engineering system so that an autonomous agent can understand what needs to change, make that change, observe the result, verify it and operate within safe boundaries.

For years, these investments were justified through developer productivity, maintainability and reliability. The best agent-ready engineering systems will be the ones with the fewest ambiguities and the strongest feedback loops.