The Floor is Rising
Most engineers I know are shipping faster than ever and feeling worse about it. I've been trying to figure out why.
I’ve spoken to a handful of engineers over the last few months, friends and mentees mostly, and the prevailing sentiment is one of low-grade unease that nobody has quite managed to name. Everyone is shipping faster than ever, everyone is amazed by what tools like Claude Code and Cursor can produce in an afternoon, and everyone has this persistent feeling that something important is missing from the work.
This is my attempt to name it.
What Actually Changed
The commodity work is gone, and if we’re honest with ourselves, we knew it was commodity work long before the tools made it obvious. CRUD apps, the same frontend libraries reaching for the same patterns, the same database choices, the same infrastructure boilerplate reproduced across thousands of codebases; we built the assembly line for our own automation without really noticing we were doing it. We called it engineering, and a lot of it was factory work wearing engineering’s clothes.
What the Commodity Work Actually Cost Us
The obvious cost was time, but the less obvious cost was mental capacity, and that’s the one that matters more for what comes next.
You cannot context-switch from firefighting tickets into ambitious thinking, because those are different cognitive modes that require very different conditions to access. Getting into genuinely ambitious thinking requires a kind of warmup, a sustained period of low-interruption time, that simply never materialized when the sprint was already overcommitted and production was on fire. Most engineers weren’t timid about what they wanted to build, they were chronically stuck in the wrong gear with no realistic path to shift, and the commodity work wasn’t just filling their calendars, it was occupying the mental space where harder questions might otherwise have lived.
The Collapse of Opportunity Surface
Here’s what I think is actually driving the unease that engineers are feeling right now: sitting in front of Claude Code clicking “accept” all day gives you nothing to push against, and without something to push against, your opportunity surface collapses.
The struggle of building software wasn’t just a character-building exercise or an obstacle between you and the finished product, it was the primary mechanism by which you found the edges of your own understanding. A broken CI run at 2am, a production incident you didn’t anticipate, an architecture decision that came back to haunt you three months later, these were unpleasant experiences but they were also information, and that information showed you where you didn’t know what you thought you knew. That’s where new directions came from, where you discovered what you wanted to learn next and what problems you found genuinely interesting. Remove that friction entirely and you remove the feedback loop, and without the feedback loop you stop developing a sense of what you want to build next. That’s why engineers feel lost right now, and it has less to do with grief over lost craft than it does with the disruption of the mechanism that used to generate direction.
The struggle served a second purpose, one that’s easier to miss. It wasn’t just a feedback mechanism, it was also how you got into the mental state where ambitious thinking became possible in the first place. Grinding through a hard problem, even an unpleasant one, builds the kind of focused attention that harder problems require. Remove that entirely and you don’t just lose the signal, you lose the warm-up. Clicking accept all day is cognitively light in a way that leaves engineers poorly equipped for the kind of thinking that actually matters now.
The Floor is Rising
When everyone can build a React app, the React app is no longer where interesting things happen, because the floor rose.
The baseline of what’s possible with minimal effort moved up dramatically, which means the work worth doing has moved with it. What required a team two years ago is now a weekend project, and that’s genuinely remarkable, but it also means the question has changed. The question is no longer how to protect what we had or mourn what the tools have taken over, it’s what you actually build now that the commodity work stops consuming all your available capacity, both time and cognitive. Not because you should be braver than you were before, because the capacity was always the real constraint, not the ambition.
These tools have gravity. Models are exceptionally good at solving already-solved problems, which means they pull toward the mean by design. Ask Claude to scaffold something and you will get a competent, conventional answer, because competent and conventional is what the training distribution rewards. That’s not a criticism, it’s just the nature of how LLMs work. The danger is that this gravity is invisible until you notice you’ve been accelerating toward it for six months. The floor rose, yes, but the tools also make it very comfortable to stay on the floor.
The Honest Part
Shifting gears after years in the same one is hard, and the muscle for choosing ambitious problems is atrophied in a lot of engineers right now, which makes the obvious failure mode worth naming explicitly.
The danger isn’t that engineers become obsolete, it’s that we fill the reclaimed capacity with more of the same: faster CRUD apps, higher velocity on the same class of problems, boilerplate produced at scale. That the job quietly becomes creating the boring stuff faster and we let it happen because inertia is powerful and the discomfort of starting a genuinely hard problem is real. The factory workers of the industrial revolution didn’t get much choice about what to do with whatever time automation freed up. We do, and that’s the part worth not squandering.
So What Now
I don’t have a clean answer to any of this, and I’d be suspicious of anyone who does. What I do think is that the engineers who come out of this period doing interesting work will be the ones who sat with the discomfort long enough to find out what they actually wanted to build, rather than filling the space with faster versions of what they already knew.
Further reading
Anthropic: How AI assistance impacts the formation of coding skills
MIT Media Lab: Your Brain on ChatGPT
Thank you to Vilhelm von Ehrenheim for his always insightful feedback.