The Dispatch #61 · May 18, 2026
The Velocity Trap: Why More Output Doesn't Mean More Skill
For engineers who use AI tools daily
You ship more. Your PR count goes up. Your velocity metrics look better than last quarter. You're building features faster, closing tickets faster, shipping faster.
And yet — when something breaks that isn't a normal error, something you've "shipped" a dozen times — you feel a flicker of uncertainty. A moment where you can't quite trust your own read of the system.
The output increased. The understanding didn't.
This week: the velocity trap, why it's so insidious, and what you can actually do about it.
What "Velocity" Is Hiding
Velocity is a measure of output per unit time.
What it doesn't measure:
- Whether you understand the output
- Whether the problem-solving capability that generated it lives in you or in the tool
- Whether you'll be able to solve the same problem without the tool next time
- Whether your mental models of the system are getting richer or shallower
When AI handles the middle of the work — the debugging, the edge cases, the optimization passes, the "why isn't this working" sessions — your velocity increases. Your actual problem-solving capability might be decreasing.
The Mechanism — Why This Happens So Fast
AI reduces the friction that generates learning
The struggle with a hard problem is where learning happens. Not the answer — the struggle. When AI removes the struggle, it removes the condition for learning. You get to the answer faster. You skip the part that would have built the mental model.
"Friction is a feature" — the difficulty of retrieval strengthens the memory. Ease of retrieval weakens it.
AI generates confidence without requiring comprehension
When AI explains something confidently, with clear reasoning and clean code, your brain accepts the explanation as understanding. But understanding something that was explained to you is not the same as understanding something you figured out through struggle. You can follow the explanation. You can nod along. You can even reproduce it. But the deeper structure doesn't transfer.
The feedback loop rewards velocity, not depth
Your team's velocity metrics go up. Your code review is faster. Your PRs ship faster. The feedback loop is designed to reward production. It has no signal for whether your mental models are getting stronger or weaker. The trap closes. The velocity keeps going up. The depth keeps going down.
The Cost Nobody Talks About
The real cost of the velocity trap isn't lost productivity. It's latent risk.
The knowledge mirage: You know more than you did two years ago — in the sense that you've seen more solutions, worked on more systems, reviewed more code. But you know less in the sense that actually matters: can you solve novel problems in this domain without AI?
What you know feels like understanding. But it's recognition, not comprehension.
The backup failure: The engineers most vulnerable to the velocity trap have one thing in common: they can't tell you, in their own words, without an AI tab open, how their system actually works. Not because they're bad engineers. Because the AI handles the parts that used to build that understanding.
The compounding invisibility: Skill atrophy from AI isn't dramatic. You don't wake up one day unable to code. You wake up one day unable to debug something that would have been routine two years ago — and you can't pinpoint exactly when it happened. The velocity trap compounds quietly. Until it doesn't.
The Calibration Test
Here's the test worth running monthly:
Pick one feature you've shipped in the last 30 days. Without looking at the code or any AI tools:
- Can you explain why the architecture decisions were made the way they were?
- Can you identify the three most likely failure points, and why?
- Could you debug a production issue in this feature at 2am without AI?
If you can answer all three confidently: you're probably in better shape than most.
If you can answer one or two: the velocity trap has a grip.
If you can't answer any of them: the code shipped, but the understanding didn't.
What Actually Changes the Trajectory
The fix isn't to use AI less. That won't stick and isn't the real goal.
The fix: be deliberate about when you're learning and when you're producing.
The Split Practice
With AI off — or AI as a teacher rather than a collaborator — and some is production. The production work can use AI freely. The learning work needs friction.
After any AI-assisted session, spend 5 minutes writing in your own words what you did and why it worked. Without the AI's framing. Without the code open. If you can't: that's your gap. That's the work.
Once per quarter, take a medium-sized problem you've been working on with AI for several weeks. Solve it for one hour without AI. Don't look at the AI's previous solutions. Work from first principles. Measure: how far did you get? Where did you get stuck? How did it feel?
If this described something you've been feeling: the AI Fatigue Quiz takes 90 seconds and maps where your understanding has drifted from your unaugmented capability. Free. No email required.
Take the AI Fatigue Quiz →Skill Atrophy
The slow erosion of generative capacity when origination is outsourced.
Productivity Theater
When AI makes you busy, not better — and how to spot the difference.
Cognitive Load
Why your mental bandwidth is finite — and why AI doesn't actually expand it.
Daily Practice
The micro-habits that maintain skill while using AI freely.
Velocity is a metric. Understanding is a capability.
Metrics are easy to optimize for. Capabilities are hard to maintain.
The trap is optimizing the metric at the expense of the capability.
Measure both.
P.S. If you've been meaning to share The Clearing with a colleague who feels like they're running faster but getting shallower — this is the week.