The claim

I recently went to an event where Mai Giménez, Research Engineer at DeepMind, gave a talk on “how the people who build AI write code”. I found the talk really interesting and I hope it gets published so I can watch it again, but here I’d like to talk about one of Mai’s answers during the Q&A. Someone asked her about using harnesses, and Mai answered something along the lines of: she works with frontier models that haven’t even been released yet, and she doesn’t use any harness.

That answer, which I’m convinced makes perfect sense in Mai’s context, later turned into a hallway conversation along the lines of “did you hear? You don’t need a harness”. And that claim is the one I think makes no sense at all.

We always say that context matters in software development, and I think it’s easy to see that Mai’s context is completely different from that of most of us who use LLMs to build software. That alone should probably be enough to make my case, but I’ll try to elaborate on my point of view a bit more.

What people mean by a harness

Maybe the first thing we should do is agree on what a harness is. In this industry we sometimes use words believing there’s a single shared understanding of what they mean, and then it turns out they mean different things in each person’s head. We don’t need to go far back in time: just remember how we’ve used words like Agile, Big Data, or DevOps to realize that reaching a collective consensus isn’t exactly easy.

I’m starting to see the same thing happen with the word harness, so by the time we agree on what it means, it may not even matter anymore.

Etymology

It comes from the Old French harneis, which in the 12th century meant “equipment, gear, armor”, above all a warrior’s equipment. From there it passed into Middle English around the 13th century with that same military sense: the equipment of a soldier or knight.

Its origin before French is uncertain. The most repeated hypothesis is that it comes from Old Norse, from a reconstructed form hernest, from herr (“army”) plus nest (“provisions”), that is, something like “provisions for the army”. Another proposal links it to Celtic languages such as Breton, and the Welsh root haearn (“iron”) is sometimes mentioned. Etymological dictionaries don’t settle confidently on any of them.

The sense of “a horse’s tack” appears shortly after, around 1300, and took hold because a knight’s equipment included the gear for his mount. That’s where expressions like “in harness” (on duty, working) come from and, much later, the technical uses, such as the wiring harness (the cabling of a vehicle or a piece of equipment).

Origin in software

The word “harness” applied to software development wasn’t coined with the arrival of LLMs; it started with testing. Although we now talk about “harness engineering”, the term “test harness” was coined many years ago. As often happens with these things, it isn’t clear who coined it, but the first written record seems to be in Glenford Myers’ book The Art of Software Testing. Although the third edition is from 2012, the first edition dates back to 1979.

In this book, Myers says “Developers collaborate with testers to build test harnesses that can test functionality automatically”.

According to Wikipedia, a test harness is the set of scripts, stubs, drivers, and infrastructure that runs tests in a controlled and observable way. The metaphor comes from a horse’s harness: something that connects and controls.

Origin in modern AI

The term harness engineering shows up in February 2026. Some sources attribute it to Mitchell Hashimoto, creator of Terraform, for his post My AI Adoption Journey, and others to Viv Trivedy for his post Improving Deep Agents with Harness Engineering. I have no idea who coined the term and, honestly, I don’t care; it’s quite possibly neither of them 😅

Either way, over the following months there was a stream of posts about harness engineering, making the ones about prompt engineering and context engineering look dated. Some of the most relevant:

Meaning

Personally, I like to go for the simple option, so I’ll stick with Vivek Trivedy’s definition:

Agent = Model + Harness

If you’re not the model, you’re the harness.

A harness is every piece of code, configuration, and execution logic that isn’t the model itself.

Part of the confusion

In the Birgitta Böckeler post I linked above, she borrows DDD terminology and explains that the term “harness” means different things depending on the bounded context.

If we’re talking about a coding agent, the harness is the one provided by the agent’s vendor (Claude Code, Codex, etc.). It’s made up of the system prompt, the tools exposed to the LLM, and anything else made available to the LLM to tackle the tasks it’s given.

From the user’s point of view, their harness is made up of the prompts, tools, hooks, and any other mechanisms that try to shape the agent’s behavior.

It isn’t about applying one or the other; it’s more like adding layers to an onion. If we want to make things a bit more complicated, we could say that in a product like Claude Code:

Coding Agent = LLM + Claude Code harness + User harness

What you get without one

I assume that when Mai was asked about harnesses, she understood it as the “user harness”, but that’s just a guess. Maybe she gives the word a different meaning; I don’t know.

If we buy Vivek Trivedy’s definition, without a harness all we have is an LLM, so we’d be very limited, because the LLM wouldn’t even have any tools to call.

If we assume we’re talking about the “user harness”, what we get is the coding agent’s “vanilla” behavior. Even then, keep in mind that this behavior depends on the model we’re using. And the same is true the other way around: using Opus 5.5 with Claude Code, GitHub Copilot, or OpenCode will give different results because, even though we’re using the same model, we’re changing the harness, and that means at the very least a different system prompt and different tools.

What Mai was probably getting at is something like Rich Sutton’s bitter lesson (2019) applied to agents: in the long run, general methods that scale with compute beat human knowledge built in by hand.

And in Mai’s context, working with versions of frontier models that aren’t even available to the general public, it makes perfect sense.

There are recent references that discuss this:

When we don’t need a harness

Harness design for long-running application development says that “every component in a harness encodes an assumption about what the model can’t do on its own, and those assumptions are worth stress testing, both because they may be incorrect, and because they can quickly go stale as models improve”. This applies as models gain new capabilities, as long as we’re talking about “public knowledge”. For example, with less capable models you had to rely on skills or prompts telling the model how to apply good engineering practices, how to use some open source tools, and so on. Over time, new models pick up those capabilities, so including them in the harness becomes unnecessary. It can even become counterproductive in terms of performance or token economy.

So ideally we should keep the public knowledge we put into the harness to a minimum, and re-evaluate it every time new model versions come out.

When a user harness does earn its place

Private knowledge is a very different case. Whether your company stores its metrics in ClickHouse or Prometheus is something only you know, and the model will benefit enormously from having that kind of information in the harness. If your company has a policy for adopting new package versions that rules out packages less than a week old, that information is yours alone.

Any information about the workflows you follow, your development cycle, and so on, that the agent needs to work according to your policies and preferences, belongs in the harness.

The same goes for code examples. Last year I was working on a project that used a version of Blazor the models hadn’t been trained on yet. That’s to be expected, since Blazor is a niche framework and the new version had come out very recently. We had to add some code examples showing how to do things the new version’s way, because the agent kept making the same mistakes over and over. Today that part of the harness is no longer needed, because frontier models have picked up that information in their training.

Conclusion

The harness doesn’t disappear: it gets thinner. Every piece of public knowledge we add to it is a bet against the next generation of models, so it pays to build it thin and disposable. When someone says “we don’t use harnesses”, they most likely mean “we use the smallest harness possible”.

In practice, I’d sort every piece of the user harness into one of three groups:

  • Public knowledge (good practices, how to use well-known tools and frameworks): keep it to a minimum and question it with every new model. Try removing it and see whether the results get worse.
  • Private knowledge (your stack, your policies, your workflows, your conventions): this is where the harness earns its place. No model will learn it in training, so it stays until it stops being true.
  • Feedback and guardrails (tests, linters, hooks, permissions): they don’t go stale as models improve, because they don’t compensate for what the model doesn’t know; they verify what it does.

And whatever you decide, don’t decide it from a hallway conversation. Measure it with your own tasks and your own models.