Asking about a file

In Lesson 3.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 a project in Claude on Desktop. Two versions of the same question, both typed into the chat:

Vague:

explain the codebase

Sharp:

explain server/index.js

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 contact form handled in server/index.js, server/messages.js, or somewhere in the HTML?”).
• 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 — each one is a sentence you type into the chat:

what does server/messages.js do?

walk me through server/index.js — what is it, and what does it call?

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 email.js 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 requires ./messages, which is where the actual saving lives” — and you can follow up with another sharp question about that file. (We’ll lean into this pattern hard in Lesson 3.4.)

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

Try it: ask, and read the reply

Reading a file with Claude is a conversation, not a command you memorize. You type a question naming the file; Claude opens it, reads the lines, and answers in plain English — and asks permission before it ever changes anything.

Get the feel for that rhythm right here. Send a prompt and watch the reply come back:

That’s the whole loop behind “read this file.” In a real project you’d swap the prompt for explain server/index.js and Claude would open that exact file, read it top to bottom, and tell you what it found — then follow the imports for you if you ask.

What’s next

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