AI Coding Verification

AI-generated code is now a structural part of how software gets built — and its share is still climbing. What has not kept up is the ability to say, with confidence, what any given generated change actually does. That gap has a name: verification debt.

Verification is the answer to a question code review alone was never designed for: not “is this code well written?” but “is this the change we asked for, inside the boundaries we set, with proof it was checked?”

A code review looks at a finished diff. Verification is a loop that wraps the entire coding run — and most of it happens outside the diff:

• Intent match: does the change do what the task asked — and nothing else?
• Scope respect: did the run stay inside the files and boundaries it was given, or did it “helpfully” touch things it shouldn’t?
• Validation: did checks run that the generating model did not write itself — tests, linters, type checks, build?
• Evidence: is there a reviewable record of what was validated, what was skipped, and what remains uncertain?
• Human acceptance: does a person — with that evidence in front of them — make the final call?

A practical loop that works with any AI coding tool:

1. Before the run — define the task. Write down the goal, the boundaries (which files, which behavior must not change), and the validation plan: how you will know it worked. Five minutes here is the highest-leverage step in the loop.
2. During the run — keep it bounded. Small, scoped runs beat sprawling ones. If the task grows, split it; a run that changed 40 files is not verifiable, only mergeable.
3. After the run — check against intent. Diff the result against the written task, not against your memory of it. Off-scope changes are findings, even when they look like improvements.
4. Validate independently. Run the validation plan: existing tests, type checks, lint, build — plus targeted checks the generating model did not author.
5. Attach the evidence. One short record per run: intent, what changed, what was validated, what was not, open questions. This is what the reviewer — and your future self — actually needs.
6. Human gate. A person accepts or rejects the change with the evidence in view. No auto-commit.

Several tool categories cover parts of this loop, and most teams will combine them:

• Cloud PR reviewers comment on pull requests with strong models and zero setup — they cover the “read the diff” step, after the code exists, as an external service.
• Static analysis, linters, and SAST catch known bug patterns and security issues deterministically — necessary, but blind to intent: they cannot know what the change was supposed to do.
• Tests and CI verify behavior — as far as the tests reach, and only if the tests weren’t generated by the same run they are supposed to check.
• Verification layers (the category Reality Graph is in) wrap the loop itself: intent and boundaries before the run, independent validation and evidence after it, a human gate at the end — designed to run locally, beside the coding tools you already use.

None of these replaces the others. The mistake to avoid is covering only the post-hoc steps: if intent was never written down, no tool can verify against it later.

Reality Graph implements this verification loop as a local-first layer beside Claude Code, Cursor, GitHub Copilot, and similar tools: task boundaries and context before the run, visible validation and a reviewable evidence report after it, a human approval gate in between. It is in private beta — early access is open for a small group of teams.