Your plan is a harness

The phrase people have landed on for the work around a coding agent is harness engineering — building the scaffolding that turns a capable model into reliable output. It's a good phrase, and it points at something real. What took us a while to notice is that a thorough, collaboratively-built plan is one of these harnesses. Not a document that leads to one — a harness in its own right.

What a harness actually is

The model is the engine, and for any given task it's roughly fixed — you get the model you get. A harness is everything you put around it to make its output trustworthy: the tools it's allowed to call, the tests it runs against, the context you feed it, the constraints you impose, the feedback it gets when it strays. Harness engineering is the recognition that most of your leverage lives out here, in the scaffolding, not in swapping one model for a slightly better one. (We've made that argument before.)

Put more precisely: harness engineering for agentic coding is the design of the systems, controls, and runtime environments that turn a raw AI model into a fully autonomous coding agent. And that autonomy has one hard prerequisite — the agent has to be handed its requirements in full detail. An agent can only run without you to the extent that everything it would otherwise stop to ask has already been decided. Every part of the harness, in the end, is in service of that: making the requirements complete and enforceable enough that the agent can carry them out on its own.

A plan does the same job

Look at what a resolved plan actually contains and it's hard to tell it apart from a harness. It says what the agent may and may not do (reject non-http(s) URLs; never overwrite a slug). It says what “done” means (these eight behaviors, and here's the one that's ambiguous). It carries the context every downstream decision has to respect (tax is charged on the discounted subtotal, in every region). Those are exactly the three things a harness supplies — constraint, acceptance, context — just written in prose instead of code.

And in the strong case it doesn't stay prose. In an earlier experiment the plan's resolved decisions became a literal executable acceptance suite — eight checks the build either passed or didn't. That's the same document, hardened one more notch into a runnable harness. But it was already doing the harness's job the moment the decisions were written down: bounding the space of outputs the agent could hand back and call finished.

You don't write a good harness in one shot

Here's the part that makes planning and harness engineering not just similar but the same practice. Nobody writes a good test harness in a single pass. You run the thing, watch where it goes wrong, tighten a constraint, add the case you didn't think of, run it again. A harness is converged on, not authored.

Iterative, collaborative planning is that convergence, moved earlier — done against the plan before it's done against the code. The agent drafts and marks what it's unsure of; you tighten the loose decisions; it comes back with follow-ups only where they're still open. Every resolved comment is one more constraint added to the harness. It's why the depth of that back-and-forth tracks so cleanly with how few problems the build comes back with: more rounds of planning is just a tighter harness, measured after the fact in the issue tracker.

A plan you converge on with the agent isn't a document that produces a harness. It is the harness, built the only way harnesses ever get good — iteratively.

A harness that travels

The other thing a real harness has to do is persist. A test suite that vanished after one run would be useless; its whole value is that it's still there for the next change, the next contributor, the next refactor. A plan has the same property and a chat does not. The reasoning behind every constraint stays on the line it applies to, so the next agent — and the next engineer — builds inside the same harness instead of quietly inventing their own. One document, one set of rules, however many hands and agents pass through it.

Closing the loop

And then you hand the plan back. The most direct thing you can do with a resolved plan is feed it to the agent as the spec it builds against — which is to say, run the agent inside the harness you just built. The tighter the plan, the tighter the harness, the more of the output that's right on the first pass. That's the whole loop, and it's why “spend more time planning” and “invest in your harness” turn out to be the same advice.

So if harness engineering is where the leverage is — and we think it is — then the highest-leverage, most general harness available to you isn't a bespoke rig of tools and scripts. It's a thorough plan, converged on with the agent that has to live inside it.