How AI Coding Agents Can Be Managed in a Project Context
Harness Engineering
28.07.2026
Senior Data Scientist
Context: Why Harness Engineering Is Becoming Relevant Now
Software development using AI has advanced rapidly in recent years. For a long time, traditional development took center stage: people structured tasks, decided on architecture, wrote code, and tested the results using established tools and processes. With the advent of AI assistants, new tools were introduced. They primarily provided support right where a developer was already working: through code completion, when defining individual functions, when generating small tests, or as assistance within a file.
However, this hardly changed the fundamental development workflow. Developers integrate the tools into their workflow, not the other way around. With coding agents, this could shift. They not only provide suggestions in the editor but can also track a task across multiple steps: analyzing codebases, modifying files, running tests, executing terminal commands, performing browser or UI checks, and responding to error messages. In other words: In the past, humans wrote the code and used the tools themselves. With AI assistance, they received suggestions along the way. With agent support, part of the workflow can be handed over to the agent itself.
This raises a new question: What kind of environment do coding agents need to ensure their results are produced quickly, verifiably, and reliably? This is exactly where Harness Engineering comes into play: It helps mitigate typical weaknesses of Large Language Model (LLM)-based systems, such as hallucinations or non-deterministic behavior.
Figure 1 illustrates this shift: AI assistance primarily complements existing workflows. Agent-based development goes a step further and transforms these workflows more significantly because the agent not only comments on or supplements tasks but actively executes them. This gives rise to new roles, new control points, and new requirements for architecture, quality assurance, and governance. Control points are deliberately defined stages in the process: Which tests must be run, when is a review needed, which changes can be prepared automatically, and where is human approval required? The agent remains a tool, but one that operates much closer to the actual development process than traditional assistant functions in the IDE. This is where harness engineering comes into play. If an agent is to work within a codebase, it needs clear guidelines:
- What constitutes good code in this project?
- What architectural constraints must be adhered to?
- Which tests actually deliver meaningful results?
- Which tools is the agent allowed to use—for example, file access, the terminal, test scripts, browser checks, or internal documentation?
- And at what points must a human intervene?
Harnesses and Harness Engineering
In software engineering (but also more generally for any agent-based systems), the term “harness” is best understood as a working and execution environment surrounding a large language model. An LLM can analyze language and code, recognize patterns, and generate new content. It becomes an agent when it is connected to context, tools, state, rules, and feedback loops. A simple formula sums up this idea:
Agent = LLM + Harness
LangChain, a framework for LLM applications and agents, describes an Agent Harness as the part outside the model that manages state, executes tools, enables feedback loops, and sets boundaries.1 Specifically, system prompts, tools, skills, the MCP server, access to infrastructure components such as the file system, orchestration logic, and hooks for deterministic execution are listed as components of a harness. It is important to distinguish between the harness and harness engineering. The harness is the concrete environment in which an agent operates. Harness engineering describes the work involved in this environment: it is designed, adapted to a project, integrated with tools and tests, secured by clear boundaries, and continuously improved during operation. ³
From a software developer’s perspective, this principle is not new. Good software development has never consisted solely of writing code. It has always encompassed build systems, tests, CI/CD, architectural rules, monitoring, and reviews. Harness engineering applies precisely this engineering discipline to working with AI coding agents.
Figure 2 shows how a harness can be structured around a coding model. At the center is the coding model—that is, the LLM. What matters most, however, is what is built around this model: the harness. On the left side of the figure is Guidance. It provides the agent with direction before or during its work. This includes Instructions & Rules, Docs & Context, and Tools & Scripts. It clarifies questions such as: What needs to be done? What project rules apply? What architectural decisions are relevant? And which tools is the agent allowed to use, such as test commands, search scripts, browser checks, or project-specific CLI commands? On the right side is validation. It provides feedback on the quality of the generated artifacts. These include Tests & Linters, Review Agents, Logs & Metrics, and browser or UI checks. Validation thus provides the agent with actionable feedback. It lays the foundation for an agent to independently detect errors and improve its solutions. In her blog post, Birgitta Böckeler uses the terms “Guides” and “Sensors” as fundamental abstractions of a harness. Guides are intended to control the agent’s behavior, while Sensors serve to provide it with feedback on its behavior and thus an opportunity for self-improvement.²
The lower part of the figure shows the self-correction loop. This is where a large part of the actual added value is generated: the agent performs an action, receives feedback, evaluates this feedback, and adjusts its result. Harness engineering therefore does not mean prescribing every single step to the agent. At its core, the goal is to structure the environment in such a way that this feedback loop is reliably supported. The figure also illustrates the practical implementation level. Companies rarely start from scratch. Often, a generic harness already exists, such as GitHub Copilot, Claude Code, or an agent-based development environment.
Harness engineering begins when this general harness is tailored to the specific project: through project-specific rules, appropriate tools, meaningful tests, clear permissions, and effective feedback mechanisms. The harness is then further refined and improved through day-to-day use.
1 https://www.langchain.com/blog/the-anatomy-of-an-agent-harness
2 https://martinfowler.com/articles/sensors-for-coding-agents.html
3 https://martinfowler.com/articles/harness-engineering.html
The harness exists on multiple levels
The term “harness” does not always refer to the same level. Depending on the context, the term can describe an SDK or toolkit, the specific implementation within a project, a domain-specific framework, or even the entire agent-based development system. It is therefore helpful to consider the term at multiple levels: Table 1: Levels of a Harness
| Level | Meaning |
|---|---|
| Generic Harness | The technical foundation an agent needs to function at all. This includes tool-calling interfaces, specific tools (e.g., file access, terminal, or browser), a sandbox, the execution loop, permissions, and the interaction interface. Agent-based coding tools build on this foundation and bundle the model, user interface, tool access, and work loop for code modifications. |
| Project Harness | The adaptation of the agent to a specific codebase. This includes project rules, architectural context, build and test scripts, local documentation, CI signals, review guidelines, and project-specific constraints. |
| Domain Harness | Reusable knowledge for a specific domain. This includes standards, technical terms, regulatory requirements, typical data models, quality guidelines, and industry-specific best practices. |
| Delivery Harness | The organizational and technical framework for software delivery. It encompasses the interaction between people, agents, workflows, CI/CD pipelines, quality gates, governance, observability, and release processes. An agent can not only modify code but also, for example, prepare reviews, evaluate test results, and trigger deployment processes. |
This article focuses primarily on the Project Harness level. It addresses the practical question: How do we make an agent in a specific codebase controllable, useful, and verifiable? The other levels remain important, but the most direct entry point for software developers is usually the project itself.
A practical example: A bug fix with and without a harness
To make the model in Figure 2 more tangible, let’s consider a typical case from an existing codebase. A team maintains an application that imports and validates business data. A ticket describes a bug: Certain invalid date values are not reliably rejected during import. At the same time, there is a special business rule. Some historical data from a legacy system may still be imported, even though it would actually be invalid according to today’s rules. This exception is not immediately apparent at the relevant validation point. References to this exception are scattered throughout the project documentation, in test data, old migrations, and a business constant. This refers to a named value in the code—such as ALTDATEN_STICHTAG—that centrally defines the exception, rather than repeating the same date in multiple places.
A developer wants to use a coding agent to investigate the error and prepare a fix. Even without a project-specific test harness, a modern coding agent will likely handle much of this correctly in this case. It can find relevant files, run existing tests, understand the validation logic, and generate a plausible change proposal. This is precisely why this example is relevant:
The question isn’t whether the agent can modify code in principle. What matters is whether its change meets the project’s business and technical standards. Without a project-specific harness, it lacks, above all, explicit project rules, a focused review, and clear guidance on which edge cases are actually important to the team.
With Harness, the same scenario plays out differently. The guidance first provides the implementation agent with direction. For example, the project rules state that validations are not implemented directly in the import process, but rather in a central validation layer. In the documentation, the agent finds the business rule regarding permitted date formats and intentionally tolerated legacy data. A linked search script directs them to the relevant validation classes and test data.
Another project command specifically launches the import regression tests that are relevant to this area. This allows the agent to combine their code analysis with the project knowledge relevant to this fix. The agent works within the intended architecture, takes into account the business exception for legacy data, and supplements the test where the team typically validates such rules. Validation then comes into play. The import regression tests reveal which combination of invalid dates and historical data sources is relevant. The logs from the local test run indicate which data record triggers the edge case. Additionally, a review sub-agent independently verifies the change against the project rules and architectural specifications:
- Is the logic in the correct layer?
- Is the legacy data exception expressed using the existing constant?
- Is the new edge case covered by a regression test?
In this way, the review sub-agent provides a second perspective. It checks not only whether the code runs, but also whether the change fits the project from a business and architectural standpoint. The self-correction loop closes the loop. The Implementation Agent revises its change based on the review. It uses the existing constant for the legacy data cutoff date, adds the missing test case, and reruns the relevant checks. Only when the regression tests and review results align does it submit the change as a proposal or pull request. Figure 2 also includes an Optimizing Loop. It describes a higher-level step: insights from reviews, test runs, or human approvals can flow back into the harness. For example, a specific case can lead to a clearer project rule, an additional regression test, or a more precise tool description. In this way, a single case improves the harness for similar tasks in the future. The difference, therefore, is not that the agent suddenly becomes smarter when using the harness. Rather, the agent is guided more precisely and verified more systematically.
The guidance reduces the risk of the agent working in the wrong direction. Validation reveals errors and relevant edge cases. The feedback loop ensures that the agent can correct identified problems on its own. A harness does not prevent every wrong decision. However, it makes the development process with coding agents more reliable and reduces the risk that changes, while technically functional, violate business rules or architectural requirements. Humans remain involved where responsibility, architectural decisions, or business assessments are required.
What does a software developer do in harness engineering?
For developers, this shifts part of their workload. Software development has always involved more than just writing code: architecture, testing, build systems, code reviews, and operations are all part of it. With coding agents, it becomes even more important to design an environment in which an agent can work effectively. This includes making implicit project knowledge explicit. In many teams, rules exist only in the minds of individuals, in old pull requests, or in verbal agreements. For humans, that may be sufficient. For agents, however, it’s difficult. An important part of harness engineering is therefore to document architectural principles, quality goals, and typical workflows in a way that makes them usable as guidance. This step doesn’t just help agents. When project knowledge is documented more clearly and can be found in one place, new team members, code reviews, and future maintenance also benefit. Harness Engineering thus makes visible what is important in the project anyway, but has often been passed on only informally until now.
At the same time, developers must ensure that the agent receives reliable feedback. Good tests, clear build scripts, understandable error messages, logs, metrics, and automated reviews are not minor issues here. They play a decisive role in determining whether an agent can review and improve its work. Equally important is controlling the agent’s scope of action. Not every agent should be allowed to modify every file, run every tool, or start every pipeline. Harness engineering therefore also involves clearly defining permissions, sandboxes, approvals, and escalation points. The agent should be able to work productively, but not without oversight. It becomes clear: Harness engineering does not replace software development.
Many of these practices have long existed. In the context of agents, however, they become more important and more visible. Teams with well-defined architectural boundaries, robust tests, clear documentation, and functioning toolchains can deploy agents far more effectively than teams where critical project knowledge is primarily shared informally.
Quality, Safety, and Governance
Harness engineering isn't just about productivity. It's just as much about quality, security, and governance.
As soon as an agent can modify code, run tools, or interact with external systems, new risks arise. Even a highly capable coding agent can suggest a change that makes sense locally but doesn’t fit neatly with the architecture, domain model, or approval process. For example, it might technically correctly extend a validation rule but, in doing so, model a business exception in the wrong place or bypass existing review conventions. It might modify too many files or inadvertently place information in a context where it doesn’t belong. Such risks cannot be controlled by better prompts alone.
Whenever possible, deterministic checks should take precedence. Tests, linters, type checkers, architectural reviews, and security scanners often provide more reliable results than a purely linguistic evaluation. LLM-based reviews can be a useful supplement but should not be the sole arbiter of quality.
In the context of the Codex, OpenAI explains that coding agents can better verify whether changes actually work by accessing logs, metrics, and traces.⁴ Anthropic describes, among other things, harness designs with planner, generator, and evaluator roles for long-running development tasks.⁵ Both examples illustrate the same fundamental principle: The more autonomously an agent operates, the more important the technical environment becomes that guides, monitors, and constrains it.
4 https://openai.com/index/harness-engineering/
5 https://www.anthropic.com/engineering/harness-design-long-running-apps
Continuous Improvement of the Harness
A harness isn't a setup you configure once and then forget about. It continues to evolve alongside the project, the team, and the agents being used. In practice, harness engineering often begins with specific errors.
Is an agent ignoring an architectural rule? Then perhaps that rule is missing or is worded too vaguely. Is an agent implementing a fix that violates existing edge cases? Then there may be a missing test to provide feedback.
Is an agent using a tool incorrectly? Then perhaps the tool description is unclear, or the permissions are too broad. The goal isn’t to correct every error individually by hand.
What’s more important is to trace recurring errors back to the harness. A manual correction then becomes, for example, a clearer rule, a new test, a script, better logs, a more understandable tool description, or an additional approval step. Over time, this makes the harness more concrete. Recurring errors are not merely corrected individually but are translated into rules, tests, tool descriptions, or approval points. A good harness, therefore, does not consist of as much text as possible. What matters is whether context, tools, validation, and boundaries interact in such a way that the agent can operate reliably.
Conclusion: Leverage is the result of engineering
AI coding agents open up new possibilities in software development. They can prepare tasks, modify code, add tests, update documentation, and respond to feedback. However, how well this works does not depend solely on the underlying model. Harness engineering becomes relevant for developers and teams as soon as agents are expected to work in a traceable and reliable manner within the context of a specific project. Speed alone is not enough. Teams must define the context an agent receives, the tools it is allowed to use, how its results are verified, and at which points a human must make a decision. A harness links the agent’s work to project knowledge, technical checks, and responsibilities. This makes it easier to control the basis on which the agent operates, the rules it follows, and how errors are detected and corrected. For companies, therefore, it is not only crucial which model or tool they use. Equally important is the working environment in which this model is deployed. Only this environment determines whether an agent merely generates code quickly or delivers changes that are implemented correctly from both a functional and technical standpoint and integrate seamlessly into existing development processes.
From HMS’s perspective, this is the practical core of Harness Engineering. AI becomes valuable in software development when speed, quality, traceability, and control are considered together.
Additional Resources
- LangChain: The Anatomy of an Agent Harness.
https://www.langchain.com/blog/the-anatomy-of-an-agent-harness - Birgitta Böckeler / Thoughtworks: Maintainability sensors for coding agents.
https://martinfowler.com/articles/sensors-for-coding-agents.html - Birgitta Böckeler / Thoughtworks: Harness engineering for coding agent users.
https://martinfowler.com/articles/harness-engineering.html - OpenAI: Harness Engineering: Codex in an Agent-Centric World.
https://openai.c om/de-DE/index/harness-engineering/ - Anthropic: Harness design for long-running application development.
https://www.anthro pic.com/engineering/harness-design-long-running-apps
