Make Claude prove its work with 2 critical verifications

"It works," Claude told me.

It hadn't run anything. It re-read the code it just wrote, decided it looked correct, and called it done.

That's the trap, and once you see it you can't unsee it: Claude is blind to its own output. Ask it "does this work?" and the only thing it can do is re-read its own code and confirm the code matches what it intended. Of course it matches. The same model wrote it.

Reading your own code isn't verification

That's not verification. It's self-confirmation. And self-confirmation tells you nothing, because nothing outside the code ever pushed back on it.

Real verification is different. It means checking the work against evidence the model can't fake: proof that comes from outside the code, not from re-reading the code. Until you have that, "it works" is just a guess.

So the fix isn't a smarter prompt or a bigger model. It's two directives, baked into every build, that force Claude to prove the work instead of vouch for it.

Directive 1: tests must pass

The first one is simple. After every new feature, Claude writes tests and the suite has to come back 100% green. Not "I think it works." A passing run, every time.

This sounds obvious, and it's the one people skip. "The code looks right" is an opinion. "The tests passed" is a fact. A green suite either happened or it didn't, and Claude can't talk its way around a failing test.

Make it a standing rule, not a request you remember to type: write the feature, write the tests, run them, and don't call it done until they pass.

Directive 2: open a browser and look

Tests catch the logic. They miss the thing your user actually sees on the screen.

So the second directive: before Claude claims a UI feature is done, it opens a real browser and looks. I use the agent-browser skill for this. Claude navigates to the page, takes screenshots, checks what's actually rendered, and fixes whatever's wrong before it reports back.

This is the one that surprises people. The tests can be all green while the screen is broken: a layout collapsed, a button off the edge, a state that never renders. The logic passed. The page didn't. And Claude had no idea, because it was never looking at the same thing your user is.

Once it opens the browser, that gap closes. Claude sees what the user sees, instead of what it assumed it built.

What the two directives buy you

Put both in place and your first delivery comes back working 95 to 99% of the time. Not perfect, but close.

That changes the whole shape of the work:

• Without verification, the first delivery is a rough draft. You click through every screen yourself to find what's broken, then send it back.
• With it, the first delivery mostly works, and your job shrinks to a quick refining pass on the few things left.

The occasional small bug still slips through. This isn't magic, and you'll still catch the odd thing yourself. But there's a real difference between a refining round that's a short list of fixes and one where you're babysitting the whole build. These two directives move you from the second to the first, and that's a ton of time you stop spending on cleanup.

Make it prove it

"Claude said it works" was never enough, because re-reading your own code and declaring success isn't the same as proving it.

So stop taking its word for it. Make it close the loop with evidence: a test suite that passes, and a browser it actually looks at. Bake both in so they run on every feature automatically, not when you remember to ask.

That's the move. It's one of the cheapest upgrades you can make to how you build, and it's the kind of working habit I teach inside Builder Methods.