Harness engineering for coding agents

The harness is everything around the model in a coding agent. It covers the rules files, skills, hooks, sub-agents, MCP servers, codebase search and the way the prompt gets built. When an agent gets something wrong, I look at the harness before I blame the model.

Three pieces shaped how I think about this. Cole Medin's talk Harness Engineering: What Separates Top Agentic Engineers Right Now breaks the harness into parts. Google's whitepaper "The New SDLC with Vibe Coding" gives it a formula: agent = model + harness. Simon Willison's guide to agentic engineering patterns collects the working habits around it.

Fix the failure in the harness

Cole calls this system evolution. Every agent mistake is a chance to improve the harness:

If the agent does not know a convention, add it to the rules file.
If it runs a destructive command, add a pre-tool hook that blocks it.
If it ignores the code style, add a lint gate that checks it in code.

The Google paper makes the same argument with numbers from other teams. It reports one team moving its agent from outside the Top 30 to the Top 5 on Terminal Bench 2.0 by changing only the harness. It also reports LangChain gaining 13.7 points by changing the system prompt, tools and middleware around a fixed model.

A fix in the harness stays fixed. A better prompt in a chat session is gone when the window closes.

One rule in my CLAUDE.md came from this. An agent shipped a static export with missing pages, because the build succeeded but the output was incomplete. The rule now tells agents to check the output after a build. My quality gates also run lint, typecheck and a build check before any pull request opens.

Two levels of harness

Cole splits harness engineering into two levels.

The first level is a single session. You pick the coding agent, such as Claude Code, Codex or OpenCode, and build the layer around it yourself. This is where agent skills and sub-agents live.

The second level joins several sessions into one workflow. A single session handed a large plan gets overwhelmed. Split the work into focused tasks instead, and pass a handoff document from one session to the next. Each session keeps a small context and a clear scope. I describe the loops I run this way in how I build software with agent loops.

Decide what context loads when

The paper traces a move from prompt engineering to context engineering. I felt that move myself. In early 2025 I worried about how to phrase instructions. By early 2026 I worried about what the agent needs to know before it starts.

The paper lists six kinds of context an agent needs: instructions, knowledge, memory, examples, tools and guardrails. Each one is either static, always loaded, or dynamic, loaded when needed. Too much static context wastes tokens and buries the important rules. Too little and the agent forgets them. The paper treats this split as an architecture decision, reviewed and versioned like other configuration. I agree.

Skills are how I handle the dynamic side. A skill is a markdown file with the steps for one task, and the agent loads it only when the task needs it.

Those six kinds also make a checklist for a failure. When an agent gets something wrong, ask which one was missing or wrong.

Conductor or orchestrator

The paper describes two ways of working with an agent. In conductor mode you watch the agent in real time and correct it as it goes. In orchestrator mode you hand over a goal and review the result later.

I was using orchestrator mode for tasks that needed a conductor, because it felt more advanced. That was a mistake. Complex logic, unfamiliar code or vague requirements go faster when I can correct the agent as it works. A well-specified task with clear acceptance criteria can be handed over and run alongside other work.

Willison suggests asynchronous cloud agents for background work, such as Gemini Jules, Codex on the web or Claude Code on the web. I run the CLIs myself in Herdr, on a server I can leave running, so I can check on a handed-over task without being at my laptop.

Read the code before anyone else does

The paper describes the 80% problem. An agent gets about 80% of a feature right quickly. The rest needs context the model does not have, and the errors there are wrong assumptions about business logic and missed edge cases. I treat the agent's output as a first draft and spend my attention on those parts.

Willison's main anti-pattern is opening a pull request full of code you have not read. That hands your review to someone else. I think the same bar applies with no collaborators. If I cannot explain a change, I should not merge it. Asking for a pull request description that says what changed, what was tested and what the risks are makes me do that review.

Keep what works

Willison's advice is to hoard things you know how to do, so an agent can recombine them. He mostly keeps working code examples. I mostly keep process documents: skills, AGENTS.md files, prompt templates and checklists.

He also cites Dan Shipper and Kieran Klaassen's compound engineering, where every project ends by writing down what worked so the next agent run starts better. That is the same habit as fixing a failure in a skill file and letting the next run inherit it.

The guide is light on automated checks. I want the agent to clear lint, typecheck and a build before the pull request opens, so I am not guessing whether the output got better.

What I wanted to add

After reading these, I listed the gaps in my own setup:

Review the harness before a new project starts: which tools the agent has, which guardrails exist and what happens when the first attempt fails.
Have an agent run the app in a browser and take screenshots, which Willison calls agentic manual testing.
Ask a second agent for a walkthrough of how a change works, to make review faster.
End each project with a short retrospective that updates the agent instructions.

The paper ends by saying that generating code is solved, and that checking it, judging it and setting its direction are the work now. The harness is where I put that work.