Harness Engineering in Practice: Stop Agents Building the Wrong Thing

The wrong-thing problem

An agent that writes broken code is easy to catch. The test fails, you see it, you move on. The expensive failure is quieter. The agent writes clean, working code for the wrong thing. It adds a caching layer next to the one you already have. It installs a second queue library because it did not know the first one was there. It spins up a database it likes instead of the one in production. Everything passes, and you have just paid tokens and time to grow the mess you were trying to shrink.

These are not model mistakes. The model is capable. They are context mistakes. The agent did not know the shape of the system it was working in, so it made a reasonable guess, and reasonable guesses about a system you cannot see are wrong most of the time.

Harness engineering is prevention

This reframes what the work actually is. Harness engineering has become the practice of stopping an agent from doing the wrong thing so it has room to do the right thing. It is prevention before it is anything else.

The hard part is that the right thing and the wrong thing are not fixed. They change from one project to the next, and they change from one session to the next inside the same project. The database you standardized on this quarter, the helper you just wrote, the sandbox you settled on yesterday. Keeping an agent current with all of that is a constant catch-up, and I could not keep up by hand. Every session started with me re-explaining the same system, and every gap I missed became another wrong turn.

Smarter agents make it worse

The obvious hope is that better models end this. They do the opposite. A smarter agent makes more decisions, and it makes them faster. Each decision it takes without knowing your system is another chance to head the wrong way, and no human reviews decisions at that rate. The more capable the agent, the more the missing context costs, because the agent commits to more before anyone can correct it. Speed turns a small context gap into a large amount of confidently wrong work.

The faster the agent, the more expensive it is to let it guess.

Environments for systems

The shift that fixed it for me is a change in where the context lives. We already know how to make an environment for development. You set up dependencies, config, and tooling so a new developer is productive on day one instead of spending a week discovering how the project fits together. Do the same for the system the agent operates.

When the agent is part of the system rather than a visitor to it, the guessing stops. It knows the deployment surface because the deployment surface is part of the environment it runs in. It does not have to discover which database you use or how to use it, because the database is a known capability of the system. It does not install or build a second version of something you already have, because the existing solution is present and visible. It does not forget which sandbox it picked or which database it is actually running, because that state belongs to the system, not to the last few thousand tokens of a conversation.

What "part of the system" means

Concretely, this is the difference between handing an agent a blank workspace and handing it a running system it can read. Express the system as the units of work it is made of, the events that trigger them, and the capabilities they call, and the things an agent keeps getting wrong become facts it inherits:

• The deployment surface is part of the environment, so the agent targets what actually exists instead of inventing a target.
• The database and how to use it is a known capability, so the agent queries the real one rather than picking a new favorite.
• The solutions you already have are visible, so the agent extends them instead of shipping a duplicate.
• The chosen sandbox and current state live in the system, so the agent does not forget its own decisions between steps.

This is the same instinct I wrote about in harness engineering: hold the model fixed and put the effort into the environment. Here the environment is not just documents to retrieve, it is the live system the agent is operating, and that is what stops the wrong-thing failures at the source.

The results, and why

I measured this on my own work before I trusted it. Giving the agent a system it is part of cut token usage by roughly 60% and about doubled the speed from design to build. These are my own numbers on my own projects, not a benchmark, so treat them as a direction rather than a guarantee. The direction has been consistent enough that I stopped setting up agents any other way.

The reason is not mysterious. Most of an agent's tokens go to rediscovery: reading around to figure out what already exists, what it is allowed to touch, and what the system looks like. Encode that once in the environment and the rediscovery disappears. The design-to-build speedup comes from the same place. When the agent does not wander toward a wrong version of the work, the first build is closer to the one you keep, and you spend far less time steering it back.

None of this needs a larger model. It needs the system to be something the agent is part of, so the smartest, fastest agent you can get points its speed at the right thing instead of the wrong one.

FAQ

What problem does harness engineering solve? It stops agents from doing the wrong thing so they can do the right thing: no duplicate of what you already have, no reinventing a solved problem, no picking a database, sandbox, or deploy target you do not run.

How much can a good harness save? In my own testing, giving the agent a system it is part of cut token usage by about 60% and roughly doubled design-to-build speed. The savings come from removing rediscovery and wrong turns, not from a bigger model.

What does an environment for the system mean? The same idea as a development environment, applied to the agent. It inherits the deployment surface, the database and how to use it, the chosen sandbox, and the solutions that already exist, because those are part of the system rather than facts it rediscovers.

Why do smarter agents make this harder? They make more decisions faster. Every decision made without knowing your system is a chance to go the wrong way, and no human can review at that speed. The faster the agent, the more the missing context costs.