Lesson 3.3 gave you the unit of curiosity: the symbol. This lesson gives you the move that connects symbols to each other.
“Where does this come from?” and “where is this used?” are the same question, asked in two directions. Both used to take experienced developers an hour of manual searching. Now they take a sentence in the chat.
If there’s one chapter in this level to internalize hard, it’s this one.
The two directions of tracing
Code is a web. Almost everything in a codebase connects to something else: a function calls another function, a variable is set in one place and read in another, a value flows from the database through the backend to the frontend and onto the screen.
When you want to understand any piece of that web, you have two natural questions:
- Where did this come from? — backward, toward the source.
- Where is this used? — forward, toward the consequences.
Both questions used to be hard. Now they aren’t.
Where does this come from?
You’re reading saveMessage in server/messages.js and you see it’s handed a msg object. Where did that come from? You don’t have to scroll. Ask:
where does the msg that saveMessage receives come from? Trace it back.Claude will follow the trail: maybe it’s read from a file. Maybe it’s passed in from a parent function. Maybe it’s built from a web request. The answer is a chain — “it’s built in handleContact in server/index.js from req.body — the name, email, and message a visitor typed into contact.html — then passed into saveMessage.”
That chain is a real mental model of how the code is wired. You couldn’t have read it linearly. Claude assembled it for you.
Where is this used?
Now flip it. You’ve understood a function. The next question is who depends on it? — because that’s what tells you whether changing it is safe.
what calls sendNotification? List every file and what it does with the result.You’ll get an answer like: “one caller — handleContact in server/index.js, which calls it right after saving the message, and ignores the return value.” That’s gold. You now know:
- What changes if you break this function.
- Whether your change needs to keep the same return type.
- That there’s exactly one place sending email, so changing how email works is a one-file job.
This is the question senior developers ask before every refactor. It’s the question that separates “I’ll move this function around” from “oh no, I just broke production.”
The hour of searching that turned into a sentence
Before agents like Claude, tracing was a job. You’d open the project in your editor, run text searches, follow imports manually, open four files at once, keep a mental stack of “and this is called from here, which is called from here…” If the codebase was unfamiliar, an hour could disappear into one trace.
The thing this lesson is really about: the cost of curiosity has dropped to nearly zero. Trace everything. Trace twice. Trace when you don’t even need to. It used to be expensive, so people skipped it. Don’t.
A few more shapes worth knowing
Tracing data backward:
where do the messages in messages.json actually come from? Trace it back to the form.Tracing data forward:
when a visitor submits the contact form, what happens? Walk me through every function that runs, in order.Tracing imports:
what does server/index.js require, and what does each one do?Finding where something lives:
where in this project does the email actually get sent?Different questions, same shape: start at one point, follow the wire.
The thing that trips people up
You’ll be tempted to ask Claude “is this function used anywhere?” and trust a yes/no. Don’t. Always ask Claude to list the callers — file by file. Two reasons:
- “Yes, it’s used” tells you almost nothing. The list is what’s actionable.
- A list is checkable. You can open one of those files in a few seconds and confirm Claude found a real caller — not an imagined one. (More on this in Lesson 3.7.)
A trace you can’t verify isn’t a trace. It’s a story.
Try it: one prompt, the whole trace
Tracing in Claude is just another sentence in the chat — except this one sentence does what used to take an hour of opening files. You ask where something comes from and where it goes; Claude reads every hit and hands you a chain, not a wall of line numbers.
Send a prompt and watch a request turn into a plan and a result:
In a real project you’d type where does sendNotification come from, and what uses it? and Claude would answer in one line — “defined in server/email.js, called once by handleContact in server/index.js” — a list you can act on, both directions at once. Then take it further: pick a variable you don’t recognize and ask where it comes from; pick a function and ask what calls it. One question, then the follow-up. A mental map in three minutes that used to take an hour cold.
What’s next
Tracing helps when the code is working but unfamiliar. The other half of reading is when the code is broken — when you’ve got a wall of red error text and no idea what it means. That’s the next lesson.