Humans Are Bottlenecks. That's the Point.
Friction isn't the enemy of quality. It's how quality happens.
The software industry has been on a mission to remove its bottlenecks. Slower developers. Code review. Human judgment. The painful friction between “here’s what the ticket says” and “here’s what actually ships.”
AI makes this mission feel achievable. Finally, we can get the bottlenecks out of the way.
There’s one problem with that goal: the bottleneck is the point.
When a senior developer reviews a pull request and stops cold with a “wait, what is this doing?” that pause is not a failure of the process. It’s the process working. Confusion is data.
The fact that something took twenty minutes to understand when it should have taken two means something is wrong with what was written.
Pain is information.
A developer who reads code and feels nothing, who zips through review at the same speed regardless of what the code actually contains, is either reviewing code they can read in their sleep, or they’ve stopped seeing it.
The friction of reading someone else’s code: the slowness, the occasional what the hell were you thinking. That’s not inefficiency. That’s the quality signal. You need it. Your team needs it. Your production environment at 2am really needs it.
Now remove the human.
Automated agents don’t feel confusion. They don’t slow down when something is wrong. They don’t stop at a function name that seems slightly off, or a comment that doesn’t quite match the implementation, or a change that seems fine in isolation but is going to blow up the integration test they can’t see from here.
They ship. Confidently. Quickly.
And when it breaks, nobody can read the codebase, because nobody wrote the codebase.
The industry heard “bottleneck” and heard problem. They heard slow. They heard blocker. They heard something to engineer around.
What they missed is what every developer who’s debugged anything already knows: the moment you finally understand the bug is the moment the pain stops. You weren’t stuck because you were bad at your job. You were stuck because the system was telling you something. The confusion was trying to hand you information. The moment you stopped fighting the friction and started listening to it, that’s when you found it.
Removing friction from the development process isn’t removing inefficiency. It’s removing the feedback loop that tells you when something is wrong.
That’s a different problem. A worse one.
The Stoics weren’t advocating for suffering as an end, they were observing that difficulty is how you build the capacity to handle difficulty.
This is not abstract philosophy. It’s a practical observation about how human beings develop judgment.
A developer who has spent five years fighting confusing code. Writing it, breaking it, fixing it, reading other people’s worst commits at the worst possible moments, has built a model of software systems that lives in their head. It’s not in any book. It’s in the scar tissue.
That model is what catches the null check at code review before it becomes the null check in production.
AI didn’t form the model. You did. Through years of friction.
You are the bottleneck. The bottleneck is the model. The model is the thing no one can replace.
Here’s what worries me about the current trajectory.
We’re building a generation of developers who are going to miss the formation that produces the model. Not because they’re lazy. Because the environment removed the conditions that produce it.
You can’t shortcut the frustration. The frustration is where learning happens. Every hour a junior developer spends confused by a codebase they didn’t write is an hour they’re building the mental map they’ll spend the next twenty years navigating by.
Pull AI into that loop too early, and the confusion disappears. Not because the developer understood it. Because the AI resolved it before the confusion could do its work.
That’s not a win. That’s a generation of developers who reach senior titles without ever building the model that makes the title mean something.
I’m not arguing against using AI. I use it. I’ll keep using it.
What I’m arguing is this: understand what you’re the bottleneck for.
You’re not the bottleneck because you type slowly. You’re the bottleneck because your judgment, earned through years of watching things go wrong in predictable and completely unpredictable ways, is the mechanism that catches problems before they compound.
Voluntary discomfort isn’t just a Stoic practice. In this context, it’s professional maintenance. Writing code by hand when you could have AI write it. Reading unfamiliar codebases when you could have AI summarize them. Staying in the difficulty long enough to understand it instead of optimizing the difficulty away.
Because the moment you outsource the hard reading, the slow thinking, the uncomfortable pauses.: you’re quietly maintaining less of the thing that makes you valuable.
You don’t feel it for a while. And then you need the model and it’s not there.
The bottleneck is the feature.
Pain is information. Confusion is data. The friction in the development process—the human kind, the slow kind—is what separates shipped from good.
Own being the bottleneck. It’s the best thing about you.
Quote of the Day:
“The impediment to action advances action. What stands in the way becomes the way.” - Marcus Aurelius
👉 If you enjoy reading this post, feel free to share it with friends!
Or feel free to click the ❤️ button on this post so more people can discover it on Substack 🙏
You can find me on X and Instagram.
Also, I just launched a new YouTube channel - Code & Composure



I have read some of your posts about using AI as a tool to speed up work, as well as the risks that excessive use can decrease judgment and this post is also really nice. Your posts are truly inspiring and offer valuable insights. Please keep up the good work.