5.3
Checking Claude's Work
Why this exists
Back in 2.1 you learned it can be confidently wrong about facts. This is the same problem wearing different clothes: it can be confidently wrong about work it just did — and tell you it's finished when it isn't.
This is the lesson your background is built for. Checking whether something does what it claims is your day job. You're about to point that instinct at a different kind of document.
The idea
"Done" is a claim, not a status. Somebody has to check, and that somebody is you.
Claude will tell you it added the thing, fixed the bug, handled the edge case. Usually true. Sometimes it did most of it. Occasionally it did something adjacent that looks right from a distance.
Nothing in the message tells you which — same as 2.1, the tone is identical either way.
Four checks, in order of how often they catch something:
| Check | What you do |
|---|---|
| Use it | Actually click the thing. Don't read about it. |
| The nasty input | Empty, wrong, enormous, weird characters |
| The claim | It said it did X — go and look at X |
| The blast | What else did it touch? git diff |
That last one catches the worst class of problem. You asked for one change; it made four, three of which you didn't ask for and won't notice for a week. git diff before you commit shows you every line that changed, and it takes ten seconds.
The nasty input is where real defects live. Everyone tests with a sensible name in the name box. Nobody tests with an empty box, a name with an apostrophe, or two hundred characters. That's where things break, and it's where your finance instinct is already calibrated — you don't check the invoice that looks right, you check the one at the edge.
One thing to hold onto: finding a defect is the lesson succeeding, not you failing. A defect you found is worth more than a build that seemed fine, because the seemed-fine version has the same defects and you just haven't met them yet.
And when you do find one, don't fix it in the same breath. Write down what you did, what you expected, and what happened. That's a bug report — and in Level 6 that habit becomes the difference between "it's broken" and a message somebody can act on.
Do
- Open the thing you built in 5.2. Use it normally, start to finish, like someone who didn't build it.
- Now try to break it. At minimum: empty input · wrong type of input · very long input · special characters like apostrophes and quotes.
- Take Claude's last three completion claims and check each one against the actual file or the actual behaviour.
- Run
git diff HEAD~1on your most recent round. Read every changed line. Ask yourself: did I ask for this? - When you find something, write it in
defects.mdas three lines — what I did · what I expected · what happened. - Find at least one real defect. If you genuinely can't, you haven't tried nasty enough input yet.
- Only now, fix one. Then re-check it the same way.
Step 6 is not optional. Every build has something. If you're not finding it, the checking is too gentle.
Done when
Never do
Never take "done" as done. Not from Claude, not from anyone. It's a claim about work, and claims get checked before they go anywhere that matters.
Never commit without reading the diff. It's ten seconds and it's the only thing standing between you and a change nobody asked for arriving in your project unnoticed.