Coding Harness

A language model like ChatGPT can only do one thing: generate text. It cannot open a file, cannot launch a program, and cannot save anything. A coding harness is an additional program that closes exactly this gap. It takes the model’s text, recognizes instructions within it such as “open this file” or “run this test,” carries that out on a real machine, and sends the result back to the model as new text. The word harness comes from English and means the device used to hitch a draft animal to a cart. The model supplies the power; the harness makes sure it actually gets somewhere.

Why the same model codes better with a good harness

In recent years it has become clear that the quality of the harness is almost as important as the quality of the model. Two companies can license the same model and still offer coding assistants of very different quality. The difference lies in which information the harness shows the model and which tools it allows it to use. On leaderboards like SWE-bench, where AI systems are supposed to fix real bugs in real programs, a better harness can shift the success rate by double-digit percentage points.

The second reason is economic. Every word the harness sends to the model costs money, because providers bill based on the amount of text processed. A project with a hundred thousand lines of code does not fit into a single request. The harness therefore has to decide which ten files are actually relevant. If it makes this selection poorly, the work becomes expensive and the answer is wrong anyway.

Third, there is the matter of safety. A model that is allowed to execute commands on a computer can also delete files or send data outside. The harness is the point at which such actions are throttled or submitted for confirmation. Without this control layer, productive use within companies would be hard to justify.

The loop of proposal, execution, and feedback

The core of every harness is a loop. First, the harness assembles the task for the model: the user’s request, a few relevant excerpts from the project, and a list of allowed tools. The model responds with a tool call, such as “read file X” or “run the tests.” The harness executes this and appends the result to the conversation. Then it queries the model again. This repeats until the task is done or a limit is reached.

Typical tools include reading and writing files, searching the project, running commands on the command line, and interacting with version control. Access to automated tests is especially valuable. They provide hard feedback that doesn’t come from the model itself: the test passes or it doesn’t. It is precisely this outside feedback that distinguishes a harness from a mere chat conversation about code.

A common misconception is that the harness is simply a particularly long prompt. The prompt, i.e., the instruction given to the model, is only one part of it. The harness is real software with error handling, permission management, budget limits, and often a sandboxed environment in which the commands run.

From Cursor to Claude Code: harnesses in practice

Well-known products that are, at their core, a coding harness are called Claude Code, OpenAI Codex, Cursor, Windsurf, or GitHub Copilot Workspace. From the outside, they look like chat windows or editors. On the inside, each one has a harness that couples a model to the project and to the command line. The models behind them often come from the same handful of providers.

In news coverage, the term usually comes up when benchmark results are being disputed. When a company announces that its model solves sixty percent of all test tasks, the question almost always follows: which harness was used to measure this? Without that information, two numbers are not comparable. The related term agent belongs here too: an agent is a model that independently carries out multiple steps — and the harness is the environment that makes those steps possible in the first place.