A capable coding model does not know your organisation. It does not know which conventions are load-bearing, which technical debt you have chosen to live with, what your architecture forbids, how much risk you will accept or what "done" means in your team. It can be told some of that. It cannot be trusted to remember or apply it without something checking.
That something is the harness. CloudNala has written about it twice already. Guides, guards, checks and sensors introduced a four-part taxonomy from Chris Ford's work: artefacts that describe or judge, applied before or after the agent generates code. Harness engineering: the workshop around the agent described the practical components: instructions, sandboxes, permissions, tests, architecture checks and review gates.
Both pieces remain useful. They tell a team which artefacts are missing. This part is about the next step: treating those artefacts as one control system rather than a checklist. Much of the vocabulary here comes from Birgitta Böckeler's article Harness engineering for coding agent users, published on martinfowler.com on 2 April 2026. We credit the framing to her and add our own synthesis and a worked example.
Seapoint Payments is fictional, and its systems and figures are illustrative. Seapoint's merchant onboarding squad has been using coding agents for three months. It has an AGENTS.md, a test suite and a code review rule. It also has a growing sense that the agents keep making the same kinds of mistake, and that the reviewers are tired.
The plain-English definition
Harness engineering is the practice of building the instructions, tools, tests, policies, architecture checks, feedback signals and approval gates that keep an AI agent working inside the system's intended boundaries.
The model supplies general capability. The harness supplies local judgement, structure and evidence. A harness has two jobs: raise the chance that the agent produces an acceptable result on the first attempt, and catch problems early enough that the agent can correct them before expensive human review or a production release.
Three layers, and the one you cannot buy
Böckeler describes the model at the centre, a builder harness around it supplied by the coding-agent product, and a user harness on the outside built by the people using the agent for their own system.
The distinction matters for ownership. The model provider improves the model. The agent product improves its own system prompt, orchestration, tool calling and sandbox. Neither can write your outer layer, because it contains your intent, your architecture, your standards and your risk appetite. Organisations sometimes wait for a better agent to fix problems that live entirely in the outer layer. A better model will not learn that Seapoint's onboarding service must never call the payments ledger directly. A dependency rule that fails the build will teach every model the same thing.
Guides before, sensors after
The control-system view starts with direction. Guides are feedforward controls: they act before the agent does, anticipating likely mistakes and making the preferred path explicit. Sensors are feedback controls: they observe what the agent produced and return evidence it can use to correct itself.
At Seapoint, guides include the onboarding specification ONB-012, two architecture decision records, AGENTS.md, a service template for new endpoints, and explicit boundaries on tools, files, network and data. Sensors include the compiler, the test suite, a linter, a secret scanner, a dependency rule check, an AI review step and, after release, production logs and service-level objectives.
Both are needed, and each fails without the other.
- Guides without sensors produce prompt-only governance. The instructions exist, but nothing checks whether they were followed.
- Sensors without guides produce feedback-only engineering. The agent makes the same preventable mistake on every task and burns time and tokens repairing it, because nothing told it the preferred approach up front.
One more practical point from Böckeler's article is worth repeating: a sensor's message is itself an input to the agent. "Test failed" invites guessing. "Payout hold expected for partial match, got release" lets the agent fix the right line. Writing failure messages for the agent to read is one of the cheapest improvements a team can make.
The cheapest reliable control first
Controls also differ by how they run. Computational controls are deterministic: types, tests, linters, schemas, structural rules, policy checks. They are fast, cheap and repeatable, but they only detect what someone has encoded. Inferential controls use a model to judge meaning: AI code review, checking a change against a specification, critiquing an architecture. They can assess things no rule captures, but they are slower, costlier and non-deterministic. Human review understands accountability and trade-offs, and is the scarcest resource of all.
The design rule follows directly. Reject deterministically whatever can be rejected deterministically. Use inferential review for questions that genuinely need judgement. Spend human attention where responsibility cannot be delegated. Each control should see fewer, better changes than the one before it.
Seapoint's first harness had this backwards. Its AI review step caught missing null checks and import-order problems that a linter would have caught in a second, and its human reviewers were spending their time on formatting comments. Moving those checks to the computational layer shortened every review and made the AI review findings worth reading.
Three things a harness must regulate
Böckeler's second useful distinction is between what a harness regulates. A team that only thinks about "code quality" usually builds one dimension well and the other two hardly at all.
Maintainability covers internal code quality: complexity, duplication, dependency hygiene, naming, test quality. It is the easiest place to start because mature tools already exist. The harder part is semantic: catching over-engineering, a misdiagnosed bug fixed by brute force, or tests that exercise code without asserting anything useful.
Architecture fitness covers whether the system keeps the characteristics it needs: dependency directions, domain boundaries, API compatibility, data ownership, performance budgets, observability requirements, security controls. This is where fitness functions live. Architecture stops being a diagram reviewed once and becomes a set of properties checked on every change.
Behaviour covers whether the system does what the business actually needs. Böckeler calls it the elephant in the room, and it is. A green test suite generated by the same agent that wrote the code does not independently prove that the intended problem was understood. Behaviour needs guides grounded in business intent (approved examples, acceptance criteria written by someone other than the agent, representative evaluation data) and, for anything that matters, a named person who accepts the result. Part 5 of this series is about that person.
The harness as a loop
Put together, the controls form a loop around each change.
- State intent. Outcome, users, constraints, assumptions and success measures.
- Provide guides. The smallest relevant specification sections, standards, architecture rules and procedures.
- Constrain execution. Scope tools, permissions, data, network, environments and irreversible actions.
- Run fast computational sensors before the change leaves the agent's loop.
- Run selective inferential sensors for semantics, architecture and specification alignment.
- Self-correct within a bounded number of attempts, then escalate.
- Apply the human gate to intent, material trade-offs and unresolved exceptions.
- Observe production: reliability, security, behaviour, cost and drift.
- Improve the harness. When a failure repeats, add or refine the guide, sensor, template or boundary that should have prevented it.
Step 9 is what makes it a control system rather than a checklist. Böckeler describes the human's role as steering by iterating on the harness, and makes the point that a good harness does not try to remove human input; it directs it to where it matters most. At Seapoint, the rule became: if the same agent mistake appears twice, the answer is not a better reminder in the next prompt. Improve the harness. The squad keeps a short harness backlog, reviewed in the same weekly session where production signals are triaged.
Harnessability: why some codebases are easier
Not every system offers the same control surface. Böckeler uses the term harnessability for how well a codebase supports being harnessed. Strong types, explicit module boundaries, stable APIs, repeatable builds, good tests, structured logs and clean deployment automation all make agent behaviour easier to guide and inspect.
The uncomfortable corollary is that legacy systems usually need a harness most and support one least. Hidden dependencies, weak tests and ambiguous ownership leave few reliable sensors. For those systems the first step is often to improve harnessability (add characterisation tests, make boundaries explicit, make the build repeatable) before increasing agent autonomy. Our piece on reverse-engineering legacy systems with coding agents covers how agents can help with exactly that preparatory work.
It also gives architects a new selection criterion: choose technologies and structures partly by how clearly they can be constrained, tested, observed and repaired.
Harness templates as a platform capability
Most organisations build a limited number of service shapes: APIs, event processors, data pipelines, web front ends, scheduled jobs. Böckeler suggests that harnesses can be bundled per shape as harness templates, possibly growing out of existing service templates. Narrowing the variety of topologies narrows what the harness has to regulate.
At Seapoint, the platform team turned its existing API service template into a harness template: project structure, dependency rules, approved libraries, a test skeleton, security checks, observability defaults and an AGENTS.md that points to all of it. A new endpoint built from the template arrives already harnessed. This is where harness engineering meets platform engineering: the platform becomes the governed environment in which agents work with bounded autonomy.
Failure modes to look for
- Prompt-only governance. Rules exist, nothing checks them.
- Feedback-only engineering. The same preventable mistake on every task.
- AI reviewing AI with no independent control. The same class of model generates and approves.
- Green tests mistaken for correct behaviour. The tests verify the implementation, not the intent.
- Contradictory controls. Skills, repository instructions and pipeline rules disagree.
- Silent sensors. A check never fails, and nobody knows whether the system is healthy or the check is weak.
- Late feedback. A pipeline or a person finds what a local check could have caught.
- Unlimited repair loops. No retry limit, no escalation rule, rising token spend.
- No harness owner. Rules drift, templates age, exceptions become permanent.
- Harness theatre. Counting tools and policies instead of measuring escaped defects, review effort and rework.
Measures that tell you it works
| Outcome | Measure |
|---|---|
| First-pass quality | Share of agent changes passing local controls before human review |
| Self-correction | Share of detected issues repaired inside the bounded agent loop |
| Review efficiency | Human review time and comments per accepted change |
| Escaped defects | Defects, security findings or boundary violations found after merge |
| Harness coverage | Critical failure modes with at least one guide and one effective sensor |
| Control usefulness | False-positive rate per sensor |
| Cost efficiency | Tokens and compute per accepted change, including failed repair loops |
| Business correctness | Acceptance failures or rework caused by misunderstood intent |
After two months of harness work, Seapoint's reviewers were leaving roughly half as many comments per accepted change, and almost all of the remainder concerned intent and trade-offs rather than style. The figure is illustrative, but the direction is the one to look for: human attention moving towards the decisions only people can make.
Our view
The competitive advantage will not come from giving every engineer the same coding model. Everyone can buy that. It will come from the environment around the model: clearer intent, stronger specifications, executable architecture, fast feedback, safe boundaries, and evidence that directs human attention to the decisions that matter. That environment is the outer harness, and only you can build it.
Next: Part 5, Agentic development still needs an acceptance authority. All parts are on the series page.
How CloudNala can help
We run harness reviews for teams already using coding agents: mapping existing guides and sensors against the three regulation dimensions, finding where expensive controls are doing cheap work, identifying repeated agent failures that should become new guides or sensors, and setting up a harness backlog with an owner. Where a platform team exists, we help turn its service templates into harness templates so new work starts inside the controls.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Plan an AI Delivery Pilot or write to us at consult@cloudnala.co.za