Claude Code’s verification loop is the real coding-agent primitive
Claude Code’s verify workflow points to a practical pattern for coding agents: capture the checks humans already run by hand, make them measurable, and let the agent rerun them until the change proves itself in the product, not just in tests.
TL;DR: Claude Code gets more useful when you turn your manual acceptance checks into measurable project skills, because the agent can rerun them, fix failures, and show receipts instead of waiting for your browser feedback.
What changes when verification becomes part of the prompt?
Claude’s first-party explainer, “Building verification loops in Claude Code,” makes a simple point that I think is easy to underrate: the bottleneck in coding agents is often not code generation. It is verification.
Claude Code already runs the usual machine checks: tests, type checks, linters. Those are necessary. They are not enough. A change can pass all of that and still fail the thing you actually care about. The page jumps on load. The button works but appears in the wrong place. The endpoint returns JSON, but not the response shape the client expects.
Today, that missing layer is often you. You open the browser. You click around. You watch the console. You paste feedback back into the agent.
Claude’s argument is that some of that human acceptance loop can be captured as project knowledge. In “Building verification loops in Claude Code,” Claude says the verify skill can run the app, check the change in the app itself, then save the working steps as a skill in the project. After that, Claude Code can use tools like a browser, terminal, and iOS simulator to repeat those checks.
That is a more practical definition of “agentic coding” than most demos. Not “the AI wrote a whole app.” More like: the agent knows what done means in this repo, can measure it, and can retry when it fails.
What should builders actually codify?
The useful checks are the ones you already perform without thinking.
For a web app, that might mean opening the page, clicking the new control, watching for console errors, taking a screenshot, and checking layout stability. Claude gives the example of using Google Chrome’s DevTools MCP to run a performance trace and measure layout shift, one of Google’s Core Web Vitals. In the example, Claude Code adds a Like button, runs the UI check, detects layout shift, fixes it, runs the checks again, and returns screenshots and scores as proof.
That is the right shape. Not vibes. Not “looks good.” A check should say when to run, what action to take, what failure looks like, and what counts as pass.
For a backend service, the equivalent might be calling an endpoint with a known payload and comparing the response. For mobile, it might be tapping through a simulator flow. For a design system, it might be checking spacing, variants, or accessibility rules. For content-heavy products, it might be validating rendering states, broken links, or empty-state behavior.
The key is to avoid turning every preference into an agent rule. Codify the repeatable stuff first. The checks with clear signals. The things you hate re-explaining.
Where does this break?
Verification loops are only as good as the signals inside them.
If the check is vague, Claude will satisfy the vague check. If the browser flow misses the real edge case, the agent will still report success. If a screenshot is the only proof, you are back to subjective review. This is not a replacement for product taste, security review, or hard judgment.
There is also a maintenance cost. Skills can drift as the app changes. A flow that worked last month may click the wrong element after a redesign. Performance budgets can become noisy. Simulator checks can get flaky. Builders should treat these skills like test code, not magic memory.
Still, I like the direction because it puts the burden in the right place. The answer to weak coding-agent output is not only a bigger model. It is better work definitions. Better harnesses. Better project-specific acceptance criteria.
Practitioner’s take: next time you catch yourself giving Claude Code the same browser feedback twice, turn that into a verify skill. Start with one narrow path: run the app, perform the action, inspect the console, capture a screenshot, measure one objective thing. The catch most readers miss is that the skill should not describe your intent, it should describe the proof. Done is not “make the UI better.” Done is “click the button, see the state change, no console error, no visible layout jump.”