Best for
- Joining a project and needing the lay of the land fast
- Understanding the module everyone avoids before you must change it
- Explaining your own old code back to you
What you give it
- The code area or flow you need to understand, and what you plan to do with the understanding
What you get back
- A guided explanation from entry point to effect, at the depth you need
- The non-obvious parts decoded: why it is built this way, what breaks if you touch what
- A trap list: the gotchas a newcomer would hit
How it works
- Traces the real execution path from the entry point, reading callers and callees — not just the file you pointed at.
- Explains in layers: the one-paragraph gist first, then the mechanics, then the edge cases.
- Distinguishes what the code does from what it appears intended to do — and flags the gaps.
- Tailors depth to your goal: changing the code needs more than reviewing it.
Example
You: Walk me through how an order goes from 'paid' to 'shipped' in this codebase. I need to add a packaging step.
Result: The flow traced through five files with the state machine explained, the discovery that two background jobs race on status updates (and how the lock prevents it — usually), and exactly where your packaging step should hook in, plus the one place you must NOT put it and why.
Limits — please read
- It explains what is there; lost design intent is marked as inference, not fact.
- Runtime-only behaviour (data-dependent branching) is described with its conditions, not guessed flat.
- A walkthrough is understanding, not endorsement — code smells get named in passing.