Software Engineering's Great Re-bundling

Software engineering is not shrinking. It is being re-bundled. The roles we spent thirty years carefully separating (analyst, product manager, designer, developer, tester, operator) are collapsing back into a smaller number of wider ones. The reason is not that AI writes code. It is that AI collapsed the cost of producing a software artefact without collapsing the cost of verifying one, and every role boundary we ever drew was built on the old ratio between those two numbers.

The evidence is unusually clear. 84% of developers now use AI while only 29% trust its accuracy. Time in pull request review is up 441%. Software postings sit 30% below their 2020 baseline, yet forward deployed engineer postings grew more than 1,000% in a year, and AI skills now carry a 56% wage premium. That is not a profession disappearing. It is a profession re-sorting, and the sort has a direction you can plan a career around.

Consider the surface symptom first. In a single week of job postings last year, one CTO catalogued more than thirty distinct engineering titles: AI Engineer, Applied AI Engineer, GenAI Engineer, LLM Engineer, Context Engineer, Agent Engineer, RAG Engineer, Evals Engineer, Forward Deployed Engineer, AI-Native Developer, and, his personal favourite, “Builder.” He called it the worst naming disaster since the industry decided DevOps was a person rather than a practice.

He is right about the noise. But noise is a symptom, and the interesting question is what it is a symptom of.

I have a particular vantage point on this. I spent years building and scaling an engineering organisation to more than eighty people, which meant I personally drew a lot of the role boundaries I am now arguing have stopped making sense. I currently run engineering at a company that deploys AI systems into museums and public spaces, which is about as unforgiving a production environment as exists. And I wrote a book whose entire premise is that the model is the easy part. What follows is the labour-market consequence of that premise.

The assembly line we built, and why it was correct

For most of the last three decades, the industry’s answer to complexity was specialisation. A feature travelled down a line: a business analyst gathered requirements, a product manager turned them into a backlog, a designer produced mockups, an engineer implemented them, a QA engineer verified them, DevOps deployed them, support fielded the fallout.

This was not stupidity. It was correct, given the constraints. Each artefact in that chain (the requirements document, the wireframe, the implementation, the test suite) was slow and expensive to produce, and producing it well required practice. Specialisation amortised scarce skill across many projects. The handoffs cost something, but less than the alternative.

The hidden bill came due elsewhere. Context died at every boundary. Each role was measured on the artefact it produced rather than the outcome the chain existed to create, so a team could hit every internal metric and still ship something nobody used. Everybody owned a step. Nobody owned the result.

I want to be honest that I did not work this out from the outside. Running an eighty-person organisation, one of the things I was proudest of was a low-code framework that cut our development costs by roughly thirty per cent. It worked. It also did something I did not fully appreciate at the time: by making a category of artefact dramatically cheaper to produce, it quietly dissolved the justification for the specialists whose job had been to produce that artefact carefully. The roles re-bundled. I read it then as a tooling win. It was a preview.

That trade-off held as long as artefact production stayed expensive. It did not.

The two costs that came apart

Here is the mechanism, and it is worth stating precisely because most commentary skips it.

AI collapsed the cost of producing a software artefact. Code, tests, migrations, mocks, specifications, documentation, first drafts of almost anything. All of it got dramatically cheaper for anyone who can direct a tool competently.

AI did not collapse the cost of verifying one. Reviewing, judging whether something is true, deciding whether it should exist at all, and being accountable when it breaks. These remain human, slow, and expensive.

The evidence for the split is unusually good.

On production: DORA’s 2025 State of AI-assisted Software Development, drawing on nearly 5,000 professionals, found 90% of developers now use AI in their daily work, a 14-point rise in a year, with a median of about two hours a day. Adoption is effectively total.

On verification: Stack Overflow’s 2025 survey of 49,000 developers found adoption climbing to 84% while trust in accuracy fell to 29%, down eleven points in a year, with only 3% reporting high trust. The same survey found two-thirds of developers wrestling with answers that are almost right but not quite, and experienced developers the most sceptical of all. The people with accountability trust the output least.

And on what happens when you accelerate production without accelerating verification: DORA found AI’s relationship with throughput reversed from negative to positive in 2025, while its association with delivery instability persisted. Faros telemetry across 22,000 developers put numbers on the downstream damage: median time in pull request review up 441%, pull request size up 51%, and 31% more pull requests merging with no review at all, a pattern they name “acceleration whiplash.”

The macro version of the same story: an MIT NANDA study of 300 public enterprise AI projects found roughly 95% produced little or no measurable impact on profit and loss. The models worked. The deployments did not.

That figure is the reason I wrote a book rather than another paper. My doctoral work was in AI and data science, and the honest lesson of moving from research into production is that model quality was almost never the binding constraint. It was everything around the model: the data path, the failure modes nobody specified, the integration nobody owned, the operational reality that a demo never has to survive. Ninety-five per cent of enterprise AI projects failing to move profit and loss is not a modelling result. It is a verification-and-integration result.

So: production cheap, verification expensive, and the gap between them is where value now sits.

What the labour data actually says

The pessimistic reading is everywhere, and it is half right. Indeed Hiring Lab data shows software development postings running roughly 30% or more below their February 2020 baseline as of mid-2026, one of the hardest-hit categories they track. The entry level took it worst: junior developer postings down around 40% from pre-2022 levels, entry-level hiring at the fifteen largest tech firms down 25% in a single year, and computer science graduate unemployment among the highest of any major.

But there is a second movement in the data that almost nobody quotes, and it changes the story. Indeed’s own analysis found that while AI-exposed occupations led the decline between 2022 and 2026, since 2025 the relationship has flipped: the more AI-exposed an occupation, the more strongly it has rebounded.

Meanwhile the roles being created are not the roles that were destroyed. Forward deployed engineer postings, to take the sharpest example, grew by more than 1,000% year over year into early 2026, with the most-listed skills no longer Python and SQL but customer discovery, problem decomposition and product judgment.

The pay data points the same direction. PwC’s Global AI Jobs Barometer, built on close to a billion job ads, found a 56% wage premium for AI skills, up from 25% the year before. That is not a market shedding engineers. That is a market bidding hard for a different shape of engineer.

Where each old role’s work is actually going

The business analyst is the clearest case. Requirements gathering, process mapping, specification. That work has not vanished, it has been absorbed by whoever builds. Discovery is now part of the engineering job, not a phase that precedes it.

The product manager is splitting rather than shrinking. The generalist PM sitting between business, engineering and design is breaking into distinct tracks: a builder track that prototypes and ships directly, and a strategy track that owns positioning and sequencing. The middle (backlog grooming, ticket writing, requirement translation) is exactly what AI is absorbing fastest, and exactly where the hiring market looks weakest. LinkedIn replaced its Associate PM programme with a “Product Builder” track rotating across product, design and engineering.

Design is moving the same way. When generating interface variations becomes nearly free, the value shifts from producing artefacts to research quality, systems thinking and taste.

QA is the most misread of all. It is not dying; it is relocating. Manual tester listings are down while quality engineer and SDET listings are up, and developers are increasingly expected to own basic test automation themselves. What survives, and is now scarcer and better paid, is exploratory testing, risk analysis, coverage design and evaluation strategy. In a world where production accelerates and verification does not, the discipline whose entire purpose is verification should be gaining leverage, not losing it. The ones losing are those who defined themselves by test execution rather than quality judgment.

Engineering management is flattening. Gartner expects that through 2026, one in five organisations will use AI to flatten structures and eliminate more than half of current middle management positions, and Meta’s applied AI team has reportedly run at a 50-to-1 employee-to-manager ratio.

And the shape of the team itself is changing. Gartner’s outlook describes engineering teams breaking into smaller groups (a product manager, a UX or agent-experience designer, and at least one AI-native engineer), with each member covering business goals, agent management and product design simultaneously. Their phrasing is direct: role compression is turning software engineers into product engineers.

The roles that are forming

Strip away the naming chaos and a small number of stable shapes are visible.

The product engineer

The dominant term for the re-bundled generalist. An engineer who owns the why, not just the how, extending their scope to problem definition, user context and post-launch iteration. It absorbs analysis, much of testing, and the implementation-detail half of product management. The argument for it is coordination cost: when work has to pass from engineer to designer to backend lead to QA, you have already lost.

The forward deployed engineer

The same breadth, pointed outward. An engineer embedded with a customer, shipping production code inside the customer’s environment, accountable for the product creating value there, and feeding what they learn back upstream. Palantir invented it; OpenAI and Anthropic both launched dedicated deployment ventures within days of each other in May 2026, and Google, Databricks, Salesforce and a long tail of vertical AI startups followed.

This is the part of the map I live on. Deploying AI systems into museums means shipping into an environment you do not control, cannot fully simulate, and cannot quietly roll back. A web deploy that fails gets reverted in ninety seconds. A device on a gallery floor that fails is a visible failure in front of the public, on hardware you may be four hundred miles from, possibly with the network down. That environment teaches something that is hard to learn from a laptop: the work that matters is almost never the model. It is the offline fallback, the failure mode nobody specified, the operating hours nobody wrote down, the integration that only breaks at the edges. Those are verification problems wearing engineering clothes, and they do not compress.

The AI engineer

The counterweight to the generalist trend, and the reason “everyone becomes a generalist” is too simple. An analysis of around 1,000 job descriptions found the AI engineer is best described as a production-oriented engineer specialising in building, evaluating and operating systems on top of foundation models, with employers prioritising retrieval, integration and deployment over fine-tuning or research. This is a genuine new specialism forming while others dissolve, and it is priced accordingly, at a US median around $173,000 and total compensation averaging well over $240,000.

The quality or evaluation engineer

Quality moving upstream from finding bugs to designing the systems that make correctness measurable.

The platform engineer

The unglamorous winner. When change volume rises and instability follows, whoever owns the paved road becomes load-bearing.

The distinction worth internalising

Product engineer and forward deployed engineer look nearly identical day to day. The distinguishing question is simple: is there a product standing behind you?

If yes, you are fitting an existing product to a client, your bespoke work is temporary by design, and half your value is the feedback loop upstream. If no, you are the product, and everything you build is permanent. An engineer with no upstream who behaves like an FDE ships shortcuts that never get retired.

The honest counter-argument

I would not trust this thesis if it had no opposition, so here is the strongest case against it.

Jevons, not extinction. Every previous automation of software production (compilers, high-level languages, frameworks, cloud) reduced the cost of building software and increased the number of engineers, because cheaper software meant more software. There is no strong prior reason this time is different.

Titles churn constantly. Prompt engineer was the future of work in 2023 and a curiosity by 2025. Naming noise is not structural change, and much of what is described as re-bundling is just recruiters copying each other.

The generalist swing is cyclical. The industry has oscillated between generalists and specialists for forty years. One prediction holds that role count will shrink as far as it can before specialisation expands it again, which is a claim that we are watching a cycle, not a transformation.

All three are fair. My response is narrower than the sceptics might expect: the direction of the re-bundling is well evidenced; the endpoint is not. What is genuinely different this time is not the cost reduction itself but where it landed: precisely at the artefact layer that role boundaries were drawn around, while leaving verification untouched. That asymmetry is the thing to watch. If verification also gets cheap, the whole argument changes.

Three horizons, and the specific bets I would make

What follows gets progressively less certain, and I have labelled it accordingly. I would rather be specific and wrong than vague and unfalsifiable, so each prediction below names a role and states the evidence I am extrapolating from.

Now to twelve months: high confidence

Titles stay chaotic; read responsibilities, not labels. AI fluency stops being a differentiator and becomes table stakes. In small teams, dedicated analysis and manual testing seats quietly disappear. Evidence beats credentials in hiring: a shipped, verified thing outperforms a line on a CV.

The concrete bet: the evaluation engineer stops being a curiosity and becomes a budgeted line item. When review time is already up 441% and roughly a third more pull requests are merging entirely unreviewed, the bottleneck is measurable, and measurable bottlenecks get owned by someone. Expect “evals” to follow the exact path “SRE” took between 2014 and 2018: a practice, then a title, then a team, then a budget.

One to three years: medium confidence

Titles consolidate onto a small set: product engineer, AI engineer, forward deployed engineer, platform engineer, and some form of quality or evaluation function. Career ladders get rewritten around scope of ownership rather than technical depth alone. Team shapes shrink: fewer people per project, more projects per person.

Three specific roles I expect to be named, staffed and advertised in this window:

1. The agent operations engineer, or agent SRE. Gartner projects that 33% of enterprise software applications will include agentic AI by 2028, up from less than 1% in 2024. It also projects that over 40% of agentic AI projects will be cancelled by the end of 2027, and that 40% of enterprises will demote or decommission agents after governance gaps surface in production. Put those together and the implication is unavoidable: a large population of non-deterministic systems will be running in production, failing in ways traditional monitoring was never designed to catch. Someone carries that pager. My bet is that by 2028 “agent incident” is a standard category in mainstream incident-management tooling, agent fleets have named on-call rotations, and the role is compensated like senior SRE rather than like support.

2. The AI assurance engineer. This is the prediction I hold most confidently, because it has a date attached to it. LinkedIn’s 2026 Skills on the Rise data shows AI governance demand up 150% year over year, with more than 14,000 roles carrying an AI governance title and US hiring averaging 71 new roles a week through 2026. Against that, the 2026 Global CISO Leadership Report finds only 2% of organisations describe their AI governance as optimised while 73% call it ad hoc. Now add regulation: the EU AI Act’s transparency obligations and general-purpose AI enforcement powers land on 2 August 2026, and while the high-risk obligations were deferred in the simplification package, they arrive on 2 December 2027 for stand-alone Annex III systems and 2 August 2028 for AI embedded in regulated products. Deferred is not cancelled. It is a scheduled hiring wave with eighteen months of warning. The bet: this becomes an engineering role rather than a legal one. The person who matters is not the one who writes the policy document but the one who builds the evidence pipeline that proves the policy holds: model cards generated from CI, eval results traceable to releases, audit logs that survive a regulator reading them. By 2028 I expect mid-size AI companies to staff an assurance engineer per product line the way they staff a security engineer today.

3. The agent experience designer. Gartner already names “agent-experience designer” in its team-shape forecast, and it points at something genuinely new: when a meaningful share of your product’s consumers are other software agents, the design surface changes. Tool schemas, structured affordances, machine-readable state, the protocols agents use to discover what your system can do. These become design problems, not just API decisions. The bet: within three years, job specs start distinguishing “human-facing” from “agent-facing” design the way we currently distinguish frontend from backend.

And the junior pipeline becomes an acute strategic problem. It takes roughly five to nine years to grow a graduate into a reliable senior. Junior intake has been suppressed since 2023, so the arithmetic mechanically produces a senior shortage in the early 2030s. There is no way to hire your way out of a cohort you never trained. IBM reportedly moved the other way in early 2026, tripling junior intake while restructuring the role toward interpreting customer needs and validating AI output. That is the reframe that works: a 2026 junior should be auditing AI-generated code and evaluating competing implementations, not writing boilerplate. I would rather hire someone who can tell me why a plausible-looking implementation is wrong than someone who can produce another plausible-looking implementation.

Three to ten years: speculative, treat these as bets

The unit of employment shifts from a role on a team toward accountability for an outcome. Re-specialisation begins, this time around autonomy, verification and safety.

Domain fluency becomes the scarce input, because it is the part that does not generalise. A model can learn your stack far faster than it can learn your client’s regulatory reality, their procurement cycle, or the three things their inspectors always ask about. I expect the highest-paid engineers of the early 2030s to be described by the domain they are fluent in rather than the stack they use: a clinical systems engineer, a claims engineer, a grid engineer. The stack becomes the commodity; the domain becomes the moat.

Autonomy safety becomes a named engineering discipline. Gartner expects at least 15% of day-to-day work decisions to be made autonomously through agentic AI by 2028, up from zero in 2024. If that holds even approximately, then by the early 2030s a meaningful fraction of consequential decisions inside organisations will be made by systems no individual authored. Defining the boundaries of what a system may decide unsupervised, and proving those boundaries hold, is a distinct skill from building the system. I expect it to separate out the way security separated out of general engineering in the 2000s.

And trust becomes the commercial asset. The question customers will pay a premium for is not whose model scores better on a benchmark. It is who will stand behind the system, in person, when it fails at two in the morning. I am reasonably confident about this one because it is already true in my corner of the market: nobody buying a public-facing deployment has ever asked me about model architecture. They ask what happens when it breaks on a Saturday, and who picks up.

What to do about it

If you are an engineer, an analyst, a tester or a designer reading this as a career question, the practical answer is unglamorous and mostly unchanged by any of the above.

Stop optimising for the artefact and start optimising for the outcome it was supposed to produce. Get physically close to a real user, and ask questions rather than take requirements. Volunteer for the ugliest integration on your team, because integration is where the difficulty concentrated when everything else got easy. Ship one thing end to end, alone, all the way to production. Learn to verify well, and learn to demo well. Those are now the scarce halves of the job.

And pick one axis of genuine depth to defend while you widen your range around it. The generalist swing is real, but a generalist with no depth is a coordination layer, and coordination layers are exactly what this transformation is removing.

The roles are being redrawn around two questions: who can define the problem, and who will stand behind the answer. Everything else is a title.

I write about the gap between working models and working systems. If that is your problem too, From Model to Product is the long-form version of this argument, and you can get in touch here.