A few weeks ago, my friend Sandy Sanchez published an article that stopped me mid-scroll. She’d been thinking about something that I’d been noticing too, but hadn’t quite found the words for. It’s a growing feeling that the more efficient we get, the more exhausted we somehow become.
She opened with a wedding. A few days away from screens, deliverables, and Slack notifications. Just people, food, music, and the kind of unscheduled time that’s started to feel almost foreign. She described coming back to a pile of emails with a guilt that surprised her. Not guilt about the backlog itself, but guilt about the fact that she hadn’t thought about the backlog at all while she was gone.
I was at that wedding.
I lived that exact re-entry. And I had the same moment of “wait, when did being fully present start to feel like a mistake?”
Sandy’s piece got me thinking about all of this from a developer’s perspective because, well, I am one, and I’m at the center of it in a way most people aren’t.
I’m building with AI tools every day, shipping faster than I used to, and also living with what that speed actually costs.
I’ve been watching a specific pattern repeat long enough that we need to talk about it 👇
Why AI Saves You Time But Doesn’t Give You More of It
The promise of AI we all heard was simple: automate the tedious stuff, save time, and have more room to breathe.
It does save time.
Very recently, I built and shipped a Flutter app called VersoID. That project happened because of AI, and I mean that in a very specific way.
Before AI tools were part of my workflow, picking up a new tech stack like Flutter would have been a real commitment, not a weekend project, not something I could fit alongside everything else. The idea would have stayed an idea because the time cost was too high.
AI changed that math. I could move through unfamiliar territory fast enough that starting the project actually made sense.
So the time savings are real. No question.
But saving time doesn’t create space. It creates capacity. And capacity, in most work environments, gets filled immediately 😅
A Harvard Business Review study from earlier this year tracked employees at a tech company over eight months with in-person observation, internal channel monitoring, and 40+ interviews across engineering, product, design, and operations. AI users worked faster, took on more tasks, and pushed their work into more hours of the day. Not because they were forced to, but because the work felt easier to move forward, so they kept moving it.
The word the researchers used was intensifies.
Not reduces. Intensifies.
That’s exactly what I keep seeing.
Finish a feature faster? Here are three more tickets.
Ship ahead of schedule? Great, what can we pull forward?
The backlog doesn’t shrink; it just adjusts to whatever pace you’re running at.
Why Shipping Faster Just Means More Work (Not Less)
There’s an economic idea called the Jevons Paradox that explains this better than I can.
In the 1800s, economist William Stanley Jevons noticed something strange about coal: when steam engines got more efficient, people didn’t use less coal—they used more.
Since efficiency made coal cheaper to use, it got used in more places, for more things. The savings got reinvested straight back into consumption.
Developer time works the same way.
When you can ship faster, building things gets cheaper. And when building gets cheaper, more things get built. More features get scoped, and more side projects become realistic. More requests feel reasonable to say yes to.
The time you saved doesn’t come back to you because it goes straight into new work.
I saw this happen with WP Agent, a custom MCP server I built for my team. It was meant to make our day-to-day development smoother (which it does). But the moment it worked, the question was immediately: okay, what can we do with this now?
New projects. New requirements. More iterations. I built a thing to make work easier, and what it actually did was make more work possible.
You didn’t get more room. You got a bigger room to fill.
And the ironic part is that the work filling that room is harder.
Moving faster with AI means making more decisions, reviewing more output, and context-switching between more things at once.
You’re not just doing more. You’re doing more of the cognitively heavy part.
When You Ship More But Know Less
This next part is a little uncomfortable to admit.
When AI is writing more of the actual code, things like structuring the logic, generating the boilerplate, and scaffolding the solution, you can start to lose your grip on what you actually built. We’ve talked about this before on THT.
There’s nothing wrong with the output. The output is fine. What slips is the understanding that only comes from writing the thing yourself.
The normal rhythm of building something goes like this: you sit with the problem, write the code piece by piece, hit a wall, debug it, figure out why, and try again.
That whole messy cycle is where you actually learn. It’s where the thing stops being something you read about and starts being something you know.
In fact, that cycle is also where the satisfaction lives. The part that makes you feel like you actually built something when it’s done is that slow, frustrating, figuring-it-out part 💁♀️
When AI handles the crafting, you can skip straight to an answer. But you can also skip straight past that feeling.
You end up reviewing code you didn’t write, for a system you didn’t fully design, in a codebase you could describe but maybe couldn’t diagram from memory.
The result exists. Your relationship to it feels, shall we say, a tad distant.
I’ve done this. Accepted a solution that looked right, shipped it, and then weeks later had to re-learn how it worked because I’d never really learned it the first time.
That gap between what you shipped and what you actually understand is its own kind of debt. Let’s call it cognitive debt. And unlike a TODO comment you mean to fix, it doesn’t sit still. It compounds.
Note 👀
None of this is an argument against using AI tools. I use them all the time. The point is that the process of building is where a lot of the value lives and it’s easy to accidentally trade that away for speed without noticing.
Related: Am I Still a Developer If I Didn’t Write the Code?
Why You Can’t Just Opt Out of the AI Productivity Pressure
You can’t individually decide to step off this treadmill.
If your team ships 40% faster with AI tools and you don’t use them, you don’t go back to your old workload. No, you fall behind it.
The sprint velocity was adjusted. The stakeholder timelines were tightened. Everyone else’s baseline became your new bar, whether you opted in or not.
This is what Sandy was pointing at when stating that busyness has stopped being a personal choice and started being a condition of the environment. The phrases she flagged have become so normal that nobody even registers them anymore:
“Sorry, we know it’s a lot.”
“Do what you can.”
“We’re booked out for four months.”
Almost everyone is saying this. Almost everyone is hearing it. That’s not a handful of overcommitted people—that’s the baseline.
When the baseline is overwhelmed, the problem isn’t individual time management but something in the system itself changed.
There’s also a quieter version of this that I think a lot of developers feel but don’t name: you have access to more tools, more libraries, more AI capabilities than ever before, and somehow that abundance makes it harder to feel drawn to any of it.
Everything is available, everything is one prompt away, and yet at the end of the day, you close the laptop feeling vaguely grey.
Not burned out exactly. Just not particularly lit up either.
For developers specifically, there’s an extra layer: it’s not enough to keep up with your current workload. You’re also expected to keep pace with the tools themselves, from new frameworks to new AI capabilities and workflows that didn’t exist six months ago.
Just staying competent means running to stay in place.
The treadmill isn’t running at your pace. It’s running at its own pace, and the setting isn’t in your hands.
What Actually Helps (That Isn’t More Productivity Advice)
I don’t have a clean solution. Anyone who says they’ve cracked this probably works alone and doesn’t have a sprint board.
But a few things have actually made a difference for me, and none of them are the usual “block your calendar” advice.
One is protecting the slow work. There are parts of building I try to do by hand, even when I don’t have to. Not because it’s faster (it never is), but because that’s where I actually learn something. Writing a function from scratch instead of prompting for it. Reading through a library instead of asking for a summary. It keeps me connected to the craft in a way that matters, even if it doesn’t show up anywhere measurable.
Related: Here Is An Easy Active Guide To Beating AI Burnout
Another is catching the expansion impulse before it lands. Every time something ships, be it a tool, a feature, or a project, there’s a beat right after where the question becomes: okay, what’s next?
That beat is worth pausing on. Not to say no, but to notice that the question arrived before the last thing was even fully absorbed. If you don’t catch it, you’ll be three projects in before you’ve had a chance to ask whether the first one did what you wanted. (I’m extremely guilty of this 😬)
And the third is actually disconnecting. Sandy’s piece resonated with me partly because I was there, but also because I know how uncommon that kind of presence has become.
Fully stepping away, not “quick check,” or “just making sure nothing broke,” is something I have to choose now. It’s not something that just happens. If you came back from a long weekend feeling guilty for being unreachable, that guilt is worth reflecting upon.
Tip 💯
That guilt isn’t really about what you missed. It’s a signal about what you’ve started treating as your default responsibility. You’re allowed to renegotiate that.
Are We Moving Faster Toward Something Worth Reaching?
Sandy’s article ends with a question I haven’t been able to shake, and that is:
We’ve gotten incredibly good at moving fast. What we’re not as good at is stopping to ask what we’re actually moving toward.
I think a lot about this with my own work.
Am I building something because it solves a real problem, or because I have the capacity and building is what I do with capacity?
Am I shipping because it matters, or because the tools have made shipping easy?
Those aren’t always comfortable questions to sit with, and I don’t always have clean answers.
They come up for personal projects, where filling capacity is a “waste of time”, as well as with work projects, where discussing what matters becomes its own skill.
Speed and efficiency aren’t the problem. The problem is when they become the point, when moving fast stops being a means to something and becomes a habit.
It’s a Wrap
Nobody in tech is slowing down anytime soon. The tools keep getting faster, the backlogs keep refilling, and the baseline keeps adjusting.
That’s just the current state of events.
However, it’s worth noting what’s actually happening:
- Efficiency isn’t freedom
- Shipping more isn’t the same as doing better work
- Feeling guilty for being fully present somewhere is a signal, not a character flaw
Sandy’s article made me think about that wedding differently. Not as days off, but as proof that some of the best things don’t compress.
You can’t optimize a dinner with people you love.
You can’t speed-run the moments that matter.
Some things are worth exactly as much time as they take.
That’s not a productivity failure. That’s the point.
Go touch some grass. The backlog will still be there 🌿
