How Code Agents Are Built: Harness Engineering Explained

1. What Triggered the Discussion: A Source Map Exposure

Recently, an industry discussion focused on a leading AI coding agent after a packaging configuration oversight caused front-end assets with source maps to be published. As a result, the agent’s client-side readable code could be fully reconstructed.

The discussion quickly shifted from curiosity to technical analysis, especially because this agent is often regarded as one of the most engineering-mature coding agents currently available.

One important clarification is needed first: what was reconstructed was the client shell of the agent, not the underlying large model itself.

Some readers may wonder why client code matters. The answer lies in a key point: the capabilities of an intelligent coding agent are never the result of a model working alone. They come from the combination of the model and its surrounding engineering system. Understanding that shell is often more valuable than debating which model is stronger.

2. What Makes Up a Coding Agent?

To understand harness engineering, it is first necessary to understand the full form of a coding agent. At minimum, it includes several layers:

• Foundation model: responsible for understanding natural language instructions, reasoning about code logic, and generating code snippets. This is the “engine.”
• Toolset: atomic capabilities such as reading files, writing files, executing commands, retrieving code from a repository, and running tests.
• Agent main loop: the scheduling center that drives the model to repeatedly “think, act, and observe.”
• Context and memory management: determines what information the model should see at each step.
• Constraint and permission layer: defines what the model can and cannot do.

The model is only one part. What truly determines whether an agent is useful is the entire engineering system built around the model.

3. What Is Harness Engineering?

“Harness engineering” is a term that has recently gained attention in technical circles. It may sound abstract, but its essence is simple: it brings a practical reality to the surface.

Rather than hoping that a large model becomes smarter and stops producing hallucinations, it is better to put a harness on this “wild horse.”

The word “harness” is quite precise. An untamed horse may be fast and powerful, but without reins to control its direction, it will simply run wild. Large models are similar: they are knowledgeable, fluent, and fast, but they may also make things up, drift away from the goal, or lose direction during long tasks.

Harness engineering aims to constrain model behavior in a systematic way, define a track for it, and help it deliver results reliably and predictably.

It is worth emphasizing that harness engineering is not a replacement for prompt engineering. Instead, it contains and upgrades it. Prompt engineering focuses on how to state requests clearly. Harness engineering focuses on how to make the system stable.

4. Core Components of the Harness

So what engineering elements make up this “harness”?

1. Agent Main Loop: From One-Off Q&A to Continuous Execution

An ordinary conversational model is based on “one question, one answer.” An agent, however, is a continuous loop. Its basic rhythm can be abstracted as follows:

while not task_done:
    observation = collect current state and feedback      # Observe
    action      = model(reason + decide next step)        # Decide
    execute action and capture result                     # Act
    write result back to context

The model is not invoked once and then finished. It is repeatedly brought back into the loop: observe the result, think about strategy, and act again until the task is complete. This loop itself is the first layer of constraint against the model’s tendency to simply produce a one-time output.

2. Tool Calls: From “Being Able to Talk” to “Being Able to Do”

A model itself cannot truly read or write files, nor can it execute commands. An agent becomes capable of real work through a set of structurally defined “tools” or “functions.” The model outputs a tool call in a specific format, an external program executes the operation, and the result is returned to the model.

Tool design is a major focus of harness engineering. Several principles are usually followed:

• Atomic and semantically clear: each tool should have a single responsibility and a precise description so the model can select the right one more easily.
• Return structured results: error messages and execution states should be returned in a form the model can understand.
• Failures should be recoverable: when a tool reports an error, it should provide enough context for the model to self-correct instead of falling into an infinite loop.

3. Context Management: Putting the Right Information into a Limited Window

A model’s context window is limited, while a real codebase can easily contain hundreds of thousands of lines. Stuffing everything into the context is neither possible nor necessary. Harness engineering needs a strategy for “feeding the model the right material”:

• On-demand retrieval: load only the files, symbols, or snippets relevant to the current task into the context.
• Chunking and summarization: compress or distill very long content while preserving key information.
• Timely cleanup: remove completed or invalid information from the window so noise does not consume effective space.

The quality of context management directly determines whether an agent can remember accurately, locate information correctly, and avoid drifting in large projects.

4. Constraints and Permissions: Defining Non-Negotiable Boundaries

The stronger the capability, the more boundaries are needed. A mature agent sets guardrails before executing dangerous operations:

• Confirmation for high-risk operations: deleting files, executing irreversible commands, or modifying production configurations requires explicit authorization.
• Sandboxed execution: run code in a restricted environment to prevent damage to the host system.
• Least privilege principle: grant only the minimum access necessary to complete the current task.

This layer is not only a security requirement, but also an effective counterbalance to overly confident model behavior.

5. Why Strong Models Still Need a Harness

A common misconception is that if the foundation model is already strong enough, the surrounding engineering layer can be as thin as possible. The reality is the opposite.

• Hallucinations do not disappear because the model is strong: even a powerful model may confidently invent non-existent interfaces or function signatures.
• Long tasks accumulate deviation: in multi-step tasks, a small early mistake can be amplified by later steps.
• Determinism is a prerequisite for engineering: software engineering requires reproducible and verifiable results, not outputs that are “mostly correct.”

The value of harness engineering is precisely to use external determinism to offset the internal randomness of the model, converging a model’s strength in generation into reliable delivery.

6. Practical Guidance for Teams

If you are building or evaluating a coding agent, you can start from these directions:

1. Clarify tool boundaries first: more tools are not always better. Semantic clarity and flexible composition are more important.
2. Treat context as a scarce resource: manage the model’s attention as carefully as you would manage memory.
3. Design exit conditions and guardrails for the loop: prevent infinite loops, repetitive work, and dangerous operations.
4. Establish observability: record each step’s reasoning, actions, and results to make it easier to locate problems and continuously tune the system.
5. Treat evaluation as a first-class concern: use a stable test set to measure the real benefits of harness changes instead of relying on intuition.

7. Conclusion

The competition among intelligent coding agents may look like a competition of models, but in essence it is a competition of harnesses. The same foundation model, equipped with a well-designed harness or without one, can produce very different results. What truly creates the gap is the maturity of the surrounding engineering: the main loop, tools, context management, and constraints.

Understanding this point gives you a clearer standard whether you are building your own agent or evaluating external tools.