Harness engineering: why the model is only half the system
Loading...
Loading...
Join JS Mastery Pro to apply what you learned today through real-world builds, weekly challenges, and a community of developers working toward the same goal.
Two developers use the exact same AI model on the same kind of task. One gets clean, working changes that fit their project. The other gets confident code that misses the point and quietly breaks things. Same model. Roughly the same prompt. Completely different results.
The usual explanation is that one of them is better at prompting. Sometimes. But the bigger reason is something most people never think about, because it stays invisible until someone names it. The model is only half of what you're actually using. The other half is the harness, and unlike the model, the harness is yours to build.
This is the idea quietly reorganizing how serious teams work with AI in 2026, and it has a name now: harness engineering. It's worth understanding properly, because once you see it, "which model should I use" stops being the interesting question.
Start with the cleanest definition going around, popularized by LangChain and sharpened over 2026: an agent is a model plus a harness.
The model is the raw intelligence. It predicts, reasons, writes. On its own, that's all it does. It can't see your files, run your code, remember what happened yesterday, or check whether its own answer was right. A raw model is pure capability with no way to act on anything.
The harness is everything else. It's every piece of code, configuration, and setup around the model that isn't the model itself. The tools it's allowed to use. The context it's given to work from. The environment it runs in. The checks on its output. The rules about when to stop and ask. The harness is what turns raw intelligence into work you can actually use.
The word is well chosen. A harness, in the old sense, is the gear that connects a powerful animal to a task. The horse supplies the strength. The harness is what turns that strength into a straight furrow instead of a field full of hoofprints. A stronger horse pulling in no particular direction doesn't plow a better field. Same here. A better model with a poor harness is power with nowhere to go.
Mitchell Hashimoto, who built Terraform, put the term into wide circulation in early 2026, and within weeks it had a research literature and a name for a whole discipline. It caught on fast because it named something people were already feeling: the model had stopped being the thing holding them back. The harness was.
It helps to see harness engineering as the third step in a progression, because you've probably already lived the first two.
First came prompt engineering. The unit of work was a single message. You learned to phrase the request well, give examples, structure the ask. It operates on one exchange.
Then came context engineering. The realization that what the model can see matters more than how you phrase the question. You started managing what went into the window: the right files, the right background, nothing stale. It operates on what the model knows at the moment it answers.
Now comes harness engineering. The unit of work isn't one message or one window. It's the whole environment the agent operates in, across an entire task, from the moment it starts to the moment the work is verified and done. It's the biggest surface of the three, and in 2026 it's where most of the real engineering effort has gone.
Each phase didn't replace the last. It wrapped it. Prompts live inside context, and context lives inside the harness.
This is the useful part, because these are the pieces you get to design. A coding agent's harness is roughly made of five things.
Its tools. What the agent can actually do, beyond talking. Read and write files. Run commands. Execute the tests. Search the web. Call other systems. A model that can only produce text is giving you suggestions. A model that can run your test suite and read the failure is doing work. The set of tools you give it sets the ceiling on what it can accomplish.
Its context. What the agent knows about your specific situation before it starts: your project's structure, its rules, the decisions already made. The same model with your real constraints in front of it reasons from your world. Without them, it reasons from the average of everything it ever read, which is rarely your world.
Its feedback. How the agent finds out whether its work is any good. Can it run the thing and see the error? Does a check run against it? A harness with a real feedback loop lets the agent catch and fix its own mistakes before they reach you. A harness without one hands you a first draft and calls it finished.
Its constraints. The boundaries and the stop conditions. What the agent is not allowed to touch. When it should pause and ask a human instead of guessing. Good constraints are what let you safely give an agent more freedom, because you've defined the edges it won't cross.
Its orchestration. How the work is structured. Does one agent do everything in a single pass, or does the work move through stages: plan, build, check, review? Do you bring in a second agent, with fresh context, to review the first? Orchestration is the difference between one confident attempt and a process that catches its own errors.
None of these is the model. All of them are things you decide.
Make it concrete. Picture the same model, used two ways.
In the first, you describe a task in a chat window. The model writes code. You copy it into your project, read it over, run it yourself, find the problem, paste the error back, get a revision, and repeat. The model is smart, but the harness is almost nothing: no access to your code, no ability to run anything, no memory of your project, no checks. You are the tools, the context, the feedback loop, and the orchestration, all by hand.
In the second, the same model runs inside a real harness. It reads your actual files and runs your actual tests. It starts with your project's rules already in context. When it writes something, it runs it, sees what breaks, and fixes it before showing you. When it hits a decision you haven't made, it stops and asks instead of guessing. When it's finished, a second pass reviews the work with fresh context.
Same intelligence both times. The second produces verified work that fits your project. The first produces a confident guess you have to babysit. The gap between them was never the model. It's everything built around it.
Here's the part worth holding onto. You don't control the model. You get whatever the labs release, the same one available to everyone else. If results depended only on the model, there'd be no edge to find and nothing to learn.
But the model is only half of it, and the other half is entirely yours. The tools, the context, the feedback, the constraints, the orchestration: every one of those is a decision you make and can get better at. That's where the skill lives now, and it's why two people with the same model get such different results. One is just using the model. The other built a harness around it.
It also means you aren't stuck waiting for the next model to get more out of AI. The research consensus of 2026 is blunt about this: better models alone aren't enough, and the harness has become the real bottleneck. The upside is that the biggest difference in your results comes from the part already in your hands.
A coding workflow, the good kind, is a harness. When you give an agent a set of skills it can run, a file of your project's real rules to work from, a way to verify its own output, clear points where it stops and checks with you, and a sequence that moves work from plan to build to review, you are doing harness engineering, whether you call it that or not.
That's what we teach in the Agentic Engineering course: not which model to pick, but how to build the harness around it. The tools, the context, the checks, the stop conditions, the sequence. And because a harness wraps the model rather than depending on a particular one, what you build keeps working across models, on whatever you use now and whatever ships next.
The model is the half you wait for. The harness is the half you build. That's the half that was always yours to get right.
