AI Build Harness

The problem behind faster builds

Coding agents can produce changes quickly. The harder question is how an organisation decides those changes are acceptable, especially when review inherits the assumptions of the agent that produced them.

I am developing a build harness that gives implementation and independent challenge different responsibilities. The owner defines the work and its boundaries; agents work within them; acceptance depends on explicit criteria and reviewable evidence.

The approach

The prototype uses bounded tasks, controlled handoffs, recorded defects and targeted correction rounds. Accepted work should not be repeatedly reopened without a reason, but relevant regressions still need to be checked.

The broader design keeps durable state in governed artefacts rather than relying on an agent’s memory. Proposed learning, reusable procedures and changes to the operating rules need their own review before they influence later work.

Cost is part of reliability

A cheap response is not necessarily a cheap result. The meaningful cost includes repeated context, correction, review and the owner’s time resolving failures.

I want to assess the cost of an accepted change alongside the quality of its assurance. That means measuring where additional reasoning closes defects and where it merely repeats work. An unresolved requirement should become an explicit decision for the owner, rather than another round of implementation.

What the prototype has taught me

This portfolio was used as an initial build-harness trial. It exposed practical questions around review independence, evidence handoff, Windows process handling and recovery from interrupted work.

That experience informs the next implementation. It is not proof of a finished autonomous delivery product. The wider architecture for learning, capability admission and optimisation remains development work; it should earn its place through testing rather than be assumed to work because it is specified.