Your first real read

You’ve covered the ideas. Time to do the thing.

This lesson mirrors Lesson 1.10 and Lesson 2.8: no new theory, just a run-through where every move from Level 3 gets used at least once. Open a real project in Claude on Desktop. Actually type the questions.

Pick a codebase

You want a project with at least a few files and some actual structure. Pick one of:

• Your own my-site — the running project from this whole course. It has a frontend (index.html, contact.html), a tiny backend (server/), and a real import graph to trace. We’ll use it as the worked example below, so it’s the easiest place to start.
• A project from your team — if you’ve got access to a real codebase you’ve never really read, that’s perfect.
• An open-source project from GitHub — even better for practice, because nothing’s familiar. Some good small ones: a static site, a CLI tool, a Python script you’ve used. Pick something under ~50 files for this lesson. (You can do bigger ones later — Claude scales further than this exercise will.)

To work on an open-source project, you’ll want a copy of it on your computer first. You don’t need to memorize any download command — just ask Claude in the chat:

clone the GitHub repo <paste-the-repo-url> into a new folder and open it

Then point Claude at whichever folder you picked — your my-site, your team’s project, or the one you just cloned. Take a breath. You’re about to map a codebase, end to end, in five questions.

Move 1 — Orient

The first question you always ask. Don’t overthink it:

what is this project? Read README.md and the top-level files, and give me a short summary.

Watch the turn loop you learned in Lesson 1.4: thinking → reading files → answer. Claude will read the README, glance at package.json or its equivalent, and tell you:

• What the project is.
• What language and framework it uses.
• How to run it.
• The shape of the folder structure.

That’s your orientation. You’re no longer staring at a stranger.

Move 2 — One file, asked sharply

Pick a file from the answer that sounds interesting. The one you’d be most curious about. (In my-site, the backend file behind the contact form is a good one.) Now use the move from Lesson 3.2:

walk me through server/index.js. What does it do, and how is it structured?

You’re going from a 30,000-foot view to a single ground-level building. Read Claude’s answer carefully — you should now know, in one or two sentences, what that file’s job is in the project.

Move 3 — One symbol, by name

In that answer, you’ll see function names. Pick one whose job isn’t obvious. (In my-site, handleContact is a good one — it’s the function the contact form hits.) Now apply Lesson 3.3:

explain handleContact. What does it do, and what does it call?

You don’t need to know where it lives anymore. You just know its name. Notice how naturally curiosity drops from file → function → call.

Move 4 — Trace

Pick the most interesting call in that function’s answer — in my-site, handleContact calls sendNotification — and trace it. Use Lesson 3.4:

where is sendNotification defined, and where is it called from? Trace it both ways.

Now you’re building a real mental map. You’ll get back something like: “defined in server/email.js; called once, by handleContact in server/index.js, right after the message is saved.”

In four questions, you’ve gone from “never seen this repo” to “I can sketch how this slice of it works.” That used to take half a day.

Move 5 — Verify

Now you stress-test the answers. Pick the most load-bearing claim from any of Claude’s responses — “sendNotification is called from server/index.js” or “the message comes from req.body”. Apply Lesson 3.7:

quote the exact line where sendNotification is called in server/index.js.

Then open server/index.js — click it in Claude’s file pane, or open it in your editor — and confirm the line is really there, really says that.

If it checks out: you can trust the broader picture. If it doesn’t: ask Claude to look again, and tell it what you found. This is the moment you stop being someone who reads with Claude and start being someone who reads with Claude well.

Optional — the bonus moves

You’ve got time. Try one of these:

Read an error. Find a way to make the project break — ask Claude to introduce a small typo, or run the wrong script. Catch the resulting error, paste it into the chat (Lesson 3.5), and watch it translate.

Read the history. Pick any file you’ve been looking at and ask (Lesson 3.6):

what has changed in this file in the last few months, and why?

You’ll get a tour of the evolution of the file — sometimes more revealing than the file itself.

When you’re done

Close the project and look around. The project that was unfamiliar 20 minutes ago has shape now. You couldn’t draw all of it, but you could draw the slice you investigated — accurately, with the names of real files and real functions in it.

That’s the win. Not “I understand the whole codebase.” That’s a goal that doesn’t exist. The real goal is “I can answer any specific question about this codebase, by reading with Claude.” You can.

What’s next

Level 4: Build with Claude. The training wheels come off again, and this time they come off for real — you’ll make your first real change to a codebase. Everything you just learned about reading is the foundation for changing things well. If you can read it, you can change it. If you can’t read it, don’t.