Every South African engineering leader we talk to right now has a version of the same story. Someone on the team one-shotted a working prototype over a weekend with a coding agent. It felt like magic. Weeks later, the same agent can't reliably get a page layout right, invents an API that doesn't exist, or quietly reintroduces a bug the team fixed three sprints ago.
Neither experience is a fair read of what coding agents can do. Both are a read of what happens when a powerful, stochastic generation process is given too little — or the wrong kind — of structure around it.
We've spent the last few weeks studying Chris Ford's upcoming O'Reilly book, Agentic Engineering at Scale (Early Release, 2026), which does the best job we've seen of naming that structure precisely. This article opens a five-part series in which we work through the book's core ideas — reverse engineering legacy estates, spec-driven development, keeping systems fit as they age, and buy-versus-build economics — and connect each one to what we're actually seeing in South African client engagements: government departments carrying decades of undocumented COBOL and Delphi, banks and insurers with core systems nobody fully understands anymore, and scale-ups trying to move fast without inheriting the technical debt of their sponsors.
We start here, with the idea the rest of the series leans on: the agent harness.
Code is cheap. Judgment isn't.
Coding agents have solved a real problem — the accidental complexity of expressing intent in code a machine can execute. What's left is the essential complexity Fred Brooks described nearly forty years ago in "No Silver Bullet": deciding, precisely enough that another system can act on it, what you actually want.
That's not a new problem. It's the same problem architects, business analysts and senior engineers have always owned. What's changed is the volume and speed at which an under-specified decision now gets turned into running code — and shipped, reviewed, or missed entirely, long before anyone catches it.
Ford's term for the discipline of closing that gap is harness engineering: the use of structured artefacts to guide what a coding agent produces, before and after it produces it. Think of it as developer experience, except the developer is the agent.
Four kinds of harness
The framework rests on two independent questions you can ask of any artefact you hand to a coding agent, or any check you run against what it produced:
- Does it describe, or does it judge? A harness can simply give the agent context (descriptive), or it can pass or fail a solution against a standard (normative).
- Does it apply before generation, or after? A harness can shape what gets generated in the first place (feedforward), or it can react to what was actually produced (feedback).
Cross those two axes and you get four categories.
Guides are descriptive and feedforward. They give an agent context before it writes anything — domain vocabulary, company background, "here's how our promotions engine thinks about a discount." A Guide doesn't say what's correct. It says what's true, or what matters.
Guards are normative and feedforward. They narrow the solution space before generation starts — an architecture decision record that says "we use Postgres for this class of workload," a schema that fixes the shape of an API response. A Guard tells the agent which parts of the possibility space are off-limits, before it starts exploring.
Checks are normative and feedback. They judge what was actually produced — a unit test, a linter, a security scan. If the check fails, the output is wrong by definition, whether or not it looks plausible.
Sensors are descriptive and feedback. They give the agent visibility into what it built, without passing judgment — a browser tool that lets an agent see the page it just rendered, an observability dashboard, a log stream. The sensor doesn't say the layout is wrong. It shows the agent what actually happened, and leaves the judgment to whatever reasoning process — human or agent — is watching.
The categorisation isn't a process diagram. It's a control-theoretic distinction: feedforward shapes generation before the fact, feedback closes the loop by observing what came out the other side. A test written before a line of code exists is still feedback, in this sense, because it judges the artefact once it exists — it just happens to have been written early.
Why "just write better prompts" doesn't scale
Most organisations we work with are, right now, somewhere on a spectrum from "no harness at all" to "an AGENTS.md file someone wrote once in March." That's not a criticism — it's exactly where the industry is. But it explains a pattern we see constantly: a coding agent performs brilliantly on a greenfield proof of concept and then degrades sharply the moment it touches a real, messy, three-year-old production system.
The agent hasn't gotten worse. The ratio of implicit, untold context to explicit, harnessed context has gotten worse, because production systems accumulate exactly the kind of tacit organisational knowledge — "we don't touch that field, finance relies on a report that reads it directly" — that lives in people's heads and nowhere an agent can reach it.
Whenever you under-specify a solution for a coding agent, the agent doesn't leave a blank. It fills the blank — with something statistically plausible, drawn from the aggregate of its training data rather than from your context. Sometimes that guess matches what you wanted. Sometimes it's what gets called a hallucination. Both are the same underlying event: output without foundation. The only real difference is whether you got lucky.
A harness is how you stop relying on luck.
Applying the four categories
In practice, a healthy agentic engineering setup uses all four, deliberately, rather than defaulting to whichever one is easiest to bolt on:
- Guides — an AGENTS.md or CLAUDE.md file, a domain glossary, architecture diagrams, a short pointer to the relevant ADRs rather than a wall of history. The test of a good Guide isn't length. It's whether the agent can find the three sentences that matter without reading the other three hundred.
- Guards — schemas, contracts, ADRs, a "constitution" of standing decisions that hold across every change. A Guard should be specific enough that you could point to a plausible-looking output and say, correctly, "no, that violates the Guard."
- Checks — your existing test suite, linters, security and dependency scanners, and — critically for legacy estates — characterisation tests that pin down what a system currently does, so a change can be judged against that baseline rather than against nothing.
- Sensors — observability, logs, traces, and increasingly, tool access that lets the agent inspect its own output directly (a browser for a web app, a query interface for a data pipeline) rather than reasoning about it blind.
The organisations getting real, durable value from coding agents aren't the ones with the cleverest prompts. They're the ones who've done the unglamorous work of building out all four categories, so the agent is operating inside a well-lit room instead of guessing in the dark.
What this means for the rest of the series
Every article in this series maps onto this framework, because Ford's later chapters are really elaborations of it applied to specific engineering problems:
- Part 2 looks at reverse engineering — building the Guides and Sensors you need before you can safely modernise a legacy estate you don't fully understand.
- Part 3 looks at spec-driven development — the discipline of building better Guards, and why natural-language prompting alone under-constrains a solution.
- Part 4 looks at keeping systems fit for purpose as their context shifts around them — using Checks and Sensors to make continuous, low-risk technical change instead of periodic, high-risk rewrites.
- Part 5 looks at what all of this does to the economics of buying versus building software, once the harness — not the code itself — becomes the thing your organisation actually maintains.
If there's one idea worth taking from this opening piece on its own, it's this: the quality of what a coding agent produces for your business is, overwhelmingly, a function of the harness you give it — not the model, and not the prompt. That's a solvable engineering problem. It's also, usually, the one nobody has budgeted time for.
How CloudNala can help
We help South African organisations build the harness before they scale the agent — auditing what context, constraints and checks already exist (usually more than teams think, scattered across wikis, Slack threads and one senior engineer's memory), and turning that into Guides, Guards, Checks and Sensors coding agents can actually use safely in your environment.
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.
Book an AI Readiness Workshop or write to us at consult@cloudnala.co.za