Trust, but read what Claude read

You’ve spent six lessons trusting Claude’s answers — what does this do, where is this called, what changed. Time to put a load-bearing habit underneath all of that.

Claude is fast and usually right. Usually isn’t always. The fix is simple: ask which file and which line, then go look.

This is the most important habit in the whole level. It’s the difference between “reading with Claude” and “hoping Claude is right.”

Why this matters specifically in read mode

Back in Lesson 2.6, you learned that Claude pauses for permission before doing something irreversible — writing a file, running a command. That pause is your safety net for changes.

Read mode has no such pause. When Claude answers a question, nothing on disk changes, so there’s no prompt — and no built-in moment for you to second-guess. A wrong answer slides past unchecked. If you act on it later (in your code, in a meeting, in a PR description), you’re stuck with whatever it told you.

The substitute for that pause is you reading what Claude read.

The two failure modes

Claude can go wrong in roughly two ways when reading code.

Mode 1: misreading the real thing. Claude found the right file, opened it, but summarized it slightly wrong — got the conditional backward, missed a case, lumped two functions together. The names and line numbers it cites are real; the conclusion is just a bit off.

Mode 2: making things up. Less common, more dangerous. Claude invents a function name, a file path, or an import that doesn’t exist. The answer sounds plausible. The thing it’s describing isn’t actually in the code.

Both modes look identical from the outside — a confident summary. The way you tell them apart is by checking.

The verify habit

You ask one extra question after any non-trivial answer:

which file and which line did you get that from? Quote it.

Now Claude has to be specific. You can take that answer and:

Open the file (code src/auth.ts or just cat src/auth.ts or scroll your editor).
Look at the line.
Confirm the quoted text is actually there.

This works because citations are falsifiable. A summary you can’t check is a story. A summary backed by “line 42 of src/auth.ts” takes ten seconds to confirm — and Claude knows you might confirm it, which by itself makes the answer more careful.

What “confirming” actually looks like

For a small claim — “the function returns null on failure” — you open the file, scroll to the function, glance at the return statement. Five seconds.

For a bigger claim — “this function is called from three places: X, Y, and Z” — you spot-check one or two. If both check out, the third probably does. If even one is wrong, ask Claude to recheck.

You’re not trying to re-derive Claude’s whole answer from scratch. You’re sampling for honesty. (This is exactly how reviewers approach a junior engineer’s PR — not by re-doing the work, but by checking the load-bearing parts.)

When to verify and when not to

Not every answer needs a verification step. A useful rule of thumb:

The answer is about…	Verify?
What a single file does, broadly	Light — read the summary, glance at the file
Whether a specific function exists, where it lives	Yes — open it
What calls a function (a list)	Yes — spot-check at least one
What a value is set to	Yes — open and look
What changed in git history	Yes — ask Claude to quote the commit and the diff
How a library you know well behaves	Light — your prior knowledge does the work
A claim you’re about to put in a PR, doc, or message	Always

When you’re about to act on an answer — change code, tell someone, file a bug — verify. When you’re just orienting, lighter is fine.

The thing that trips people up

The temptation is to skip verification because Claude sounds confident. This is the trap. Confidence is a feature of how language models talk; it’s not a signal of truth. A made-up answer and a correct answer can look word-for-word identical in tone.

Confidence is style, not evidence. The evidence is the file.

Make the habit small enough that it doesn’t break flow. “Quote the line” takes one extra turn. That turn is the cheapest insurance policy you’ll ever buy.

A nicer side effect

Asking Claude to cite makes Claude think more carefully on the first pass. Once it knows you’ll want a quoted line, it tends to actually go find a quoted line instead of pattern-matching from memory. You get better answers up front, not just better fact-checking after.

This is why experienced Claude users build verification into their first question, not their follow-up:

where is handleLogin defined? Open the file and quote the function signature.

That’s the move. One question, citation built in, no follow-up needed.

What’s next

Seven lessons in, you have the full toolkit: framing, file scope, symbol scope, tracing, errors, history, and the verify habit. Time to use all of them on a real codebase, end-to-end. That’s the capstone.