Verification
AI code verification should reject weak evidence
AI code verification is the discipline of checking generated code against the request, the repository, and executable evidence. It is not a second prompt asking the same model whether its own work looks correct.
The minimum standard
The useful standard is simple: a verifier must be allowed to say no. If a change has missing tests, unclear scope, broad unrelated edits, or skipped checks hidden behind confident wording, the verifier should send it back.
- AuthorThe agent that wrote the code records intent, changed files, and assumptions.
- ChecksThe workflow runs the repository's real tests, type checks, linters, previews, or build commands where available.
- VerifierA separate role inspects the diff, edge cases, and residual risk before the work is called ready.
What a verifier should reject
- A final answer that does not name the behavior changed.
- A diff that changes unrelated files without explaining why.
- A test claim without command output or a clear reason the test could not run.
- New data writes, auth logic, billing behavior, or migrations without boundary review.
- Review notes that only restate the implementation instead of challenging it.
What a useful report looks like
A useful verifier report has a small number of fields: scope, checks run, findings, rejected assumptions, residual risk, and merge recommendation. It should make uncertainty visible instead of smoothing it over.
- ScopeBilling settings form and API save path. No changes to invoice generation.
- ChecksType check passed. Validation tests passed. Preview exercised loading, empty, and error states.
- RejectedFirst pass saved the UI state but failed to reload the saved value after refresh.
- RiskProvider-specific billing errors were not exercised locally and need human review before release.
Confidence is not evidence. Evidence is what ran, what failed, what changed, and what still needs judgment.
How Concertor fits
Concertor's verification story should be about structure: author and verifier are separate roles, checks are recorded, weak changes can be sent back, and the final handoff tells a human reviewer what remains uncertain.