# Coding-agent verification

> Canonical page: https://codevetter.com/coding-agent-verification

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.

## Public product links

- [CodeVetter](https://codevetter.com/)
- [Download](https://codevetter.com/download)
- [Documentation](https://codevetter.com/docs/)
- [Source](https://github.com/Codevetter/codevetter)