How it finds things

There is no index of your project anywhere. It finds code the way you would, with search and reading, and that explains a surprising amount of its behaviour.

The capture in lesson 2 is the evidence. The first thing it did was grep. Not an embedding lookup, not a database of your symbols. A text search, run in your shell, against your files, the moment it was needed.

grep -r "short" /tmp/linkshort --include="*.py" | head -20

Then it read the one file that looked right. Two steps, and it had what it needed.

What follows from it

• Nothing is stale. There is no index to rebuild, so it always sees the file as it is on disk right now.
• Nothing was uploaded. Only the parts it read go to the model, not your repository.
• Names matter. A function called next_code is findable. One called helper2 is not.
• Big repositories cost more. Searching is cheap, reading is not, and reading is what fills the context window.

The last point is the one that turns into a bill. A question that makes it read fifteen files costs more than one that makes it read two, and lesson 29 is about working in a repository too large to read.

Helping it find things

You can point it directly at a file, which skips the searching entirely.

claude -p "explain next_code in shorten.py"

Inside a session you can do the same with @ followed by a path, and it will read that file before answering. It is the cheapest way to make an answer better: tell it where to look when you already know.