“It works” vs “I checked that it works” — why not to take the AI at its word

Imagine you leave your car at the mechanic’s. You come back and he says: “fixed”. Sounds nice. But how do you know it’s true? A mechanic you trust does something more — turns the key in front of you, the engine starts, and he says: “hear that? Running smoothly”. That’s the difference between a declaration and proof.

Exactly the same habit will save you a lot of nerves working with Claude.

Two different sentences that sound alike

• “It probably works” — that’s hope. An assumption. The code looks good, so it probably does its job.
• “I ran it, I checked, here’s the result” — that’s a fact. Something was actually launched, and you see the result with your own eyes.

The problem is that the AI can write beautiful, sensible-looking code — and announce “done” with full conviction, even though it never ran it. Not out of a wish to deceive. Simply, if you don’t ask, it often won’t check.

That’s why your job isn’t writing code. Your job is making sure proof is given.

How to ask for proof

The secret is simple: after every change, ask not “does it work?”, but “show me that it works”. Don’t let the AI narrate — let it run it and paste the result.

A few sentences you can paste directly:

Don’t write that it works. Run it and paste me the exact result
that confirms it worked.

Show proof this change does what it was meant to. If it’s something
visible on the page — take a screenshot. If it’s numbers —
query the database and paste the actual result.

Run all the tests and paste me their full output —
including the number that passed and the number that failed.

Notice the pattern: every time you ask for something tangible — a result, a screenshot, a number. Not an opinion.

What to expect from a good answer

When you ask for proof, a good answer looks roughly like this: “I ran it — the login page shows correctly, here’s a screenshot. Tests: 24 passed, 0 failed”. Specifics. Numbers. An image. (Those “tests” are software tests — small programs that check by themselves whether the app does what it should; the AI can write and run them.)

A worse answer is still just “it should work” or “everything looks fine”. Then don’t let it slide — ask again: “I’m not asking how it looks, I’m asking what happened when you ran it”.

And the most important thing: ask the AI to be honest. If something failed — it should say so with the result, not sweep it under the rug. A candid report “two tests didn’t pass, here’s which” is better than a smooth “all good”, after which something breaks at a customer’s a week later.

If anything didn’t work or you skipped something —
tell me outright, with the result. I’d rather have the truth
than an over-optimistic “it works”.

This isn’t a lack of trust. It’s plain professional hygiene — the same you expect from a mechanic who shows you the engine starting.

In short

• “It works” is not proof. Treat the declaration as hope until you see the result with your own eyes.
• Ask for something tangible — a test that was run, a screenshot, a number from the database. “Show me that it worked” is your most important sentence.
• Reward honesty. A candid “two tests failed” is worth more than a smooth “all done” — because it spares you an outage at real customers.