Will AI Cut Engineering Jobs, or Multiply Their Leverage?

The honest answer is that both things are happening, to different people, and almost every version of this argument you'll read picks one group and generalizes it to the whole profession. The displacement camp points at collapsing graduate hiring. The leverage camp points at their own week. Neither is lying. They're describing different ends of the same distribution.

So this post does something narrower and, I think, more useful: it takes the four best datasets we currently have, states what each one actually measured, and shows where they agree. They agree more than the discourse suggests. What they agree on is uncomfortable for both camps. Much of the judgment software engineering demands shows up as process design, which is what XenGrowth's work on go-to-market systems publishes on.

What does the employment data actually show?

The most credible number comes from Stanford's Digital Economy Lab, and it's credible for a boring reason: it isn't a survey. Brynjolfsson, Chandar and Chen used ADP payroll records — actual paychecks for millions of US workers — rather than asking anyone how they felt about AI. Their headline finding is that employment for 22-to-25-year-olds in the most AI-exposed occupations sits about 19% below where it would be had it tracked their less-exposed peers.

The part that gets dropped in the retelling: experienced workers in those same occupations show no comparable gap. None. The effect is almost entirely concentrated in the youngest cohort.

And the mechanism matters as much as the magnitude. This is happening through reduced hiring, not increased separations. Nobody is being marched out. The jobs are simply not being posted, which is a much quieter process and one that produces no news story, no layoff announcement, and no visible cohort of displaced workers to interview. It shows up as a graduate who sends 300 applications and hears back from four.

A hiring freeze aimed at one cohort looks like nothing at all from the inside of a company. It looks like a headcount plan that quietly got shorter.

Then why is the BLS still projecting 15% growth?

Because it's measuring a different thing, over a longer window, and it isn't wrong. The Bureau of Labor Statistics projects software developer employment growing 15% from 2024 to 2034 — about 287,900 added positions against a 2024 base near 1.7 million, with roughly 129,200 openings a year once you count replacement of people retiring or leaving. Against a 4% all-occupation average, that's still filed under 'much faster than average.'

There's no contradiction here once you separate the size of a profession from the shape of its entry. A field can grow in total headcount while its bottom rung gets pulled up. That's the configuration the two datasets jointly describe: more engineers overall, fewer ways in. Google’s Generative AI Report Is Here. Read It Without Inventing a Story. covers the AI search measurement side of this.

Does the leverage claim survive contact with measurement?

Less well than you'd expect. METR ran the study the industry should have run years earlier: sixteen experienced open-source developers, 246 real issues from their own repositories, each issue randomly assigned to allow or forbid AI tooling. Not a benchmark, not a toy task — actual work on codebases averaging over a million lines that these people already knew intimately.

They were 19% slower with AI available.

I want to be careful about how far that generalizes, because it's a small sample on mature codebases with experts who already had the whole architecture in their heads — close to the worst case for a tool whose main advantage is knowing things you don't. On an unfamiliar codebase, or in a language you're rusty in, the result would likely flip. Treat it as one strong data point, not a law.

But the finding underneath the headline generalizes further than the headline does. Those developers predicted a 24% speedup going in, and estimated a 20% speedup coming out — after doing the work. They were off by roughly 39 percentage points about their own labor, in the direction of flattering the tool. That's the number worth carrying around. It means your sense that AI is making you faster is not evidence that AI is making you faster.

Stack Overflow's 2025 survey suggests why the illusion is so durable. Adoption climbed to 84% while trust in accuracy fell to 29%, and the single most-cited frustration was output that is 'almost right, but not quite.' Almost-right code feels like progress at the moment it appears. The cost lands later, in a debugging session nobody attributes back to the tool that caused it. International Keyword Research Starts Where the Translation Sheet Stops covers the international search research side of this.

What did DORA find, and why does it complicate both stories?

DORA's 2025 report is the most interesting of the four because it changed its own mind. In the 2024 data, every 25% rise in AI adoption tracked with roughly a 1.5% drop in throughput and a 7.2% drop in delivery stability — both bad. A year later the throughput sign flipped positive. Teams really are shipping more.

Stability didn't recover. It's still going the wrong way. Which means the thing AI reliably delivers is volume, and the thing it reliably costs is confidence that what shipped works. DORA's own framing is that AI amplifies whatever a team already is: disciplined teams get faster, undisciplined teams get faster at producing incidents.

GitClear's code analysis points at the mechanism. Across their corpus, copy-pasted lines rose from 8.3% in 2020 to 12.3% in 2024 while refactored — 'moved' — lines fell from 24.1% to 9.5%. 2024 was the first year on record where within-commit copy/paste exceeded moved code. That's a codebase getting larger without getting more organized, which is exactly the shape of output you'd expect from a tool that generates locally-plausible code with no memory of what already exists twelve directories away.

So which side of the split are you on?

Stanford's paper contains the closest thing to actionable advice in any of this, and it's buried in a distinction most summaries skip. They separated occupations where AI usage mostly substitutes for human tasks from ones where it mostly complements them. Employment fell in the first group. In the second, it was flat or rising. On AI search measurement specifically, GA4 Has an AI Assistant Channel. It Still Does Not Measure Every AI Search Visit. is worth reading.

That's not a statement about job titles. It's a statement about what your day actually consists of. Two people with the same title can sit on opposite sides of that line.

• Substitution-shaped work: implementing a spec someone else wrote, translating a ticket into code, producing a known component in a known pattern, writing tests against defined behavior

• Complement-shaped work: deciding what should be built at all, choosing between architectures whose tradeoffs won't surface for eighteen months, debugging something nobody has a name for yet, negotiating a requirement with the person who wants it

• The tell is whether your work has a checkable right answer at the moment you start it. Substitution-shaped work does. Complement-shaped work is mostly the process of finding out what the answer even needs to be

• Most engineering jobs contain both. The question is the ratio, and whether it's moving

This is also why the junior gap is real and not a moral failing of a generation. Entry-level work is defined by being substitution-shaped. That's the whole point of it — you're given bounded problems with known answers precisely so a more experienced person can check your work. AI is very good at bounded problems with known answers. The rung that got removed is the one built out of exactly the tasks the tool does cheapest.

One more caution about all five of these at once. Every dataset here was collected against tooling that has since been replaced, in a period where model capability moved faster than anyone's ability to study it. METR's trial ran on early-2025 assistants. Stanford's payroll window closes in June 2026. Read them as measurements of a moving object, taken from behind, which is the only place measurement can ever be taken from.

That cuts both ways, and I'd be suspicious of anyone who only invokes it in one direction. The people telling you METR is obsolete because the models improved are making the same unfalsifiable move as the people who said in 2023 that displacement was a year away. If the answer to every measurement is that the next version will be different, then no evidence can ever land, and the argument stops being about the world.

What actually follows from all this?

1. Stop treating your own sense of speed as evidence. METR's participants were experts, motivated, and wrong by 39 points. If you want to know whether a tool helps, measure something — cycle time on comparable tickets, review rounds per PR, incidents per deploy — rather than consulting your impression

2. Watch stability, not throughput. DORA's finding is that the two decoupled. If your team ships more and your change-failure rate drifts up, the tool is working exactly as measured and you are still losing

3. Audit your own week against the substitution/complement line. Not your title, your calendar. If most of what you did had a checkable right answer at the moment you started, that is the part of the market under pressure

4. If you hire, notice that the junior gap is a hiring-plan artifact, not a law of nature. The rung got removed by a thousand individually reasonable headcount decisions, and it can be rebuilt the same way

5. Do not read BLS growth as reassurance. Aggregate growth in a profession says nothing about whether its entry door is open, and right now those two numbers are pointing in different directions

The framing I'd resist hardest is the one where this is a single question with a single answer. It isn't. There is a version of the next five years where you personally have more leverage than any engineer in history, and a version where the work you're good at is the work that got cheapest, and which one you get is substantially decided by what fraction of your job survives having a checkable right answer.

The 19% gap isn't a prediction. It's already in the payroll data, through June 2026. The argument about whether this will happen is over.

Further reading from XenGrowth

• Google’s Generative AI Report Is Here. Read It Without Inventing a Story. — what you'll learn: Google announced dedicated Generative AI performance reports in June 2026, but the rollout initially covers only a subset of websites.

• International Keyword Research Starts Where the Translation Sheet Stops — what you'll learn: translate concepts for discovery, then validate the language people actually use in search and sales conversations.

• GA4 Has an AI Assistant Channel. It Still Does Not Measure Every AI Search Visit. — what you'll learn: GA4’s AI Assistant channel covers traffic from named assistants; it excludes Google AI Overviews and AI Mode.

Where this work meets go-to-market

Working on software engineering inside a commercial team? the XenGrowth practice publishes operator guides on the revenue side of this work.