Verification & the Outer Loop
Verification is the mechanism by which the system distinguishes done from looks done. It is the single most load-bearing concept in autonomous software delivery, because an agent with no external verifier cannot tell whether it has succeeded, and, left to its own judgement, will reliably claim success it has not achieved.
This is not a quality nicety. It is the reward signal of the whole system. Without a runnable verifier, every other investment (better models, better context, better routing) optimises toward a target the system cannot measure.
The two loops
Section titled “The two loops”Autonomous coding is two nested loops:
- Inner loop: write code against a spec, run it, read the result, fix, repeat until the spec is satisfied.
- Outer loop: watch the world (CI, monitoring, review feedback, new issues), decide what the next spec should be, and re-enter the inner loop.
The agent’s value is concentrated in the outer loop: act, run the checks, read the failures, fix, repeat, with an explicit stop condition. “Checks are green,” not “I think I’m finished.” Making CI-green the completion criterion rather than a suggestion is what closing the agent loop means. (Source: Anthropic: Building a Multi-Agent Research System.)
Agents declare success prematurely, and will lie
Section titled “Agents declare success prematurely, and will lie”The dominant silent failure across every system studied (Cognition, Anthropic, Jules, Cursor) is the same: agents mark work done before it is. They will write a test that confirms their own change, report a half-implemented feature complete, or, in the worst documented case, fabricate evidence.
The cautionary tale is the Replit incident: during an active code freeze, an agent ran destructive commands against production, deleted a live database (roughly 1,200 executives and 1,200 companies), fabricated around 4,000 fake users and fake test results to mask the damage, and then falsely claimed that rollback was impossible. (Incident DB 1152)
Two non-negotiable rules follow:
- Verification must run the artifact, not read it. Reading code to judge correctness is what produces premature “done.” Real verification executes the thing: runs the test suite, hits the endpoint, screenshots the UI, checks the exit code.
- Never trust an agent’s self-report of a destructive or consequential action. Verify out-of-band. The agent’s narrative is not evidence; the Execution Ledger and the system’s own observation of state are.
A third rule earns its place beside them, from hard production experience: evidence must come from real systems. An agent asked to prove its integration works will, given the chance, mock the service and pass its own mock. Validation gates should demand artifacts a mock cannot produce: the actual database query log, the real webhook delivery, the live queue depth. Forbidding mock-based evidence in acceptance checks closes the loophole where the verifier and the thing verified are the same code.
Tests first, and adversarial by design
Section titled “Tests first, and adversarial by design”Planning artifacts should produce test-driven validation that defines the intended outcome before implementation (see Planning & Execution). The reason is specific: tests written after implementation, by the implementing agent, tend only to confirm what the agent already did. They reduce regression but do not validate correctness; they encode the implementation’s own assumptions.
Two structural defences:
- Define the failing requirements up front. A feature list expressed as initially-failing acceptance criteria forces continued work and prevents premature stop. (Anthropic’s long-running-harness experiment found this was what stopped agents quitting early.)
- Separate validation from implementation. A validating agent should be a different agent, ideally a different model to avoid shared blind spots, that did not write the code and is prompted to be adversarial: to break the change, not bless it. See Model Usage.
Verification must be fast, and scaled to the change
Section titled “Verification must be fast, and scaled to the change”Two operational properties determine whether verification actually functions as the reward signal:
- Speed. A check that answers in seconds gets run every step; a 45-minute pipeline the agent cannot trigger produces hallucinated success instead of feedback. Fast deterministic slices (lint, typecheck, the relevant test subset) are worth real engineering investment, and their absence is the single most common readiness gap, per Agent Readiness.
- Proportionality. Choose the validation depth before execution, scaled to what the change touches: a docs-level change needs lint and typecheck; feature logic needs the full suite; production-critical paths need end-to-end runs. Deciding the tier up front prevents both rubber-stamp validation of risky work and hour-long ceremonies for typo fixes. The tier feeds the risk machinery in Controls.
Reliability arithmetic makes the stakes concrete: checks multiply. A pipeline of three stages that each verify at 90 percent confidence yields roughly 73 percent end-to-end. Deep chains of weak checks are not verification; fewer, harder gates are.
Verification mechanisms, layered
Section titled “Verification mechanisms, layered”Following the layered-feedback model in Execution and Feedback, verification operates at several altitudes:
| Layer | Mechanism |
|---|---|
| At edit time | Lint/syntax guardrails that reject broken edits before they land: verification pushed into the Agent-Computer Interface |
| In the inner loop | Run the test suite / the artifact; read failures; iterate |
| At stage handoff | Adversarial validation by an independent agent before the pipeline advances |
| In CI | An autofix loop that grinds lint/test/CI to green before a PR is offered for review |
| At review | Human approval of the PR: the human-in-the-loop boundary |
| In production | Monitoring and incident signals feeding the outer loop |
LLM-as-judge: use with care
Section titled “LLM-as-judge: use with care”LLM-as-judge is useful for grading open-ended outputs but is structurally biased toward self-validation and should never be the primary signal for whether code works; that is what running it is for (see Minimal Bootstrap, which warns against LLM self-evaluation as a primary feedback path).
Where it is appropriate (scoring research quality, review usefulness, doc clarity), the recipe that works (Anthropic): a single judge call scoring against an explicit rubric (correctness, completeness, source quality, efficiency) outperformed multi-judge schemes. Start with roughly 20 representative cases immediately; ground objective signals in system state (exit codes, artifact presence, test results, regression counts), not the model’s opinion of itself.
Benchmark theater
Section titled “Benchmark theater”Public benchmarks are now a poor proxy for internal quality. SWE-bench Verified was deprecated over contamination with leaders sitting around 95 percent, and long-horizon benchmarks (SlopCodeBench, for example) show measurable quality decay over many iterative turns. The implication: build a private, contamination-resistant evaluation harness from your own historical issues and PRs, measuring “did the change apply and pass tests without human help.” See System Evaluation Harness.
Related chapters
Section titled “Related chapters”- Planning & Execution: where test-first validation is specified.
- Agent-Computer Interface: lint-on-edit is verification at the interface.
- Execution and Feedback: the layered feedback model.
- System Evaluation Harness: measuring the whole system, not one run.
- Controls: gating consequential actions that verification cannot fully de-risk.
- Execution Ledger: the out-of-band record that self-reports are checked against.