Let's make this concrete with some math.
For any coding task where you use AI, total time breaks into three parts:
T_total = T_build + T_ai + T_recover
- T_build: Time you spend reasoning, writing, running, refining code changes
- T_ai: Time you spend interacting with the AI (writing prompts, reading answers)
- T_recover: Time you spend rebuilding your mental map after each interruption
What Gets Optimized
Most tools only care about T_ai. They work hard to reduce inference latency. They show benchmarks of how fast a completion appears. They measure suggestion acceptance rates.
T_build is mostly your responsibility as a developer and team.
T_recover barely shows up in any dashboard. Yet it quietly dominates how the day feels.
A Thought Experiment
Tool A: Gives answers in 2 seconds, lives in a browser tab. Every interaction requires copy-paste. Each time you return to the editor, you need to remember what you were thinking, navigate to the right file, adjust the suggestion.
Tool B: Takes 6 seconds to respond. But you invoke it directly in the file you're working on. It sees surrounding code and recent errors. You get a suggestion right in place and can apply it as a patch.
In both cases T_ai is small (2s vs 6s). That's not what decides how your day goes.
The difference is T_recover.
If Tool A causes a 5-minute reorientation every time you use it, and Tool B keeps it under 30 seconds, Tool B will make you feel faster even if its model is less impressive in isolation.
Sarah vs Miguel: By The Numbers
Let's estimate from Chapter 1:
Sarah's breakdown (70 minutes total):
- T_build: ~20 minutes (reading code, making changes, running tests)
- T_ai: ~8 minutes (waiting for responses, reading them)
- T_recover: ~42 minutes (navigating files, remembering context, re-orienting after each alt-tab)
Miguel's breakdown (15 minutes total):
- T_build: ~11 minutes (reading code, making changes, running tests)
- T_ai: ~1 minute (one interaction, quick response)
- T_recover: ~3 minutes (minimal, stayed in flow)
The 55-minute difference isn't AI speed. It's almost entirely T_recover.
That's the hidden cost no one measures.
The Cost of Mode Switching
Behind T_recover is another concept: working modes.
When you collaborate with an AI on code, you move through at least three modes:
Building Mode
- You're inside the system
- Changing code, running tests, adjusting design
- Mental work is deep and continuous
- Holding several constraints in your head simultaneously
- Updating your mental map with each change
Explaining Mode
- You're outside the system, talking about it
- Summarizing the problem, describing architecture
- Copying and trimming code, formatting logs
- Mental work is translation and compression
- Trying to fit a complex picture into a narrow channel
Integrating Mode
- You're comparing what the AI suggests with what you know
- Looking at a patch, considering side effects
- Thinking about style and conventions
- Deciding what to accept, reject, or change
All three modes are necessary. The issue isn't that explaining or integrating are bad.
The issue is how often and how abruptly you're forced to switch.
Every forced jump from building → explaining → building carries a cost. It discards part of your mental map and makes you spend time and energy to rebuild it.
Sarah's tool forced constant mode switching. Miguel's tool minimized it.
You'll feel the difference not only in speed, but in how tired you are after a day of work.