The Distance Between Knowing and Doing
issues of The Dispatch
There's something that happens around issue 100 of a publication that makes you want to say something honest.
You've been here for a while. You've read the pieces on skill atrophy, the research on attention residue, the data from the quiz that 500+ engineers have taken. You know the patterns. You can name the feeling — the middleman feeling, the velocity trap, the Sunday night dread. You've got the vocabulary now.
And maybe nothing has changed.
That gap — between knowing and doing — is the thing this issue is about.
The Knowing-Doing Gap in AI Fatigue
Most of the engineers I talk to aren't confused about what's happening to them.
They know the Sunday scaries are worse. They know they're not learning anymore — that AI is handling the hard parts and they're handling the approvals. They know their debugging skills are getting soft. They know they're tired in a way that sleep doesn't fix.
They know. And they're still stuck.
This is not a motivation problem. Calling it a motivation problem is the way the industry talks about everything — "just do it," "just set boundaries," "just take breaks." As if the engineer who's been shipped 40 features this quarter and watched three colleagues get laid off is going to solve their structural problem with a bedtime.
The knowing-doing gap in AI fatigue isn't about information. It's about context.
Why Knowing Isn't Enough
Here's what happens: you read something that describes your exact experience, and for about twenty minutes you feel understood. That felt like progress. You saved the article. You meant to come back to it.
The feeling fades. The context doesn't change.
The context is: your team has an AI mandate. Your company measured velocity this quarter. Your manager asked why your estimates haven't improved now that you have Copilot. Your CTO said "we need to ship twice as fast." Your peer got promoted for using AI aggressively while you were trying to be deliberate.
None of those things changed because you read a good article.
This is why information alone doesn't close the gap. The gap is structural. It's in your calendar, your team norms, your company's definition of productivity, your manager's incentive structure. Changing it requires more than reading. It requires a conversation, a boundary, a decision to do something different, and enough slack in your system to actually follow through.
Most people reading this don't have the slack.
What Actually Moves the Needle
In 100 issues of The Clearing, a pattern has emerged about what actually helps engineers who are stuck in the knowing-doing gap.
Not a new framework
The engineer who's read 40 articles on AI fatigue doesn't need a 41st framework. They need to do one thing, consistently, for three weeks.
Not more information
You already know more than you need. The question is whether you're doing anything with it.
Not a dramatic change
The engineers who close the gap do one thing differently — one conversation, one boundary, one protected hour, one no-AI session per week.
Here's the one-change I've seen work most often: the Explanation Requirement.
The practice: Before you ship any significant AI-assisted code, write one paragraph explaining why each major decision was made — not what the code does, but why the decisions were made that way.
If you can't write it, that's the gap. That's your curriculum.
It takes ten minutes. It doesn't require changing your team's AI policy or having a hard conversation with your manager. It just requires you to stay in contact with the difference between shipping and understanding.
The Question Worth Sitting With
If you've read 20 issues of The Clearing and nothing has changed, ask yourself this:
What's the one thing you know you should do that you're not doing?
Not the five things. Not the whole recovery plan. The one thing.
Now ask: what's the actual obstacle to doing that one thing? Not "I don't have time" — what's the real thing?
- Is it that saying no would require a conversation you're avoiding?
- That protecting one hour would mean missing something visible?
- That doing the work without AI would make you slower and you don't have political cover for slow?
The obstacle is usually not the action. It's the context around the action.
So change the context. Get the cover. Have the conversation. Define the boundary before you need it.
Or don't — and keep reading, and keep knowing, and keep feeling like something's off.
One More Thing
Issue 100 is a strange milestone. Most publications don't make it here. Most things don't.
The ones that do tend to be the ones that figured out what they were actually for. For us, it's this: we're here to give you the language for what's happening, the research to back it up, and the practical things that actually help — so that you can close the gap between knowing and doing, one decision at a time.
Thank you for being here for 100 issues. That's not nothing.
The next one is already in progress.
— Jeez 🤙
How to Follow Up This Issue
If you only do one thing: Go read the AI Boundary Builder — it's a 5-question interactive tool that gives you a concrete picture of where your AI boundaries are and aren't. Takes 3 minutes.
If you want to understand the research: The Explanation Requirement has a full evidence base at research.html — including the Bainbridge (1983) "Ironies of Automation" paper that predicted most of what we're living through now.
If you want to see where you stand: Take the AI Fatigue Quiz — 5 questions, 4 tiers, honest results. 500+ engineers have taken it. Most land in the middle tiers. The top tier isn't a badge of honor — it's a signal to pay attention.
If you want to talk: The recovery guide has the full structured approach — start at Week 1 if you're not sure where you are.
This Week's Data Point
From 500+ AI Fatigue Quiz responses:
"I feel like a middleman in my own work."
That's the #1 theme — more common than skill loss, more common than velocity anxiety. Not imposter syndrome (that's about confidence). This is an ownership problem: the code shipped, the feature works, but the engineer has lost contact with the authorship.
The middleman feeling is a signal, not a sentence. It means the work changed, not that you did something wrong. The question is what you do with it.
Forward this to an engineer who gets it.
Subscribe to The Dispatch