Skip to main content

Harness Engineering

The code wrapped around an AI model is just as important as the model itself. And soon, that code will write itself.

What Is a Harness?​

When you hear "Claude Opus 4.6" or "GPT-5.4," you are hearing about model weights: the raw intelligence that comes out of a massive pre-training run. Model weights are very good at predicting the next word in a sequence. That is really all they do.

They become extraordinary when you wrap them in a harness: the traditional code that tells the model how to operate. A harness gives the model the ability to store memories, search through text, write code, execute code, read files, access tools, and so much more. The harness is what makes things like Claude Code, Cursor, Windsurf, and other agentic coding tools so powerful. When you type a prompt and it runs for hours on end, autonomously reading files, writing code, running tests, that is all because of the harness.

Think of it like a car. The model weights are the engine. The harness is everything else: the steering wheel, the seats, the transmission, the tires. The engine alone does not get you anywhere. The harness is what turns raw intelligence into useful work.

Why This Matters​

Research from Stanford, MIT, and Krafton (MetaHarness paper, March 2026) demonstrated that changing the harness around the same model can produce a 6x performance gap on the same benchmark. Same engine, wildly different results, based entirely on how the code around the model is written.

This is why two people can use the exact same AI model and get completely different outcomes. One person is using the model through a chatbot interface (minimal harness). The other is using it through Claude Code with a workspace full of context files, skill files, and tool access (rich harness). The model is identical. The harness is not.

Claude Code Is a Harness​

This is an important framing for anyone going through the Minimum Viable Jarvis tutorial. Claude Code is not magic. It is a harness: a well-engineered wrapper around Anthropic's Claude model that gives it file system access, terminal execution, tool calling, and persistent context within a session.

It is currently the best harness for the MVJ workflow. But it is not the only harness, and it will not be the best forever. Other harnesses exist today (Cursor, Windsurf, Aider, and many others), and new ones are being built constantly. The MVJ architecture is designed so that your files are portable across any harness. Your user/USER.md, your people/ directory, your artifacts/, your skills/ are all plain markdown. Any harness that can read files can use them.

Self-Improving Harnesses​

Here is where it gets wild. Traditionally, harnesses are written by hand by human engineers. They are tested, iterated on, and improved over time, but a human is always the one deciding what to change.

The MetaHarness project demonstrated that harnesses can improve themselves. The system works by:

  1. Starting with a harness
  2. Testing it against a benchmark
  3. Letting an AI coding agent (itself wrapped in a harness) analyze the results, propose changes, and generate a new version of the harness
  4. Testing the new version
  5. Repeating

The AI decides what to inspect, what to change, and whether to make a small tweak or a major rewrite. It has access to the full history of every previous harness version, including source code, scores, and execution traces. It retrieves what it needs rather than trying to fit everything into a single prompt.

The results: MetaHarness outperformed human-written harnesses on text classification, mathematical reasoning (IMO-level problems), and agentic terminal tasks (TerminalBench). On terminal tasks specifically, the self-evolved harness scored higher than every hand-built harness except one, and it was never explicitly designed for that task.

The Bitter Lesson Connection​

This connects to a foundational idea in AI research called "the bitter lesson" (Richard Sutton, 2019): hand-written rules and human-designed heuristics never beat systems that learn those patterns on their own, given enough compute.

The most prominent example is Tesla's Full Self-Driving. For years, it used a combination of neural networks and hand-written code ("if you see a stop sign, stop"). Eventually, Tesla replaced everything with end-to-end neural networks and performance improved dramatically. The AI figured out the heuristics itself.

The same principle is now applying to harnesses. Letting AI figure out how to build its own harness produces better results than having humans write it. And as the underlying models get better, the harnesses they build get better, which makes the models more effective, which makes the harnesses even better. It is a recursive improvement loop.

The Body as Harness​

There is an older, more intuitive way to understand this concept. Consider the human body.

Your mind is capable of extraordinary things. But it operates through a body that constrains it: you can only be in one place, you need sleep, your senses have limited bandwidth. These constraints are not limitations. They are the architecture that makes focused thought possible. Remove them and you do not get a more powerful mind. You get an unfocused one.

The body channels the mind. Pain redirects attention. Fatigue forces rest. Physical presence creates the conditions for connection. The constraints are what make human intelligence productive rather than diffuse.

A harness does the same thing for a model. The model has extraordinary capability. The harness constrains it (permissions, budgets, tool limits), channels it (context assembly, skill files, memory), and enables it (file access, code execution, web search). Without the harness, the model is raw intelligence with no way to act. With the right harness, it becomes a system that does useful work in the world.

The Permission Surface article explores this further: why reducing what an agent can do often improves what it actually produces.

What This Means for You​

If you are building a Minimum Viable Jarvis, you are already doing harness engineering. Your CLAUDE.md file is harness configuration. Your skill files are harness instructions. Your folder structure is harness architecture. You are telling the model what to store, what to retrieve, and how to present information back to you.

Today, you are writing this by hand (with the agent's help). In the near future, your Jarvis will propose improvements to its own harness: better skill files, better routing logic, better ways to organize and retrieve your context. The agent will ask you, "I noticed I keep losing track of your client priorities. Can I restructure the artifacts folder to fix this?" And you will say yes, and it will improve itself.

All software will be self-evolving software. The question is not whether this happens. The question is whether you have your files in a system that can take advantage of it when it does.

Further Reading​