A senior engineer at a major tech company makes $350–500K in total comp. The work is genuinely hard. But the price isn't set by how hard it is — it's set by how few people can do it.
That's the mechanism nobody wants to name. A lot of that comp was paying for scarcity, not just difficulty.
I've been a chief architect for twelve years at the same company — hiring and building through two major downturns and the current one. The pattern forming here isn't about AI eating jobs. It's about scarcity eroding, and what happens to the economics of a profession when the thing that made it expensive starts to loosen.
#What's Actually Happening
144,000 tech workers have been laid off in 2026 so far, on pace to exceed last year's 245,000. The CEO memos all say "AI efficiency." The reality is muddier — Marc Andreessen calls it a zero-interest-rate overhiring correction, Altman has acknowledged "some AI washing," and Oxford Economics suspects companies are dressing up layoffs as progress.
The cause doesn't change the pressure. Whether AI directly automates the work or merely redirects $725 billion in infrastructure spending away from payroll, the result is the same: the supply of available engineers is rising while the number of seats is falling. That's a scarcity problem, and it runs in one direction.
The floor rose. A product manager with a coding agent can build something that works. A founder can ship a real product without a team. A marketing coordinator can spin up a landing page that would have been a two-week engineering ticket eighteen months ago. The work isn't gone. But the exclusivity that made it valuable is.
#The Shape
Economists have described labor market polarization as a barbell for decades — weight at both ends, nothing in the middle. The version forming inside software engineering is weirder: both surviving ends are high-skill, and the middle that's hollowing out is also high-skill. It's not about whether you're smart. It's about the shape of what you know.
On one end: the person who can close the loop from problem to value without a team. Not a job title — a capability. The test is specific: Can you sit alone with a business problem, an AI toolkit, and no spec, and produce something a customer would pay for? That requires holding business model, customer need, product instinct, and technical judgment simultaneously. It's the founder who codes. The engineer who does their own user research. The designer who understands unit economics. The common thread isn't any one skill — it's the ability to make the whole decision, not just the technical one.
On the other end: depth that takes years of real consequences to build. Twenty years of database internals. Compiler design. Distributed systems failure modes. Security architecture. The judgment that comes from scar tissue — not because the knowledge is secret, but because the cost of learning it can't be compressed. These people have more scarcity than before, because the systems they understand are getting more critical and there are fewer of them.
In the middle — the part under pressure — is execution without either kind of leverage. People whose value was primarily in turning known requirements into working code at average depth. This isn't a level on the career ladder. Some mid-level engineers already operate at the ends. Some staff engineers are execution-oriented with senior titles. It's behavioral, not hierarchical.
These are good engineers. They built real things. They didn't do anything wrong. The ground moved.
#The Self-Flattery Problem
I'm aware this essay describes someone who looks like me on one end of the barbell. I'm a cross-functional architect who thinks about product and business and uses AI to move faster. It would be convenient if the future belonged to people like me.
So let me be direct about what I'm not saying: I'm not saying generalists win and specialists lose. The specialist end of this barbell is at least as durable — probably more. The person with twenty years of database judgment has a moat I can't touch. My generalist toolkit makes me useful in a specific way; their depth makes them irreplaceable in a different one. If I had to bet on which end has more pricing power in five years, I'd bet on depth.
What I am saying is that both ends survive for the same reason: they have something that's hard to supply. The middle is where the supply problem breaks, because execution at average depth is exactly what's getting easier to produce.
The fact that I'm standing on one end of this barbell doesn't make the observation wrong. But it does mean I should hold it with less certainty than someone standing in the middle, looking at it from below.
#The Income Problem
A senior Meta engineer pulling $400K wasn't being reckless. That was the market. They bought houses, started families, made choices that were rational given the information they had.
The conditions that produced those salaries — near-zero interest rates, pandemic-era talent wars, remote-work geographic arbitrage — were a specific moment. The "AI engineer" premium that feels like a lifeline right now has the same arc as "big data engineer" in 2013 and "cloud architect" in 2018. The title carries weight until the skill becomes table stakes.
"The market changed" doesn't make the mortgage smaller.
#What Doesn't Survive
I want to be precise about what's under pressure, because the easy read of this essay is "learn to prompt and you'll be fine." That's not it.
What's losing value is reliable execution without leverage — either the leverage of breadth (the whole decision) or the leverage of depth (irreplaceable judgment). Writing solid React. Building standard integrations. Handling routine architecture. The work itself still exists. But the scarcity premium on it is compressing, because more people — and more tools — can produce it.
I've watched this in my own work. The harnesses I built — testing frameworks, orchestration patterns, the boilerplate I was proud of — they keep getting eaten by the model. A test infrastructure I spent three weeks designing last year, the model generated a working version of in an afternoon. Not the same version. Not as elegant. But functional, and good enough to ship. The part that mattered wasn't the code I wrote — it was knowing which failure modes to test for, which edge cases would bite us in production, which parts of the system were load-bearing and which were ceremony. That judgment got more valuable. The implementation that expressed it got cheaper. It's a different skill than the one I spent years developing, and the transition isn't comfortable even when you're on the right side of it.
There's a category I don't want to erase: the engineer whose depth is in craft itself — architecture, interfaces, test strategies, the structural work that keeps a codebase from becoming unmaintainable slop. I've watched vibe-coded products accumulate technical debt that costs more to fix than it saved to ship. Those engineers are essential — but the qualifier matters. They survive when they can translate technical quality into business language. The one who holds the quality bar and communicates why it matters to the people making product decisions thrives. The one who writes perfect code in isolation is under the same pressure as everything else in the middle.
#Sitting With It
The hardest question: what do you do for the people currently in the middle?
"Reskill" is the policy answer. Into what? Toward the broad end, you need cross-functional judgment that takes years to develop. Toward the deep end, you need expertise that takes even longer. Neither happens on a six-month timeline.
I don't have a clean answer. I don't think anyone does. But I think the scarcity framing helps more than the AI framing, because it names the actual mechanism. And it's worth saying: the ends aren't identities. They're trajectories. A lot of the people who now operate at either end of this barbell started as execution engineers. The middle isn't a permanent address — but the window to move is narrower than it was, and the people telling you "just reskill" are rarely the ones who have to do it on a mortgage timeline. The threat isn't that a model can do your job. The threat is that your job's price was partially set by how few people could do it, and that number is changing.
The technology is the same. The futures aren't.
Companion to What's Left: Software Engineering in the Agent Era.