A couple of weeks ago I caught myself in a pattern I didn't like.
I'd been deep in SureCart MCP work — diagnosing broken abilities, working around quirks in CreateInvoice::execute(), tracking down which dummy parameters unblocked empty-object failures, mapping the discover → get-info → execute flow. Useful work. Real work. Work that closed tickets and made the system better.
But it was all tactical. I was solving today's bug today, then tomorrow's bug tomorrow. None of it was building something that would still be valuable in two years. None of it was the kind of work that compounds.
That observation — "I'm executing fast, not thinking deep" — has been sitting with me. And the more I sit with it, the more I think it's the central question for engineers like me right now. Not "which framework next?" Not "which AI tool to learn?" The real question is: what does it mean to be a senior engineer when production is no longer the bottleneck?
This is my honest attempt at an answer.
The world that's ending
For most of software's history, the bottleneck was production. Writing code was slow, so people who wrote it well and fast were rare and valuable. The whole industry — interviews, salaries, titles, status — got built around rewarding fast, capable hands. "Senior" mostly meant ships more, faster, with fewer bugs.
That world is ending. Not because AI writes perfect code — it doesn't, and I've spent enough hours debugging plausible-but-wrong AI output to be confident it won't anytime soon. But because AI writes plausible code at a speed no human can match. And when production becomes cheap, the scarce thing moves.
I see it in my own day. Three years ago, "ship a Gutenberg block in a day" was a feat. Today I can scaffold one in twenty minutes with Claude, and the rest of the day is spent deciding whether the block should exist, what its props should be, how it'll behave in 30 themes I haven't tested, and what the migration story looks like in version 2. The typing part shrank. The thinking part didn't.
Multiply that across a team of seven engineers and you start to see the shape of 2026: production volume goes up, judgment about what to produce stays roughly constant. The bottleneck has moved.
What's becoming actually scarce
When I look at the engineers I genuinely respect — at Brainstorm Force, at weDevs, at Paysera, in open source — and I ask "what makes them different from a fast typist with Claude open in another tab?", a short list emerges.
Taste. They know what's worth building. They can tell, before any code gets written, whether a feature is going to age well or rot in six months. AI generates plausible code; they generate appropriate code. The difference compounds across a hundred decisions.
Systems thinking at the seams. AI is great inside a file, decent inside a service, and weak across system boundaries — auth flows, data contracts, eventual consistency, failure modes, security posture, cost surfaces. The engineers I learn from spend most of their time at the seams. That's where the bugs live, and that's where AI is least useful.
Verification skill. Reading code AI wrote, spotting the subtle wrongness, knowing what to test and what tests are theater. This is the new bottleneck and most engineers — myself included, until recently — are bad at it because we were trained to write, not to review.
Specification clarity. The new "programming" is writing precise intent. Engineers who can decompose a fuzzy human goal into an unambiguous spec will run circles around engineers who can only respond to tickets. I've watched senior engineers turn a 30-minute meeting into a 10-line spec that the rest of us implement in an afternoon. That compression is the skill.
None of these are framework knowledge. None of these are answerable by writing more code. All of them are acquired the same way: slowly, by paying attention to a lot of systems over a long time.
The trap I'm trying to avoid
When AI accelerates everything, the obvious response is to do more — more side projects, more frameworks, more shipping in public, more content. I get the appeal. I've fallen for it more than once.
But I think it's the wrong move. The counterintuitive play is to do less, deeper. One book read carefully beats five skimmed. One module of Laravel core understood beats ten copy-pasted patterns. One spec written precisely beats ten vibes-coded prototypes. Depth is the actual moat now, because breadth got commoditized the day GPT-4 shipped.
The other trap is staying tactical because tactical is comfortable. There's a real dopamine hit in closing a ticket, fixing a bug, shipping a release. There's almost no dopamine hit in spending three hours reading the React reconciler source to understand how key props actually work. But two years from now, the second activity is the one that will have made me a better engineer. The first will be invisible.
I've started catching myself when I reach for tactical work as an avoidance mechanism — when "let me just fix this one bug" is really "let me not sit with the harder question of what we should be building." It's an uncomfortable thing to notice in yourself. It's also where the growth is.
What I'm actually changing
Concretely, here's what's different about my week now versus six months ago.
I've started reading more code than I write. Not skimming — reading, the way you'd read a novel. Module by module. Asking why each decision was made. Right now I'm working through Inertia.js's adapter layer because I want to understand how it cleanly separates the routing model from the rendering model. Nothing about my day job requires this. Everything about my long-term capability does.
I've started writing specs before code, even for myself. When I have a feature to build, I now spend the first 30 minutes writing a plain-English description of what it does, what it doesn't do, what the edge cases are, and what the rollback story is. This is what I'd write for an AI to implement — but the act of writing it forces a clarity I used to get by half-way through the implementation. Catching the ambiguity earlier is enormously cheaper.
I've started reviewing AI output the way I'd review a junior PR. Not "did it run?" but "would I have made this choice? Where's the subtle wrongness? What's the load profile? What happens at 100x?" When I'm on, I reject most AI output the first time and ship the third or fourth pass. The yield is much higher than letting plausible-looking code through.
And I've started publishing opinions in public — including this post. Six months ago I wrote drafts that never got shipped because they didn't feel "ready." I'm trying to ship the half-baked ones now, because the feedback I get from being publicly wrong is more valuable than the comfort of being privately correct.
The honest uncomfortable part
I want to be clear that I'm not above any of this. The reason I'm writing it is that I'm in the middle of it. Some weeks I revert to tactical mode because there's a fire and the fire needs to be out. Some weeks I read about something interesting and don't go deep on it because going deep is uncomfortable and Slack is not. The shift I'm describing isn't a transformation — it's a deliberate, ongoing recalibration. I expect to be working at it for the next two to three years.
The compass I keep coming back to is this: the market is about to be flooded with fast hands. Not because AI replaces engineers, but because AI lets one engineer ship the work of three. In that world, what gets you kept around isn't your throughput. It's whether your opinion changes the decisions in the room.
That's the engineer I want to be in 2026. I'm a long way from being him. But I know what direction he's in.
If you're navigating the same shift — or if you're hiring for it — I'd love to talk. I'm freelance-available for senior engineering, architecture review, and the kind of consulting where the deliverable is less code, written better. Drop me a line or book a 30-minute call.