Read code as a map, not a tree

You clone a new repo. npm install. npm run dev. It works.

Now you have to actually read it.

The file tree opens. 47 folders. 312 files. Some named utils, some named lib, one called core and another called kernel (you suspect they overlap). Where do you start? Probably index.ts. After 20 minutes you've drifted three folders deep, you have 11 tabs open, and you still don't know which function is the entry point for the bug you came to fix.

The file tree is showing you where files are stored, not how the code actually moves.

A different unit

Cockpit's new Code Map switches the unit. Instead of "files in folders", you see functions, with their connections.

Every function becomes a card on the canvas:

• The body — the actual code, syntax-highlighted — sits in the middle.
• On the left: every function that calls this one. (Callers.)
• On the right: every function that this one calls. (Callees.)
• Each entry on either side is clickable. Click and the canvas pans to that function.

That's the whole interface. The file tree is still there if you want it. But the moment you click into a file, you don't see "lines 1–840 of payment.ts." You see four chips: chargeCard, refund, webhookHandler, recordLedgerEntry — each with their own incoming and outgoing arrows.

Day one in a new repo

This is the moment Code Map was built for. You join a project at 9am. By 10am you're supposed to "have a look at the auth flow." With the file tree, that's a 90-minute scavenger hunt. With Code Map:

1. Open the file you suspect is the entry point — routes/auth.ts.
2. The five route handlers each appear as their own chip.
3. Pick the one you care about: loginHandler. Its chip lights up.
4. The right column shows it calls validateCredentials, issueToken, recordLogin. Click validateCredentials.
5. The canvas pans. Now validateCredentials is the centre chip. Its callees are hashPassword and lookupUser. Its callers — left column — show you it's also called from resetPassword, which you didn't know existed.

In five clicks you've walked the auth tree. You haven't grep-ed for "login". You haven't gotten lost in utils/index.ts. The map you needed was always there in the code — you just needed someone to draw it.

Following a call you don't trust

This is the thing every senior engineer secretly does and no junior is ever taught: when you're not sure why a function is being called, you walk up the call chain until you understand the entry point.

The traditional way is grep + intuition. grep -r 'createOrder' returns 23 hits. 19 are in tests. 2 are in comments. 2 are real call sites. You open both, scroll around, try to figure out which "happens first."

In Code Map, createOrder's left column is the answer. Sorted, deduped, no test files unless you want them. Click each one to see the actual line. The whole "where does this get called" question is a 10-second visual inspection instead of a five-tab dig.

Reviewing AI-generated PRs

You asked Claude to "fix the rate-limiter bug." It produced 8 file changes across 3 directories. The diff looks reasonable. You hit Approve.

You shouldn't.

Switch the same files into Code Map. Now the diff isn't a list of +/- lines — it's a chip view where the changed functions are highlighted, with their callers and callees still drawn around them. You can immediately see:

• The agent edited rateLimit. Its callers are apiHandler and webhookHandler. Did the change break the webhook path? Click the webhook caller, read the chip, done. 30 seconds.
• It also touched getClientIp, which has eleven callers — half of them in the auth subsystem. The agent didn't mention this. You probably want to read those eleven before approving.

For PRs you wrote yourself, this is overkill. For PRs an agent wrote at 3am while you were asleep, this is the difference between "I trust it" and "I should trust it."

Tracing a bug across files

A user reports: "Sometimes when I refresh, the cart loses one item." You have a guess: something racy in syncCart. Open syncCart in Code Map.

Five callees. One is fetchCart. Two are flavours of mergeCart. One looks fishy: dedupeItems. Click. Its body shows a Set keyed on id — but the bug report mentions duplicate ids with different sizes. Found it.

Three clicks. No grep. No "open ten files in tabs and scroll." The map made the buggy node visible because the chips next to it were the right context.

On the train, no LSP, no problem

Code Map runs on your laptop, parsed by tree-sitter. No language server, no project index, no background daemon. Open a folder, get a chip view. Close your laptop, fly to Berlin, open it on the plane — same chip view, no indexing wait.

This matters more than it sounds. LSP-based tools (VSCode's "find references", JetBrains' "show callers") all need a fully booted project: tsconfig resolved, pip install done, go.mod complete. Code Map skips that. It reads your files the way a careful human reader would. If they parse, you get a chip view. That's it.

It works on TypeScript / JavaScript, Python, Go, Rust today. As a user, that's all you need to know.

When not to use it

To be fair: Code Map isn't trying to be your editor. If you're writing new code, you're in the regular Explorer with a cursor and the LSP popping up types. Code Map is for the moment before you write — when you need to read first.

A useful split:

• File tree + editor — when you know what you're changing and where.
• Code Map — when the question is "what calls what, and where do I start?"

You'll toggle between them all day. Both views look at the same files. They just answer different questions.

Try it

Open Cockpit, go to Explorer, open any source file, hit the Code Map toggle. The chip view replaces the editor pane — same file, different lens. Click a callee pin to fly to the next function. Toggle back when you're done.

That repo you've been meaning to read since January? It's a five-minute walkthrough now.

---

npm i -g @surething/cockpit · GitHub · Try Online