To understand why Sarah's day felt so painful and Miguel's felt smooth, you need a clear picture of what's happening inside a developer's head while they work.
When you're deep in a coding session, you're holding a large, delicate map in your mind. This is your cognitive stack.
It has four layers:
Layer 1: Problem Context
Everything that answers: What are we really trying to do?
- The user story or ticket
- The bug you're chasing
- Constraints from other teams
- Performance and security expectations
- Edge cases that product cares about
- "We can't break this customer flow right now"
This layer connects the code to the real world. It's why you're writing this particular thing in this particular way.
Layer 2: Code Context
Your understanding of the system as code, not as a story:
- File structure and module boundaries
- Function signatures and data shapes
- Invariants that aren't documented but are real
- Idioms and patterns considered normal in this codebase
- Places known to be fragile
- "This looks weird but it's handling a race condition from 2019"
Some of this lives on disk. Much of it exists only as "things you're currently holding in your head."
Layer 3: Runtime Context
The state of the system as it runs:
- Logs in a terminal
- Failing tests and stack traces
- Local state in a debugger
- Responses from a test API call
- A quick experiment in a REPL
- "When I pass null here, this other thing happens"
This context is short-lived and volatile, but during debugging it's often the most important layer.
Layer 4: Social Context
All the human and process knowledge that affects decisions:
- Who wrote this module
- What shortcuts were taken under deadline pressure
- Which parts are frozen until after launch
- What reviewers usually push back on
- Which patterns are acceptable even if not perfect
- "We tried that approach last year and it created production issues"
This layer is why two codebases with identical code can feel completely different to work in.
The Map Is Powerful and Fragile
Together, these four layers form a high-bandwidth mental map. When it's intact, you can jump effortlessly:
- From a log line to a function
- To another file
- To a product concern
- To a colleague's comment on a pull request
You don't have to spell out the connections. They're cached in your working memory.
But this map is fragile. Think of it as an L1 cache in your mind. It's fast and close to your thought process, but it's limited in capacity and easy to flush.
The moment you break focus, you risk losing part of it.
What Happens When You Alt-Tab to AI
Look at what Sarah had to do in Chapter 1:
- Leave her editor
- Open a browser
- Explain her problem in a chat box
- Translate her entire mental map into linear text
The structure gets lost. The bits she forgets to mention simply vanish from the model's world.
She's moved from holding a rich internal model to acting as a serializer.
That's the first leak of the context tax.
The Ping-Pong Effect
There's a second leak: repeated bouncing between environments.
Sarah's loop:
- IDE → encounter problem
- Browser → ask AI for help
- Browser → construct prompt, paste code, explain context
- Browser → wait, read response
- IDE → apply suggestion
- IDE → find it's wrong or incomplete
- Browser → adjust prompt, repeat
IDE → chat → IDE → chat → IDE → chat
This is the Ping-Pong Effect.
Each hop does two things:
First, it pushes you out of building mode and into explaining mode. You stop reasoning about the system and start writing prose about it.
Second, it makes your mental map decay. When Sarah came back to her editor, she often needed to scroll, re-read, and reconstruct her understanding. Even if this takes only a minute or two, that's a minute or two where she's not actually changing the system.
Why We Accept This
We treat this as normal because we've accepted chat as the default interface for AI. It feels familiar. It's easy to demo. It looks like asking a smart colleague for help.
But it's a terrible fit for deep technical work.
By making the developer act as the data bus between editor and model, we're spending human focus to save computer effort.
That trade is backwards.
Miguel's tool did the opposite: it spent computer effort (scanning files, parsing logs, reading config) to save human focus.
That's the correct trade.