The Four-Gate Proof Loop for Governing AI Coding Agents

Agentic software, repository and code-intelligence engineering is the discipline of letting a coding agent read, change and maintain a real codebase using evidence anchored to one commit: exact text, parsed syntax, typed references, approximate call graphs and, when it matters, observed runtime behavior. A repository map, a passing test suite or a large diff is not proof a change is correct, safe or maintainable. What should be funded and measured is accepted, maintainable work verified against acceptance tests the agent cannot touch.

What it is

Code intelligence is several kinds of evidence answering different questions, not one tool. Lexical search finds exact identifiers, configuration values, comments and strings cheaply, but misses anything phrased differently elsewhere. An abstract syntax tree captures structure once a file is parsed. A language server adds symbols, type facts and references, at the cost of extra reads. A static call or data-flow graph approximates dependencies, overapproximating behavior runtime assumptions rule out, or missing dynamic dispatch. A runtime trace shows only what was actually exercised, so an untraced path stays invisible.

A repository map is an index, not proof of architecture: it goes stale the moment a dependency changes, so any map an agent relies on must bind to an exact commit and environment. Choose the cheapest tool that resolves the uncertainty, then stop. Acceptance criteria stay outside the agent's authority to edit or weaken, and untrusted repository setup, cloning, dependency installation, build hooks, is its own authority-bearing operation needing isolation before it runs. An agent may add its own tests, but never delete or soften the tests that decide whether its own work passed.

The architecture

My framework for this is the four-gate proof loop: one repeating cycle a patch moves through, gated at four points so real context, cheap evidence, protected acceptance and honest measurement each get their own checkpoint instead of being assumed.

The first gate is context: the task is bound to an exact commit, the relevant architectural entry points, dependency rules and public interfaces the change must respect. A stale or generic map is worse than no map, it creates false confidence about a system that has already moved on.

The second gate is evidence: the agent inspects only the region the task needs, reaching for the cheapest tool that resolves it. This is where wasted spend hides: a 2026 study across three Python and TypeScript repositories, three Claude models and five retrieval arms found a language server's value depends on the task and representation returned, not a fixed rule that richer tooling always wins, and location-only semantic results can force extra reads.

The third gate is acceptance, protected mechanically, not by instruction. Layered checks, build, lint, type, unit, integration, security, end-to-end, run in an isolated workspace against a manifest the agent cannot edit, delete or weaken. Untrusted setup is reviewed before it executes: a July 2026 study of twelve scenarios and five attack classes across seven models and four harnesses found repository setup can cross into executable supply-chain effects before an agent's own warning protects the user, especially under auto-execution.

The fourth gate is outcome, where a human reviewer and a hidden, composed-feature test do what a visible test suite cannot. A May 2026 study of thirty coding tasks, SpecBench, found that passing visible feature tests does not establish that hidden, composed combinations of the same specification also pass, a gap that does not prove gaming but makes visible tests a weaker bar than they appear. A change counts once it clears both, measured as accepted maintainable work.

The common failure across all four gates is the same: letting the cheapest available signal stand in for what it was never designed to prove.

How to lead it

Ownership belongs to whichever group runs the shared repository and acceptance tooling, not each product team, because the acceptance manifests, isolated environment and typed interfaces every agent depends on are platform infrastructure.

Fund the acceptance layer and review process at the same level as the coding-agent spend itself: an unverified pass is a cost deferred, not a savings. Measure accepted maintainable changes, review-adjusted throughput, escaped defects, and cost per independently verified success that counts failed runs. Stop funding any acceptance suite generated from the agent's own output, any productivity claim built on selected examples with no counterfactual, and any dashboard built only from successful runs.

Two decisions do not belong to engineering alone: how much authority repository setup gets before a human reviews it, and the improvement margin required to promote an agent workflow to more repositories, with a rollback trigger if it is wrong.

What it is worth

The money and risk show up in three places: rework from changes that passed a visible check but missed a hidden requirement, wasted retrieval spend from a richer evidence tool than a task needed, and supply-chain exposure from setup steps executed before anyone reviewed them. Measure with review-adjusted throughput, escaped defect rate, cost per independently verified success including failed trials, and setup-stage actions caught before execution.

The 2026 evidence supports gating acceptance mechanically, choosing evidence tools by the uncertainty at hand, and isolating repository setup before it runs. It does not support a general productivity or maintainability multiplier: the dossier states plainly that longitudinal evidence on maintainability and future change cost is still insufficient, so no return figure belongs in a decision here until an organization's own reconciled outcomes supply one.