The plan → execute → verify loop is the three-step cycle behind any AI coding session: the agent proposes what it's about to change, makes the change, and then someone confirms the result actually does what was intended. Most people run the first two steps and stop — which is exactly backwards, because verification is where the actual quality decision gets made.
Updated August 2026. This pattern predates AI coding entirely — it's just how careful engineers have always worked — but coding agents make skipping the last step easy, because execution finishes fast and confidently states it's done. That confidence is exactly the part that isn't verified.
The asymmetry shows up in the numbers. An agent's own checks — tests, types, lint — run in seconds and cost almost nothing. Catching a visual or judgment miss later costs real tokens: a single 1080p screenshot runs about 2,691 tokens to hand back to the agent on Claude 4.7 and later, by Anthropic's published patch formula (full breakdown here; Source: Anthropic, 2026). On older, standard-tier models the same screenshot is downscaled and costs 1,560 instead, and that's before you've said a word about what's actually wrong with it.
That gap is why verification deserves its own treatment. It's the throughline of how to review what your AI coding agent built, and the plan → execute → verify loop is the mechanical skeleton underneath it.
What is the loop?
The plan → execute → verify loop is a three-stage pattern for any change an AI coding agent makes: plan states what will change and how success will be checked, execute makes the change and runs whatever checks it can run itself, and verify confirms the result matches what was intended — a step only a human can fully close.
Coding agents didn't invent this — it's how a careful engineer already works, split into three named stages so an agent, and you, can reason about which one a problem actually belongs to. Claude Code makes the first stage explicit with a plan mode that proposes file changes before touching anything. Execute is the part agents are genuinely good at: reading files, writing diffs, running commands, iterating against error output. Verify is the part that quietly gets skipped, because execution ends with the agent stating it's done — and "done," to the agent, means its own checks passed, not that the result is what you actually meant.
What does a good plan look like?
A good plan names the files that will change, describes the behavior difference in plain terms, and states up front how you'll know it worked — a specific check, not "it should work now." That last part matters most: a plan without a stated success condition gives execution nothing to verify itself against later.
Three things separate a plan you can verify against from one you can't:
- Scope — exactly which files or components change, not "the login flow."
- Expected behavior — what should happen after, described in terms you'd actually observe, not implementation detail.
- A success condition — the specific thing that, if true, means it worked. A passing test is one. "The button turns green on save" is another.
Vague plans produce vague verification. If the plan says "fix the spacing," there's no way to check the fix later except by feel — fine for a five-second glance, useless the third time you're re-checking the same page.
What happens in execution?
Execution is the agent editing files, running commands, and iterating against whatever feedback it gets — test failures, type errors, lint warnings — until its own checks pass. It's mechanical and largely self-correcting: the agent can see its own tool output, so it catches its own syntax and logic mistakes without you in the loop.
This is the stage AI coding agents are best at, and it's improved fast for a simple reason: everything execution needs to check is text. A failing test prints text. A type error prints text. A linter prints text. The agent reads it, adjusts, re-runs, and repeats until the text says pass. That loop can run dozens of times inside one turn without you noticing, which is exactly why execution feels so fast and confident compared to the review stages around it — it's optimizing against a target it can actually measure.
Why is verification the weak link?
Verification is the weak link because it needs eyes on the actual rendered result, and an agent has none — it perceives text: file contents, command output, its own diff. Whether a layout looks right, a color feels off, or a fix matches what you meant are judgment calls no amount of passing tests can settle on their own.
Tests, types, and lint all check a claim the agent can state precisely: this input produces that output. "Looks right" isn't that kind of claim — it's comparing a rendered page against a mental picture only you have. That's the deeper architectural reason your agent can't see what it built: it works entirely in text, and the gap between text and the thing a human actually experiences on screen is exactly where verification lives. A green checkmark on a test suite tells you the logic runs. It says nothing about whether the button is reachable, the copy reads naturally, or the layout survives a long name.
Who can verify what?
An agent can verify anything with a text-based pass/fail signal: tests, type checks, lint rules, and whether its diff matches its own stated plan. A human has to verify anything that needs judgment: whether the result looks right, feels right, and actually matches what you meant, because only you know what you meant.
| What needs checking | Can the agent verify it? | Why |
|---|---|---|
| Tests pass | Yes | It ran them and can read the output directly |
| Types check | Yes | Compiler output is text |
| Lint rules | Yes | Linter output is text |
| Diff matches its own stated plan | Yes | It can compare its changes to what it said it would do |
| Layout renders correctly | No | It has no view of the rendered page |
| Color, spacing, motion feel right | No | Judgment call, not a pass/fail signal |
| Copy reads naturally | No | Tone isn't checkable against a rule |
| The fix matches what you actually meant | No | Only you know your own intent |
| Edge cases nobody thought to test | No | Untested paths pass silently either way |
The top four rows are why "all tests pass" feels like enough — it genuinely is enough for the agent's half of the job. The bottom five are why it isn't enough for yours. A practical run-through of that bottom half — the specific things agents miss when nobody's looking — is the subject of "The agent said it's done": a 12-point checklist for verifying AI-built UI.
How do you close the loop quickly?
Closing the loop fast means looking at the actual result yourself right after execution, not trusting the agent's own "done," then reporting back specifically: where the problem is, what you expected, and what's there instead. A vague "this looks off" restarts the whole loop; a precise report lets the agent verify against something concrete.
In practice, that's a short sequence:
- State the success condition in the plan, before execution starts — you're setting up the thing you'll check against later.
- Let the agent run its own checks first. Tests, types, and lint are free; there's no reason to eyeball what a machine can confirm faster.
- Look at the actual result yourself. Not the agent's summary of the result — the thing itself, rendered.
- Report the gap precisely: location, what you expected, what's actually there. How to give feedback to Claude Code so it lands covers the anatomy of a report that works versus one that doesn't.
- Confirm the fix against the same view you flagged, not a fresh description of it.
Step 3 is where most workflows quietly break down: looking costs attention, and re-describing what you're pointing at costs tokens. A 30-second screen recording frame-dumped at 1 fps runs to 80,730 tokens, calculated from Anthropic's published patch formula — the full mechanics are in why your agent can't watch a screen recording — while a complete review bundle, voice plus the frames your pointer actually selected, runs about 3,500 tokens, measured, a 23× reduction (calculated) for the same 30 seconds. Walkie is one tool built specifically to make that compression automatic; it doesn't replace step 3, it just makes doing it honestly cost less.
Start here
You don't need new tooling to close this loop today. Write the success condition into the plan before execution starts. Let the agent run its own checks. Then actually look — at the real result, not the agent's description of it — before you say done. That third step is the whole difference between an agent that assists you and one you have to double-check every single time.