The Senior Engineer Isn't Dead. The Job Description Just Changed.

· 10 min read

There’s a version of this conversation happening in every tech company right now. Someone in a leadership meeting pulls up a slide with AI-generated code stats, mentions that GitHub Copilot has 20 million users, quotes Sundar Pichai saying 25% of Google’s new code is AI-written, and concludes, more or less directly, that maybe they don’t need as many engineers next year.

It’s a tempting argument. It’s also mostly wrong, and the companies acting on it are starting to pay for it.

AI coding tools are real, they’re widely adopted, and they do change the job. But the claim that software engineering is dying, that senior engineers are an endangered species, gets the direction right and the magnitude badly wrong. The data, if you actually look at it rather than cherry-picking vendor press releases, is a lot messier than the headlines suggest.

The Productivity Numbers Are Messier Than the Headlines

The most-cited stat in the “AI makes developers 55% faster” genre traces back to a 2023 Microsoft Research / GitHub study where 95 recruited developers wrote a JavaScript HTTP server. A single task. A greenfield codebase. A controlled lab environment. That’s where that number came from. It has nothing to do with your 12-year-old platform monolith.

The most credible counterpoint came out in July 2025. METR, an AI safety research organization, ran the only field randomized controlled trial to date with experienced open-source developers working on their own real codebases. The result: AI tools made them 19% slower. Not faster. Slower. And those same developers believed they were 20% faster. That gap between perceived and actual productivity is the most important finding in AI coding research this year, and it’s gotten a fraction of the attention of the lab-funded headline numbers.

Perceived vs. actual productivity change with AI tools. Developers believed they were 20% faster; they were actually 19% slower. Source: METR field RCT, July 2025.

Worth noting: the METR study had 16 participants. It’s the best controlled data we have on experienced developers working on real codebases rather than toy tasks, but a sample of 16 is not a settled verdict. I’d be cautious about anyone (including me) treating it as definitive. What it does do is meaningfully complicate the vendor-funded 55% claim, which had far weaker methodology and got far more coverage.

Google’s DORA report is the most rigorous longitudinal study of software delivery performance out there, now in its eighth year. In 2024, a 25% increase in AI adoption correlated with a 7.2% drop in delivery stability. The 2025 report found AI adoption nearly universal at 90% of developers, but teams without strong testing, CI/CD, and architectural discipline kept seeing the same delivery instability. The DORA team put it plainly: AI “doesn’t fix a team; it amplifies what’s already there. Strong teams use AI to become even better and more efficient. Struggling teams will find that AI only highlights and intensifies their existing problems.”

GitClear analyzed 211 million changed lines of code across major enterprise repos from 2020 to 2024. Code churn (rewrites within two weeks of the original commit) went from 3.1% pre-AI to 5.7% by 2024. Refactoring dropped from 25% of changed lines to under 10%. That’s the fingerprint of code that works line-by-line but falls apart at scale. It looks fine until it doesn’t, and when it doesn’t, someone experienced has to untangle it.

Senior Engineers Were Never Mostly Coding

Ask a senior engineer to track their time for two weeks and raw coding is roughly a third of the job. Sonar’s developer time-allocation research puts it at about 32%. The rest is code review, maintenance, incident response, architecture decisions, writing specs, sitting in meetings, negotiating with product managers, mentoring juniors, and refusing to ship things that can’t be verified.

AI is reasonably good at that 32%: greenfield implementation, boilerplate, test scaffolding, the repetitive translation work that used to eat hours. What it can’t do is the other 68%. That’s where senior engineers earn their keep, at least for the ones who actually occupy that space. To be honest about it: some engineers with the title don’t. If your day-to-day as a “senior” engineer is mostly heads-down implementation with limited architecture ownership or cross-team influence, that’s worth sitting with. The threat is real for that profile regardless of the years on the resume.

Here’s a concrete example of what I mean. I’m the lead engineer on a team responsible for bot mitigation across global markets. The systems we run make millions of decisions per second (allow, challenge, block) and the rules encoding those decisions reflect years of understanding about how traffic behaves differently by intended target, market, device type, and threat actor. Some of those rules exist because years ago I found a prominent bot tool’s executable sitting unobfuscated on their own website. I pulled it apart, read the changelog, found the engineers’ names and commit history along with clear and obvious patterns for how the bot was being used and built detection around what I learned. That intelligence lives in documentation and in the heads of the people who did the work. It’s not in the codebase. Nobody filed a ticket for that. It happened because I knew what I was looking at, knew what to do with it, and had enough context to recognize the opportunity in the first place. AI is not doing that. A junior engineer who hasn’t built up that context isn’t doing that either. What you need is someone who has been doing it long enough to know what they don’t know.

Addy Osmani, who currently works as the director of cloud AI at Google, said it well: “A senior engineer’s job is mostly the parts that don’t show up in the diff. Specs. Tests. Reviews. Scope discipline. Refusing to ship what can’t be verified. AI coding agents skip those parts by default.” Simon Willison, writing about agentic engineering, makes the same point: almost everything that makes someone a senior engineer, the system design, the complexity management, the judgment about what to automate and what to hand-code, is also what yields the best outcomes when working with AI.

The engineers reporting real 2-5x productivity gains from AI are almost always treating it like a junior collaborator they’re managing: writing specs first, reviewing output carefully, maintaining tests, and staying accountable for what ships. The ones reporting flat or negative outcomes are using it as fancy autocomplete and quietly inheriting the technical debt piling up in the background.

The Headcount-Reduction Playbook Has a Body Count

The loudest claims about AI replacing workers haven’t come from engineering specifically. They’ve come from customer service, HR, and back-office functions where the tasks are more bounded. The pattern is instructive regardless of department.

Klarna made international headlines in early 2024 when it announced its OpenAI-powered assistant was doing the equivalent work of 700 full-time customer service agents. The headline was real. What came next wasn’t in the press release: by 2025, CEO Sebastian Siemiatkowski was publicly admitting they went too far, that the focus on efficiency had reduced quality, and that Klarna was rehiring human agents. “We went too far,” he said. Remarkable candor for an admission that the strategy failed.

IBM tells a different story, and it’s the one worth paying attention to. Arvind Krishna confirmed to the Wall Street Journal that AI automated the work of a few hundred HR employees. What happened next: IBM’s total headcount grew, because the savings were redirected into sales, engineering, and customer-facing roles where humans still do things AI can’t. The company didn’t fire people and call it a win. It automated the routine and reinvested in the work that matters. That’s a meaningfully different playbook from Klarna’s.

The MIT NANDA project conducted 52 structured interviews, surveyed 153 senior leaders, and reviewed over 300 publicly disclosed AI initiatives. They found that 95% of generative AI pilots delivered zero measurable P&L impact. Not marginal impact. Zero. The cause wasn’t bad models. It was organizations that bought licenses without redesigning the workflows around them. MIT calls it the “learning gap.”

The Jobs Aren’t Disappearing. They’re Bifurcating.

The Bureau of Labor Statistics projects 15.8% growth in software developer employment through 2034. 267,700 net new jobs. Second-largest absolute occupational increase in the entire U.S. economy. Not a dying field.

That 10-year projection is directionally useful but it papers over something happening right now. Stanford’s Digital Economy Lab, using ADP payroll data, found early-career developers aged 22-25 in AI-exposed occupations saw a 16% relative employment decline since late 2022. For software developers specifically in that age range, the drop is closer to 20% from their late-2022 peak. Meanwhile, employment for experienced engineers aged 35-49 held flat or grew. The market isn’t collapsing. It’s shifting up the experience curve, and it’s doing it fast enough that the BLS 10-year number may be cold comfort if you’re 23 and just graduated.

IEEE Spectrum’s analysis of BLS occupational data shows the split clearly: “computer programmer” employment dropped 27.5% from 2023 to 2025. “Software developer” employment fell just 0.3%. The jobs that reduce to typing code are being automated. The ones requiring judgment, systems thinking, and institutional knowledge are not.

Employment change by occupation type, 2023–2025. Computer programmer roles fell 27.5%. Software developer roles fell just 0.3%. Source: IEEE Spectrum analysis of BLS data.

AWS CEO Matt Garman called the junior-replacement strategy “one of the dumbest things I’ve ever heard. If you have no talent pipeline that you’re building and no junior people that you’re mentoring, at some point that whole thing explodes on itself.” He’s right, and not just for reasons of principle. The senior engineers of 2030 are the junior engineers of today. Companies cutting that pipeline to save money in the short term will be paying consulting rates to rebuild it in three years.

He also called lines-of-AI-generated-code a “silly metric” (his word) and noted that companies have spent the last couple of years bragging about exactly that number. If that’s how you’re measuring your AI investment, you’re measuring the wrong thing. Volume of generated code is not a proxy for engineering output. It’s barely a proxy for anything.

The Bottom Line

McKinsey’s 2025 State of AI survey found only about 6% of organizations achieved meaningful EBIT impact from AI. The differentiator wasn’t which models they bought. It was whether they redesigned workflows end-to-end. Those firms were nearly three times more likely to do that, and they used AI for growth rather than cost-cutting. DORA 2025’s top-performing teams reflected the same thing: mature CI/CD, automated testing, clear AI usage policies, and senior engineers still owning architecture and review.

The field isn’t dying. But the version of it where the job is mostly typing is, and that’s creating real pressure on early-career engineers right now. Engineers who use AI to handle the implementation so they can spend more time on the work that actually requires judgment are going to be more effective than they’ve ever been.

Organizations that understand this will pull ahead. The ones cutting headcount and calling it an AI strategy are going to find out the hard way that the 95% failure rate MIT documented wasn’t about the models.

Sources