The Agentic Harness: Designing Control in Software Delivery

Agentic coding tools are already in your teams’ hands, whether or not your organisation has a formal policy. The question is not whether to engage with them but how to build the harness around them: the guides that steer the agent before it acts, the sensors that catch what the guides missed, and the architecture that keeps machine-generated change from outpacing your ability to understand it.

This piece is about that practical layer. Not the hype, not the headlines. The engineering. That engineering has a name: the harness.

The Harness Is the Differentiator, Not the Model

The most important reframing for engineers who work with agentic systems is this: an agent is not just a model. It is a model plus everything built around it to shape how it operates.

That outer layer is called the harness, and it can be broken down into two categories:

The SWE-bench data makes the point clear:

That is a 22 percentage point gap without changing or retraining the model. The underlying model matters less than its surroundings. The harness is what separates teams that get reliable output from teams that do not.

Spending hours prompting the model does get you a long way. Spending hours designing the constraints and checks around it gets you even further.

Architecture for AI Readiness: Sinks, Not Pipes

Agentic coding works surprisingly well in some codebases, but creates chaos in others. The reason is almost always architectural. Architecture is the guide layer of the harness. The structure of the codebase is the first constraint the agent works within, whether you designed it that way or not.

Think of the components in your system as either pipes or sinks.

In a human-only world, teams muddle through pipeline-heavy architectures because engineers accumulate context over time. In an agentic world, that hidden complexity quickly becomes expensive. An agent has no persistent storage for its codebase across sessions. It cannot ask a colleague, check prior context or remember what caused the incident last quarter. It works from what is visible and explicit within the current context window. A pipeline-heavy codebase does not only slow down an agent. It gives it a plausible-looking surface to reason over while hiding the actual consequences of change.

Every new session starts without a solid understanding of the codebase. If tracing what a single component does requires tracking side effects through three other services, that codebase is not AI-ready. And it was probably not pleasant to work with before AI either.

What AI readiness requires in practice

The phrase “architecture is the prompt” captures this well. If your system is full of hidden dependencies, implicit side effects, leaky abstractions and tribal knowledge, the agent has no stable surface to reason over. Clean boundaries and honest interfaces allow the agent to operate safely.

AI readiness requires in practice

None of these are new principles. However, agentic coding reinforces them more aggressively than before. It penalises ambiguity. It punishes invisible coupling. It exposes weak testing and sloppy permissions. It is less a substitute for engineering discipline as it is a stress test of whether that discipline actually exists.

Verification Moves Inside the Loop

When code becomes abundant, verification becomes the scarce resource. This is where the sensor layer of the harness does its work. It is also where most teams are getting hurt right now

Sonar’s “State of Code Developer Survey 2026” found that:

The effort has not disappeared. It simply moved downstream, where it is harder to catch.

In a microservices environment, a seemingly isolated change to a single backend service can cascade by breaking downstream services or corrupting shared database schemas. An agent-assisted developer might generate five or six pull requests per day. If each one requires thirty minutes of validation in a shared staging environment, most of that developer’s day goes into managing a deployment queue, rather than building software.

If output grows faster than validation capacity, teams accumulate verification debt. That debt manifests itself in delayed releases, superficial reviews, an increasing risk of incidents, and a false sense of speed.

A practical routine before merging:

Verification now needs a broader definition than simply a passing test suite. It includes executable acceptance criteria, static analysis, dependency and secret scanning, policy gates, human approval paths, environment separation, observability, rollback readiness and production monitoring. A fast team in the AI era is not the team that generates the most code. It is the team that can validate changes quickly, repeatedly and safely.

Security: When Agents Act, the Risk Surface Changes

The security chapter is not optional. Agentic systems do not just generate text. They act. The harness has to account for this. Guides and sensors are not enough if the agent has unconstrained access to tools, environments and external systems.

Two incidents illustrate what that means in practice.

Both incidents share a pattern worth treating as a checklist. Risk compounds when three conditions overlap:

Before granting an agent broader permissions, confirm you have controls in place for all three conditions, not just one.

One more note on vendor tooling: claims about enterprise data isolation, content filtering, and vulnerable code scanning matter, but should be treated as partial mitigations, not complete coverage. Read the fine print. Certain modes have exceptions and excluded content can still leak indirectly through semantic context. Policy cannot rely on a vendor checkbox alone.

Safe Habits Inside the Development Loop

Beyond architecture and security posture, reliable AI-assisted development depends less on prompting tricks and more on a consistent process:

These habits, practised consistently, are also the foundation of a more advanced pattern. Loop engineering is the practice of writing programs that prompt agents on a schedule, with explicit goals and stopping conditions, rather than prompting them by hand. Where guides and sensors constrain one session, a loop encodes those constraints into a self-running system: a trigger starts the agent, a verifiable goal defines when it stops, and guardrails like iteration caps and cost budgets prevent it from running indefinitely. What the loop is allowed to do in your environment still requires the same architectural and security thinking as any other agent session.

What the Engineering Role Actually Looks Like Now

The engineer who creates the most value in an agentic environment is not the fastest prompt writer. It is the engineer who can define the problem clearly, decompose it cleanly, constrain the blast radius and design a trustworthy path to production.

Engineers who try to stay inside every loop become the bottleneck. The ones who learn to manage the loop without micromanaging it get the real leverage. That is not a diminishment of the role. It is an expansion of responsibility. Implementation becomes orchestration. Individual contribution scales.

For teams thinking about early-career development:

Teams will need to design deliberate paths around debugging, production reasoning, incident analysis, and system-level thinking, rather than assuming those skills emerge naturally from ticket processing.

The engineers who progress the fastest will be the ones who learn to read generated code critically, reason about architecture trade-offs and take ownership of system behaviour, not just task completion. Those same engineers will increasingly be expected to design the automated loops that run their agents, not just the sessions themselves.

The engineering role is not being automated away. It is being redefined, and not gradually. This is a structural change in where engineering value lies. The primary question is no longer how to write good code. It is how to create the conditions under which good code can be generated, verified and trusted. Judgment, architecture, and verification discipline are becoming the core of the work. That is not a smaller role. It is a more consequential one.

Summary

The goal is not bureaucracy. The goal is proportional control.

Build the harness before you expand the autonomy. Make the architecture explicit before you let the agent assume it. Verify inside the loop, not after it. Define the blast radius before the first commit.

The organisations that get this right will not be the ones running the most AI. They will be the ones whose AI-generated changes can be trusted, traced, rolled back and learned from.

Speed without that trust system is not an advantage. It is deferred risk.

At IBM iX, we see one pattern separate the teams that fully realise the benefits of agentic coding from the ones that stall: the harness came first. The engineering foundation is what makes the business outcome possible.

Share