Will AI Replace Software Engineers? A Hiring View

Thomas Prommer Technology Executive & CTO Connect on LinkedIn

Published: May 30, 2026

Updated: June 5, 2026

The two numbers that should not both be true

The first time I noticed the contradiction, I was reading two reports in the same afternoon. One said US computer-programmer employment had fallen to its lowest level since 1980, with the twelve-month average down 27.5% since 2023 — a collapse that lined up almost exactly with the arrival of code-writing AI (Fortune, reading the BLS data). The other, from the same Bureau of Labor Statistics, projected software-developer employment to grow 17.9% between 2023 and 2033, several times the rate for the average occupation (BLS Occupational Outlook Handbook).

Contraction and expansion, published by the same agency, about what looks like the same work. Most coverage picks one number and writes a headline. I staff engineering teams for a living, so I cannot pick. I have to hire into whichever of these futures is actually arriving.

The resolution is not a compromise between the two. It is the recognition that the two labels measure different things. "Programmer" and "software developer" are not synonyms in the BLS taxonomy. A programmer, in that taxonomy, mostly writes code from a specification someone else produced. A developer designs the system, decides what to build, and increasingly supervises the writing. AI is exceptional at the first job and weak at the second. So the number measuring the first job falls, and the number measuring the second job rises, and both are honest.

What is actually being replaced is a task

I want to name the principle before I lean on it, because it is the load-bearing idea in everything that follows: AI does not replace a profession, it replaces a task inside it, and a profession only dies if it was nothing but that one task. The programmer whose entire value was translating a clear spec into working code is being automated, because translating a clear spec into working code is precisely what a large language model does well. The engineer whose value was deciding what the spec should be, why, and how the pieces fit together is not, because deciding remains stubbornly human.

This is where my sport keeps me honest. I have spent twenty years training for endurance events, and the technology in that world has never once replaced the athlete. A power meter did not make me obsolete; it deleted the guesswork about how hard I was actually working and forced me to get good at the parts the meter could not measure — pacing judgment, when to push, when to back off three weeks out from a race because the numbers say recovery is lagging. The tool removed the easy, measurable part of the job and raised the value of the judgment that surrounds it. Code-writing AI is a power meter for engineering. It does not retire the engineer. It retires the part of the work that was always closest to mechanical, and it makes the surrounding judgment scarcer and more valuable.

I have watched this happen inside my own teams. Agents now draft a large share of first-pass code. The people who got faster and more valuable were the ones who already thought in systems — they treated the agent as a junior who types quickly and needs careful review. The people who struggled were the ones whose whole identity was the typing.

The contraction is real, and it is at the bottom

I do not want to wave the aggregate growth number around as if it makes the pain imaginary. It does not. The damage is concentrated, and it is concentrated exactly where it does the most long-term harm: the entry level.

A Stanford team led by Erik Brynjolfsson found that employment for software engineers aged 22 to 25 fell roughly 20% from a late-2022 peak through mid-2025, even as employment for older engineers in the same field held steady or grew (Fortune on the Stanford study). Read that next to the BLS growth projection and the picture sharpens: the field is growing, but the growth is not landing on new graduates. AI is strongest at exactly the well-specified, low-ambiguity work that juniors used to cut their teeth on. The first rung of the ladder is the rung being automated.

This is the part that worries me most as someone who builds teams, and it is not a worry about this year's hiring. Senior engineers are not minted; they are grown, slowly, out of juniors who spent a few years doing the unglamorous well-specified work and learning the codebase in their hands. If the industry stops hiring juniors because an agent can do the junior's old tasks, it stops producing the seniors it will need in five years. We are, collectively, eating our seed corn, and the bill arrives on a delay long enough that most companies will not connect cause to effect.

Why the long-term number still points up

Set the entry-level damage beside the demand signals and the longer arc is clearly one of growth, not extinction. The World Economic Forum's Future of Jobs Report 2025 ranks software and application developers among its fastest-growing roles worldwide, alongside AI and big-data specialists, and projects net job creation of roughly 78 million positions globally by 2030 even after accounting for displacement (WEF Future of Jobs Report 2025).

The mechanism behind that growth has a name worth knowing. When a technology makes a unit of work dramatically cheaper, total demand for the work usually rises rather than falls, because the lower price unlocks uses that were never economic before. Cheaper code means more software gets built, by more organizations, in more corners of the economy that could never previously justify a custom build. I have written at length about why this dynamic applies to our field in my piece on Jevons paradox in software development; the short version is that abundance of code is far more likely to expand the need for people who can shape it than to erase it.

Gartner's read on 2030 fits the same shape. In its survey of more than 700 CIOs, the consensus expectation was that by 2030 around 75% of IT work will be done by humans augmented with AI and roughly 25% by AI operating alone, with effectively none done by humans entirely without AI (Gartner, November 2025). That is not a forecast of replacement. It is a forecast of a workforce that has absorbed AI into the work — the same way it absorbed the IDE, version control, and the cloud, none of which reduced the number of engineers despite each one automating real toil.

Even the press has started catching up to the data. In April 2026, CNN ran a piece titled, plainly, that the demise of software-engineering jobs has been greatly exaggerated, noting that developer openings kept growing and that the job was shifting toward overseeing AI-written code rather than vanishing (CNN Business, April 2026). When the doom narrative starts getting its own corrections, it is usually because the underlying numbers stopped supporting it.

None of this means the transition is painless or that the people quoting layoff headlines are lying. Some companies have genuinely frozen engineering hiring, and a few executives have said so publicly. But a hiring freeze in a quarter of high interest rates and AI uncertainty is not the same event as a profession being deleted, and conflating the two is how you talk yourself out of a career that the long-run data keeps describing as one of the most durable on offer. The honest read is that the field is being reshaped hard and growing at the same time, which is uncomfortable to hold in one's head but is what the evidence actually says.

What I actually do when I staff a team

Forecasts are cheap. The honest test of what I believe is what I do when I have a budget, an open requisition, and a stack of resumes. So here is the verdict from the chair.

I stopped screening for typing speed, and I never bring a take-home that an agent can one-shot. That test no longer separates anyone, because everyone — and every model — passes it. Instead I hand candidates a deliberately under-specified problem and watch how they handle the ambiguity. Do they ask the right questions before writing anything? When I drop an AI-generated solution with a subtle bug in front of them, do they catch it, or do they trust the confident-looking output? Can they explain why one architecture survives a change in requirements and another shatters? Those are the discriminating questions now, and a model cannot yet answer them on its own.

I weight three things above all else. Judgment: the ability to decide what to build and what not to, which is most of the job and the part AI is worst at. System thinking: holding the whole architecture in view, seeing how a change in one corner ripples through the rest. And agent fluency: the practical skill of directing AI tools, reviewing their output critically, and knowing when their confident answer is wrong. That last one is genuinely new, and it is scarcer than it should be. Plenty of senior engineers are slower to trust and steer an agent than the sharp juniors who grew up with them.

What I have stopped doing matters as much as what I screen for. I no longer treat a long resume of framework names as a signal, because a framework is the most automatable kind of knowledge there is and a model carries all of them at once. I no longer reward the candidate who can recite an algorithm faster than the others, for the same reason. And I no longer assume that years of experience equal adaptation; some of the engineers most at risk in my pipeline are veterans who built their identity on being the fastest typist on the team and have not yet made the move to directing the work instead of doing all of it by hand. The transition rewards a specific kind of humility, the willingness to let a machine do the part you were once proud of so you can concentrate on the part that actually needed a human all along.

I also keep hiring juniors, against the short-term incentive not to, because I refuse to participate in eating the industry's seed corn. But I hire them differently. I am no longer paying a junior to type out solved problems; I am paying them to learn judgment under a senior's supervision, with an agent doing the mechanical work between them. The apprenticeship has to be redesigned around reviewing and directing AI rather than grinding through tickets, and the teams that figure that redesign out first will own the senior talent market a few years from now. I sketch the mechanics of that shift in my guide on transitioning an engineering team to AI-first, and I think about where the role lands next in the future of software engineering.

The junior-developer squeeze deserves its own treatment with the role-specific data, and my colleagues over at ctaio.dev have done exactly that in their analysis of whether AI will replace junior developers. If you are early in your career and reading this with a knot in your stomach, start there.

The verdict

Will AI replace software engineers? From where I sit, holding the budget and signing the offers: no. It is replacing a task, contracting the roles that were only ever that task, and quietly raising the bar on everyone who remains. The engineer who sold keystrokes is in trouble. The engineer who sells judgment is worth more than ever, and is now also expected to direct a tireless agent who types faster than any human ever could. That is not the end of the profession. It is the profession growing up — and if you want to bet against it, you are betting against the one occupation the same labor statistics keep projecting upward while they project nearly everything else flat.

Frequently asked questions