AI-assisted software development has advanced rapidly in recent years. For a long time, the traditional development model remained largely unchanged: people structured tasks, made architectural decisions, wrote code, and validated the results using established tools and processes. The emergence of AI assistants introduced new forms of support. These tools primarily helped developers within their existing workflows, for example through code completion, drafting individual functions, generating small tests, or providing assistance within a specific file.
However, the fundamental development process remained largely the same. Developers integrated the tools into their workflows, not the other way around. Coding agents could change this dynamic. Rather than simply suggesting code in an editor, they can carry out tasks across multiple steps: analysing codebases, modifying files, running tests, executing terminal commands, performing browser or UI checks, and responding to error messages.
In other words, developers previously wrote the code and operated the tools themselves. AI assistants then began providing suggestions during this process. With agent support, parts of the development workflow itself can now be delegated to an agent.
This raises a new question: What kind of environment do coding agents need to produce results quickly, reliably, and in a way that can be reviewed? This is where Harness Engineering becomes essential. It helps mitigate common weaknesses of systems based on large language models (LLMs), such as hallucinations and non-deterministic behaviour.
Figure 1: The evolution from traditional software development and AI assistance to agentic development workflows
Figure 1 illustrates this shift: AI assistance primarily enhances existing workflows. Agentic development goes one step further by changing those workflows more fundamentally. Instead of merely commenting on or supplementing tasks, the agent actively executes them.
This creates new roles, new control points, and new requirements for architecture, quality assurance, and governance. Control points are deliberately defined stages within the workflow: Which tests must be run? When is a review required? Which changes may be prepared automatically, and where is human approval necessary?
The agent remains a tool, but one that operates much closer to the actual development process than traditional assistance features within an IDE. This is where Harness Engineering comes into play. For an agent to work effectively within a codebase, it needs clear guardrails:
In software engineering, and more broadly for agentic systems in general, a harness can best be understood as the working and execution environment surrounding a large language model. An LLM can analyse language and code, identify patterns, and generate new content. It becomes an agent when it is connected to context, tools, state, rules, and feedback loops. A simple formula captures 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 defines boundaries.¹ More specifically, the system prompt, tools, skills, MCP servers, access to infrastructure components such as the file system, orchestration logic, and hooks for deterministic execution are identified as components of a harness.
It is important to distinguish between a harness and Harness Engineering. The harness is the specific environment in which an agent operates. Harness Engineering is the work involved in shaping that environment: designing it, adapting it to a project, connecting it to tools and tests, securing it through clear boundaries, and continuously improving it in operation.³
From a software developer’s perspective, this principle is not new. Good software engineering has never been limited to writing code. It has always included build systems, testing, CI/CD, architectural guidelines, monitoring, and reviews. Harness Engineering applies the same engineering discipline to working with AI coding agents.
Figure 2: A coding agent harness connects guidance, validation, and a self-correction loop around the model.
Figure 2 illustrates how a harness can be built around a coding model. At the centre is the coding model itself, namely the LLM. What matters, however, is the environment built around it: the harness.
On the left-hand side of the figure is Guidance. It provides the agent with direction before and during its work. This includes Instructions & Rules, Docs & Context, and Tools & Scripts. Guidance answers questions such as: What needs to be done? Which project rules apply? Which architectural decisions must be considered? And which tools may the agent use, such as test commands, search scripts, browser checks, or project-specific CLI commands?
On the right-hand side is Validation. It provides feedback on the quality of the generated artefacts. This includes Tests & Linters, Review Agents, Logs & Metrics, and browser or UI checks. Validation therefore gives the agent actionable feedback. It creates the basis for an agent to identify errors independently and improve its solution.
In her blog post, Birgitta Böckeler uses the terms “Guides” and “Sensors” as the fundamental abstractions of a harness. Guides are intended to steer the agent’s behaviour, while sensors provide feedback on that behaviour and enable self-improvement.²
The lower part of the figure shows the Self-Correction Loop. This is where much of the actual value is created: the agent performs an action, receives feedback, evaluates it, and adjusts its output accordingly.Harness Engineering therefore does not mean prescribing every individual step an agent must take. At its core, it is about designing the environment so that this feedback loop is supported reliably.
The figure also shows the practical implementation layer. Companies rarely start from scratch. In many cases, a generic harness is already available through tools such as GitHub Copilot, Claude Code, or an agentic development environment.
Harness Engineering begins where this generic harness is adapted to the specific project: through project-specific rules, suitable tools, meaningful tests, clearly defined permissions, and effective feedback mechanisms. From there, the harness is continuously refined and improved in 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 term “harness” does not always refer to the same level. Depending on the context, it may describe an SDK or toolkit, a specific project setup, a domain-specific framework, or even the entire agentic development system. It is therefore helpful to consider the concept across several levels.
Table 1: Harness Levels
| Level | Meaning |
|---|---|
| Generic Harness | The technical foundation an agent needs in order to operate. This includes tool-calling interfaces, specific tools such as file access, terminal access, or browser control, a sandbox, the execution loop, permissions, and the user interface. Agentic coding tools build on this foundation by combining the model, user interface, tool access, and working loop required to modify code. |
| 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, terminology, regulatory requirements, typical data models, quality guidelines, and industry-specific best practices. |
| Delivery Harness | The organisational and technical framework for software delivery. It encompasses the interaction between people, agents, workflows, CI/CD pipelines, quality gates, governance, observability, and approval processes. In this context, an agent can do more than modify code: it can also prepare reviews, evaluate test results, and initiate deployment processes. |
This article focuses primarily on the project harness level. It addresses a practical question: How can we make an agent controllable, useful, and verifiable within a specific codebase? The other levels remain important, but for software developers, the most direct starting point is usually the project itself.
To make the model shown in Figure 2 more tangible, consider a typical scenario in an existing codebase. A team operates 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, a specific business rule applies. Some historical data from a legacy system must still be accepted, even though it would be considered invalid under the current rules. This exception is not immediately visible at the relevant validation point. References to it are distributed across the project documentation, test data, previous migrations, and a business-specific constant.
This refers to a named value in the code, such as LEGACY_DATA_CUTOFF_DATE, which defines the exception centrally instead of repeating the same date in multiple places.
A developer wants to use a coding agent to investigate the issue and prepare a fix. Even without a project-specific harness, a modern coding agent would probably get many things right in this scenario. It could identify relevant files, run existing tests, trace the validation logic, and propose a plausible change. This is precisely why the example is useful:
The question is not whether the agent can modify code at all. What matters is whether its change meets the project’s business and technical standards. Without a project-specific harness, the agent primarily lacks explicit project rules, a focused review process, and clear guidance on which edge cases actually matter to the team.
With a harness in place, the same scenario unfolds differently. Guidance first provides the implementation agent with the necessary orientation. The project rules may state, for example, that validations must not be implemented directly in the import process, but in a central validation layer. The documentation provides the business rules for permitted date formats and for legacy data that is intentionally tolerated. A linked search script directs the agent to the relevant validation classes and test data.
Another project-specific command runs the import regression tests that are most relevant to this area. This allows the agent to combine its code analysis with the project knowledge required for the fix. It works within the intended architecture, takes the business exception for legacy data into account, and adds the test where the team would normally safeguard such rules.
Validation then comes into play. The import regression tests show which combination of an invalid date and a historical data source represents the relevant edge case. Logs from the local test run indicate which data record triggers it. In addition, a review sub-agent independently checks the change against the project rules and architectural guidelines:
The review sub-agent therefore adds a second perspective. It checks not only whether the code works, but also whether the change aligns with the project’s business rules and architecture.
The self-correction loop completes the process. Based on the review, the implementation agent revises its change. It uses the existing constant for the legacy-data cutoff date, adds the missing test case, and runs the relevant checks again. Only once the regression tests and review results are satisfactory does it provide the change as a proposal or pull request.
Figure 2 also includes an Optimising Loop. This represents a higher-level step: insights from reviews, test runs, or human approvals can be fed back into the harness. For example, a specific case may lead to a clearer project rule, an additional regression test, or a more precise tool description. In this way, each case can improve the harness for similar tasks in the future.
The difference is therefore not that the agent suddenly becomes more intelligent with a harness. It is guided more deliberately and validated more systematically.
Guidance reduces the risk of the agent moving in the wrong direction. Validation makes errors and relevant edge cases visible. The feedback loop enables the agent to correct identified issues independently.
A harness cannot prevent every incorrect decision. However, it makes development with coding agents more reliable and reduces the risk of changes that work technically but violate business rules or architectural requirements. Human involvement remains essential wherever responsibility, architectural decisions, or business judgement are required.
For developers, this shifts part of the work. Software development has always involved more than writing code: architecture, testing, build systems, reviews, and operations have long been part of the discipline. With coding agents, it also becomes essential to design the environment in which an agent can work effectively.
This includes making implicit project knowledge visible. In many teams, important rules exist only in the minds of individual colleagues, in old pull requests, or in verbal agreements. That may be sufficient for people, but it is difficult for agents to work with. A key part of Harness Engineering is therefore documenting architectural principles, quality objectives, and common working practices in a way that makes them usable as guidance.
This step benefits more than just agents. When project knowledge is documented clearly and can be found in one place, new team members, reviewers, and future maintainers benefit as well. Harness Engineering makes visible what is already important within a project but has often been passed on only informally.
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 secondary concerns. They largely determine whether an agent can evaluate and improve its own work.
Controlling the agent’s scope of action is equally important. Not every agent should be allowed to modify every file, execute every tool, or trigger every pipeline. Harness Engineering therefore also involves defining permissions, sandboxes, approval processes, and escalation points. The agent should be able to work productively, but not without control.
Harness Engineering does not replace software development. Many of the relevant practices already exist. In an agentic context, however, they become more important and more visible. Teams with clear architectural boundaries, strong tests, accessible documentation, and reliable toolchains are significantly better positioned to use coding agents than teams where essential project knowledge remains largely informal and fragmented.
Harness Engineering is not only about productivity. It is equally concerned with quality, security, and governance.
As soon as an agent can modify code, execute tools, or interact with external systems, new risks emerge. Even a highly capable coding agent may propose a change that appears reasonable in isolation but does not align with the project’s architecture, domain model, or approval process. For example, it may extend a validation rule correctly from a technical perspective while implementing a business exception in the wrong layer or bypassing established review conventions. It may modify too many files or unintentionally introduce information into a context where it does not belong. These risks cannot be controlled through better prompts alone.
Wherever possible, deterministic checks should take priority. Tests, linters, type checkers, architecture checks, and security scanners often provide more reliable results than purely language-based assessments. LLM-based reviews can be a valuable addition, but they should not serve as the only quality control mechanism.
In the context of Codex, OpenAI explains that giving coding agents access to logs, metrics, and traces helps them verify whether changes actually work.⁴ Anthropic describes harness designs for long-running development tasks that include planner, generator, and evaluator roles.⁵ Both examples reflect the same principle: the more autonomously an agent operates, the more important the technical environment becomes in guiding, validating, and constraining its actions.
A harness is not something that is set up once and then forgotten. It evolves with the project, the team, and the agents being used. In practice, Harness Engineering often starts with specific failures.
Does an agent ignore an architectural rule? The rule may be missing or defined too vaguely. Does an agent produce a fix that breaks existing edge cases? A suitable test may be missing from the feedback loop.
Does an agent use a tool incorrectly? The tool description may be unclear, or its permissions may be too broad. The goal is not to correct every error manually.
What matters more is feeding recurring issues back into the harness. A manual correction can then become a clearer rule, a new test, a script, better logging, a more precise tool description, or an additional approval point.
Over time, the harness becomes more specific. Recurring mistakes are no longer corrected individually but translated into rules, tests, tool descriptions, or approval mechanisms. A good harness is therefore not defined by the amount of text it contains. What matters is whether context, tools, validation, and boundaries work together in a way that enables the agent to operate reliably.
4 https://openai.com/index/harness-engineering/
5 https://www.anthropic.com/engineering/harness-design-long-running-apps
AI coding agents create new opportunities in software development. They can prepare tasks, modify code, add tests, update documentation, and respond to feedback. However, their effectiveness does not depend on the underlying model alone.
Harness Engineering becomes relevant for developers and teams as soon as agents are expected to work transparently and reliably within the context of a specific project. Speed alone is not enough. Teams need to define which context an agent receives, which tools it may use, how its outputs are validated, and where human decisions are required.
A harness connects the agent’s work with project knowledge, technical checks, and clearly defined responsibilities. This makes it easier to control the basis on which the agent operates, the rules it follows, and how errors are identified and corrected.
For companies, the decisive factor is therefore not only which model or tool they use. The working environment in which the model operates is equally important. It determines whether an agent merely generates code quickly or delivers changes that are technically sound, aligned with business requirements, and compatible with existing development processes.
From an HMS perspective, this is the practical core of Harness Engineering. AI creates real value in software development when speed, quality, traceability, and control are considered together.