From Code Review to Harness Governance

Human oversight scales when teams govern the agent workflow, not every line an agent writes.

This essay responds to the original article.

The shift is from review volume to system design

Kief Morris frames AI-assisted delivery as a set of nested loops. People can leave agents to execute, inspect individual changes, or shape the conditions under which work happens. That last role matters most when teams want speed without abandoning accountability.

The useful question is not whether a person should approve every generated line. It is whether the delivery system makes errors visible, costly decisions deliberate, and routine work easy to verify. A harness is that system: the specifications, repository guidance, tools, tests, policy checks, and feedback paths that constrain an agent before a human has to intervene.

Governance belongs in the harness

Harness governance turns an abstract concern about control into operating choices. A team can define what evidence an agent must produce, which changes require a named approver, and when a failed evaluation blocks progress. It can make the safe route the default route.

For example, a small documentation correction can move through automated checks and a lightweight review. A change affecting security, data handling, or system architecture needs stronger evidence and an explicit human decision. The difference is not trust in the model. It is the impact of being wrong and the quality of the signals available before release.

This approach also changes what a review means. A review of one patch catches one mistake. A review of a recurring failure can improve the instruction, test, or policy that allowed the failure. The second action reduces the next occurrence rather than merely repairing the last one.

Better signals make autonomy safer

Tests are a starting point, not a complete control system. A mature harness combines several kinds of evidence:

• executable acceptance checks for expected behaviour;
• static and dependency checks for known technical risks;
• runtime signals that reveal degraded performance or unexpected use;
• clear escalation rules for ambiguity, high-impact decisions, and failed checks.

The value comes from the connection between these signals. An agent should be able to see the result of its work, explain the evidence, and stop when the evidence is insufficient. A human should be able to inspect the decision trail without reconstructing an entire session from chat history.

The limits of a self-improving loop

Harnesses can create a false sense of safety when their measurements are weak. An agent can optimise for a passing test suite while missing user harm, operational cost, or a requirement the test suite never expressed. Teams also risk automation bias: a confident recommendation may receive less challenge simply because the system produced it quickly.

Ownership is another limit. No workflow configuration makes an unclear product decision clear, and no approval threshold assigns accountability by itself. Someone still owns the policy, the exceptions, and the decision to expand autonomy. That owner needs to review whether the harness measures what matters rather than only what is easy to count.

The cautious path is incremental. Start with bounded work, capture failures as improvements to instructions and checks, and widen automation only when the evidence stays reliable. The goal is not an unattended delivery machine. It is a delivery loop where people spend their attention on judgement, policy, and learning instead of repetitive inspection.