The Future of Software Engineering: A Leader's Read on 2030

Thomas Prommer Technology Executive & CTO Connect on LinkedIn

Published: May 30, 2026

Updated: June 5, 2026

Three years into a long triathlon block, I bought a power meter. Within a month it had quietly rearranged how I trained, because suddenly I could see exactly how much work I was doing at every second. The honeymoon lasted about six weeks. Then I noticed the number had become the point. I was riding to make the wattage look good on the screen rather than to get faster, and the two had stopped being the same thing. The meter measured output beautifully. It said nothing about whether the output was aimed at the right target.

I think about that meter a lot when people ask me where software engineering is going. The honest answer is that we are living through the same transition, on a much larger scale, and most of the conversation is stuck staring at the wattage.

When the meter measures everyone at once

For most of my career, the scarce thing in engineering was the ability to produce working code at all. You hired for it, you paid for it, you organized teams around protecting it. An engineer who could turn a vague requirement into a shipped, tested feature was valuable precisely because that translation was hard and slow. Productivity was the differentiator because productivity was rare.

AI is dissolving that scarcity. Not slowly, and not at the margins. Gartner's Software Engineering 2030 research projects that by 2030 essentially no IT work will be done by humans without AI involved: roughly three quarters done by humans augmented with AI, and about a quarter done by AI operating on its own, according to its October 2025 survey of CIOs. That is the wattage going up for the entire field at once.

Here is the part that I keep having to explain to boards. When a capability becomes universal, it stops being an advantage. If every engineer on the team can now produce four times the code, the team's relative standing has not changed at all. The meter now reads high for everyone. The number stopped measuring the thing it was hired to measure, which was: who can move the system forward. Raw productivity is becoming baseline, the way being able to type used to be baseline. You still need it. It just no longer tells you who is good.

What moves into the gap

So where does the signal go when the obvious meter stops working? It goes to the things the meter was never able to see. On the bike, the wattage could not tell me whether I had paced the race intelligently, read the field correctly, or chosen the right block of training in the first place. Those are the judgment calls that decide the outcome, and they sit entirely outside the number. The same is now true of engineering.

Three capabilities move into the gap, and I watch for all three when I staff a team.

The first is judgment about systems. An AI agent will happily generate a service that passes every test you give it and falls over the first time real traffic hits an edge it was never asked about. Knowing what to ask about, where the load lands, how the thing degrades, which failure modes are merely annoying versus existential, is not generation. It is the accumulated scar tissue of having watched systems break. That does not come out of a model. It comes out of a person who has been paged at three in the morning and remembers why.

The second is orchestration. The engineer's job is shifting from writing the solution to directing the things that write it, then verifying what comes back. That is a genuinely different skill. Writing a precise specification, decomposing a problem so that an agent can attack the right piece of it, reviewing output you did not author and catching the plausible-but-wrong answer: this is closer to running a small team than to coding. The leverage is enormous and the failure mode is quiet, because a confident wrong answer reads exactly like a confident right one until production tells you otherwise.

I want to dwell on the verification half of that, because it is where I see good engineers get sloppy fastest. When you write a function yourself, you understand it by construction. You held every branch in your head as you typed it. When an agent writes it, you understand it only as deeply as you choose to interrogate it, and the temptation to wave through code that looks plausible is overwhelming when the code is correct ninety-five times out of a hundred. The discipline that matters is treating generated output as a strong hypothesis rather than an answer. The senior engineer who reads a generated migration and immediately asks what happens to the in-flight transactions is doing the actual job. The one who runs the tests, sees green, and ships is borrowing against a debt the production incident will eventually call in.

The third is creativity in the oldest sense of the word, which is choosing what to build. Most of the value in software has always been decided before a line of code is written, in the selection of which problem is worth solving and which is a distraction dressed up as a roadmap item. When production becomes nearly free, the cost of building the wrong thing does not fall. It rises, because you can now build the wrong thing faster and at greater scale than ever. The discipline to say no to a plausible feature becomes more valuable precisely as the cost of saying yes drops toward zero.

I have written about the productivity trap at more length in developer creativity versus productivity, because it is the distinction that most engineering orgs are currently getting backwards. They are optimizing the meter and wondering why the races are not going better.

The replacement question, answered with headcount

None of this means the field shrinks. The reflexive fear, that AI writes the code so the engineers go away, runs straight into the numbers. The U.S. Bureau of Labor Statistics projects software developer employment to grow 17.9% between 2023 and 2033, against a 4% average across all occupations. The World Economic Forum's Future of Jobs Report 2025 projects 170 million new roles created against 92 million displaced by 2030, a net gain of 78 million, with technology and AI roles among the fastest growing categories.

There is a mechanism underneath those numbers worth naming, because it is the one that consistently surprises executives. When you make a resource dramatically cheaper to produce, total consumption of it usually goes up, not down. Cheaper code does not mean less code. It means software reaches into problems that were never economic to automate before, which means more systems, more integration, more things that have to be kept alive. I walk through that argument in full in the piece on Jevons paradox and software development. The short version: efficiency expands demand, and the demand lands on people who can do the part the machine cannot.

So the answer to "will engineers be replaced" is no, with an asterisk that matters enormously. The full version of that argument lives in will AI replace software engineers, and the headline is that the role is changing shape, not vanishing. What is genuinely at risk is a specific slice of the role, and pretending otherwise is dishonest.

The crack in the floor

The slice at risk is the bottom rung. The traditional way you became a senior engineer was by spending years doing the work a model now does in seconds: the boilerplate, the simple CRUD endpoint, the test that exercises one obvious path. That work was never the point. It was the apprenticeship. You learned judgment by writing ten thousand mediocre functions and slowly developing a sense for which ones were wrong.

A Stanford study published in August 2025, "Canaries in the Coal Mine?" by Brynjolfsson and colleagues, found that early-career workers aged 22 to 25 in AI-exposed roles saw employment fall by 13 to 16% since late 2022, and that young software developers specifically were down nearly 20% from their late-2022 peak. Experienced engineers in the same field held steady or grew. That is exactly the signature you would expect if AI is eating the apprenticeship while leaving the judgment work alone.

This is the real problem the field has to solve this decade, and it is a leadership problem, not a technical one. If you let the model do all the entry-level work, you stop manufacturing senior engineers, and senior engineers are the entire source of the judgment that turns out to be the scarce resource. A team that optimizes for short-term output by handing every junior task to an agent is eating its own seed corn. The teams that win in 2030 will be the ones that deliberately route hard, ambiguous, judgment-building problems to their juniors even when an agent could do the easy version faster.

In practice this looks unglamorous. It means a junior is handed the gnarly concurrency bug rather than the agent, and is made to sit with it long enough to develop a real theory before anyone reaches for a model. It means code review where the senior asks "why did the agent choose this" and refuses to accept "the tests pass" as an answer. It means measuring a team's health not by lines shipped but by whether its juniors are getting harder problems each quarter. None of that shows up on a productivity dashboard, which is exactly why most organizations will skip it, and exactly why the ones that do not will own the scarce talent a decade from now. The organizations that treat their training pipeline as a cost to be automated away will discover, around 2029, that they cannot buy senior judgment on the open market because nobody was manufacturing it.

Smaller teams, denser judgment

The structure of the team changes too. Gartner expects AI-native development to push 80% of organizations to evolve large engineering teams into smaller, more nimble ones augmented by AI, and that matches what I see when I help organizations make the transition. The shift is not "same team, more output." It is fewer people, each carrying far more judgment, each orchestrating more machine work than any single engineer used to be able to supervise.

That has consequences for how you draw team boundaries and where you concentrate your scarce senior people. I have written about the topology question directly in team topologies in the AI era, and about the operational mechanics of getting a team there in the guide to transitioning an engineering team to AI-first; I keep a broader map of what AI is doing to software engineering as a discipline on the sister site for when the question is the field rather than one team. Both come down to the same principle: when the machine handles volume, you organize humans around judgment, not around throughput.

Gartner's earlier and narrower forecast, that 75% of enterprise software engineers would use AI code assistants by 2028, up from under 10% in early 2023, already looks conservative on adoption and roughly right on direction. Tool use was never the interesting question. What you do with the leverage is.

How I actually staff for this

When I sit in a hiring loop now, I have stopped being impressed by people who can produce code quickly, because everyone can produce code quickly. I watch for whether a candidate can look at a generated solution and tell me, specifically, what is wrong with it and why. I watch for whether they can take a fuzzy business problem and carve it into pieces that a system, human or machine, could actually attack. I watch for the thing the power meter could never measure: have they got the taste to know a good answer from a confident wrong one.

I also weight breadth over depth in a way I would not have five years ago. When the cost of producing code in any given language collapses, deep fluency in one stack stops being the moat it used to be. The model is fluent in all of them. What it cannot do is hold the whole system in mind, reason about how a change in one service ripples into three others, and decide that the elegant solution is the wrong one because it will be impossible for a tired on-call engineer to debug at four in the morning. I would rather hire someone who has shipped and operated systems in three different domains than someone who has memorized one framework to the studs, because the transferable skill is the judgment, and the judgment is what compounds.

Those are the same instincts that separate athletes who train with data from athletes who are trained by it. The meter is a tool. The moment it becomes the goal, you have stopped racing and started performing for the screen. The engineers who thrive in 2030 will be the ones who treat AI exactly the way a good athlete treats a power meter: as an instrument that handles the measurement and the grunt work, freeing the human to do the part that was always the actual job, which is deciding where to point all that effort.

For the wider data picture across the whole industry, including how the broader software-development market is shifting, my colleagues maintain a continuously updated read at the future of software development, which I treat as the data backbone behind the judgment calls in this essay.

Where I land

The future of software engineering is not a story about machines taking the work. It is a story about a meter that used to tell us who was good and has stopped being able to. Productivity is becoming baseline. The differentiators are moving to the places the meter cannot see: systems judgment, orchestration of machine work, and the creative discipline of choosing what is worth building at all. The engineers and the leaders who understand that are going to spend this decade getting faster. The ones still optimizing the wattage are going to spend it wondering why the races keep slipping away.