← CodeVetter

Verification field guide

Coding-agent verification

Learn how coding-agent verification connects a task, agent change, executable checks, evidence, and a measurable verdict.

Coding-agent verification answers a stricter question than code review: did an agent complete the requested software task correctly, and what executable evidence supports that verdict? A useful verification loop begins with the task, preserves the agent's change, runs checks against the changed behavior, collects the resulting evidence, and emits a verdict that another person or system can inspect.

Review is an input, not the verdict

Static review can identify suspicious code, but a plausible finding is not the same as a reproduced failure. Likewise, a green test command is not automatically proof: the test may not exercise the requested behavior, the environment may differ, or an existing failure may be mistaken for a regression. Verification links the task, revision, environment, command, output, and result instead of collapsing them into a confidence score.

The five-part loop

  1. Task: preserve the requested outcome and acceptance boundary.
  2. Change: bind the exact repository revision and agent-produced patch.
  3. Execution: run declared checks in a bounded environment.
  4. Evidence: retain commands, outputs, artifacts, and failure classifications.
  5. Verdict: report what passed, failed, or remained unverified without turning missing evidence into success.

CodeVetter is being built around this loop. Its CLI, MCP boundary, and machine-readable verification bundle are the primary product surfaces; the desktop app is a local viewer. The current public benchmark is deliberately narrower: it contains 27 synthetic cases and 29 labeled findings for reproducible recognition scoring. It is useful evidence about that benchmark and is not proof of performance on arbitrary production repositories.

When verification matters

Verification is most valuable when an agent changes authorization rules, browser state, API contracts, persistence, concurrency, or regression-sensitive behavior. These tasks can look reasonable in a diff while failing at runtime. A good verifier makes the failure reproducible and makes uncertainty visible.

What to inspect next

Read the step-by-step verification workflow, compare review with verification, inspect the verification evidence bundle, and then open the public benchmark to see the cases, outputs, scorer, and limitations.

CTA: Inspect the public benchmark or download CodeVetter to examine agent-written changes locally.