Asking about a file

In Lesson 4.1 we said Claude can read anything. So a natural first instinct is to ask the biggest question possible: “explain the codebase.” It seems efficient. It isn’t.

The more specific you are about where to look, the sharper Claude’s answer. Naming a file is the single biggest upgrade you can make to a question.

This lesson is about that one move.

The vague question vs the sharp question

Picture you’ve just opened Claude in a project folder. Two versions of the same question:

Vague:

explain the codebase

Sharp:

explain src/auth.ts

The vague question makes Claude do a lot — list files, sample a few, guess at the overall shape, summarize in broad strokes. The answer will be long and a little fuzzy. Some of it might even be wrong, because Claude had to skim instead of read.

The sharp question makes Claude do one thing well: open one file, read it carefully, tell you what it does. The answer is short, specific, and grounded in actual lines.

The sharp version is almost always what you want.

Why constraint helps Claude (and you)

Reading is cheap when scoped. Reading is expensive — and lossy — when sprawling. Pointing at a file:

Tells Claude exactly which lines to read.
Removes the guessing game (“is the auth in auth.ts, login.js, or session/index.ts?”).
Gives you an answer you can check against the actual file in seconds.

It also helps you. You start to break a big scary codebase into one-file-at-a-time chunks. That’s how everyone reads code in real life. Even senior engineers don’t read codebases — they read files, in order, with a goal.

What “naming a file” actually looks like

A few shapes of the same move:

what does src/lib/progress.ts do?

walk me through src/components/Quiz.tsx — what is it, and what's the shape of its props?

read README.md and tell me how to run this project locally

Notice how the path is always there. No path = Claude guesses. Path = Claude reads.

You don’t need to know the path off the top of your head. If you only know the filename:

find the file called Quiz.tsx and explain it

That works too. The path is better, but a filename is enough to lock the question down.

The thing that trips people up

Newcomers worry that being specific limits the answer. “What if I miss something important by only asking about one file?”

You won’t. Claude tells you when a file references other things — “this imports from ./session, which is where the actual cookie handling lives” — and you can follow up with another sharp question about that file. (We’ll lean into this pattern hard in Lesson 4.4.)

Reading a codebase well is asking one sharp question, then the next sharp question. Not one giant fuzzy one.

What “reading a file” actually is

When you ask Claude to “explain src/auth.ts,” the very first thing it does is open that file and read the lines. That’s not a metaphor — it’s a single command, the reading cousin of the ls and cd you learned in Level 1. cat prints a whole file to the screen. head prints just the top of it — handy when a file is long and you only want its shape.

Try it in the practice terminal. You’ve been dropped into a small project called taskly, the same kind of folder you’d open Claude in. Read the auth file, top to bottom:

cat src/auth.ts

Those are the exact lines Claude reads before it says a word about how login works. Now peek at just the top of another file:

head src/users.ts

That’s the whole trick behind “read this file.” Claude runs this, then explains what it found and follows the imports for you — but the thing underneath the magic is a command you now know. Next time you’re in a real project, ask Claude explain README.md and watch it do exactly this, only faster.

What’s next

Sometimes you don’t even know which file to point at. You only have a name — handleLogin, User.save, useAuth — and no idea where it lives. Turns out you don’t need to. That’s the next lesson.