The new engineering roles that did not exist 3 years ago

Open any engineering job board and you will find titles that had no meaningful presence in 2023. Some of them describe genuinely new disciplines with their own body of practice. Others are existing work with a fashionable label, and they will quietly disappear back into the roles they came from.

Telling those two groups apart is now a hiring decision with real money attached, because one deserves permanent headcount and the other does not. So which of the new engineering roles are actually durable, and how should you staff the ones that might not exist by 2029?

The answer starts with why the org chart moved so fast in the first place, and how remote tech talent markets responded to it.

Why the engineering org chart changed in three years

Three things happened at once. Models became good enough to put in front of customers, cloud platforms absorbed most infrastructure work, and regulation started attaching consequences to how data and models are handled.

Each of those shifts created work that did not previously belong to anyone. Somebody has to monitor a model that degrades silently, somebody has to test output that is different every time, and somebody has to prove to an auditor where the training data came from.

Our review of the most in-demand tech skills covers which of these areas is growing fastest. New roles appear when work becomes both continuous and specialized. If the work is occasional, it gets absorbed by an existing role. If it is continuous but generic, it becomes a shared skill instead of a job title.

Those two conditions separate a real role from a temporary label. Newness also cuts both ways.

A discipline that appeared in three years has not had time to prove it will still be here in three more. The churn that produced these titles is the same churn that will dissolve some of them, which is why naming the new roles is only half of what anyone hiring actually needs.

The engineering roles that genuinely did not exist

These have their own tooling, their own failure modes, and enough continuous work to justify a dedicated person. Accelerance, which surveys software development firms worldwide, points to exactly this pattern in its 2026 rate and trend analysis, noting the rise of engineering roles that barely existed three years ago and now command a premium.

• Machine learning platform engineer. Owns model serving and monitoring in production, including rollback when a model degrades. Distinct from a data engineer because the artifact degrades on its own without any code changing.
• Evaluation engineer. Builds test harnesses for non-deterministic output. Closer to a QA engineer than to a data scientist, though traditional testing asserts that a function returns a specific value and this discipline had to invent everything else.
• AI security engineer. Handles prompt injection, model extraction, and training data poisoning. These attack surfaces did not exist in a meaningful commercial form three years ago.
• AI governance lead. Documents provenance, maintains model cards, and answers the auditor. Created by regulation rather than by technology, and usually sourced from data analyst or audit backgrounds.
• Platform engineer. Builds the internal developer platform other engineers work on. Descended from the DevOps engineer role, though the product framing and the tooling are genuinely different.

What these share is a permanent problem to solve. A model in production will always need monitoring, and an auditor will always need evidence, so the work does not evaporate when the current wave of tooling matures.

The titles that are mostly existing work with a new name

Nothing here is fraudulent, and the people doing these jobs are doing real work. The distinction is that the work is becoming a shared competency rather than a separate seat on the org chart.

• Prompt engineer. The clearest case. Writing effective prompts is turning into a basic skill every engineer needs, in the same way that writing a decent SQL query is expected rather than specialized.
• AI engineer, in many postings. Frequently a backend engineer who calls a model API. Read the responsibilities rather than the title, because a large share of these postings describe standard application development.
• Data scientist, in many postings. Often an analyst with a different label. If the role does not involve building or tuning models it is analytics work, and a data scientist title will attract candidates expecting something else.
• Head of AI, when the remit is engineering. Usually a strategy and coordination role. Valuable, and not the same thing as someone who can ship a system.

The practical consequence is about durability rather than value. Hiring permanently against a title that is dissolving into general practice leaves you with a role description nobody can define in two years.

This is where access beats ownership. Reaching the skill through remote tech talent rather than a permanent requisition keeps the commitment reversible while the market decides what the role is called.

McKinsey's global survey of nearly 2,000 organizations found that respondents named software engineers and data engineers as the AI-related roles most in demand, ahead of the more exotic titles. That is a useful corrective. The bottleneck is usually ordinary engineering capacity rather than a novel specialization.

How to tell a durable role from a transitional one

Three questions settle almost every case, and you can run them on any job posting in about a minute.

1. Is there a permanent problem underneath it? Model monitoring and audit evidence are permanent. Working around a specific model's quirks is not.
2. Does it have its own tooling and failure modes? A discipline with dedicated tools and characteristic ways of going wrong is a real specialization. One that borrows entirely from an adjacent role is a skill.
3. Would you still need this person if the current tooling generation were replaced? If the answer is no, you are hiring against a product rather than a function.

Run those on prompt engineering, or on the agentic coding tooling that is changing how engineers work, and prompt engineering fails all three. Run them on evaluation engineering and it passes all three, because output will always need testing and the tooling for it is genuinely its own thing.

The test matters commercially because getting it wrong is expensive in both directions. Hire transitional roles permanently and you carry headcount you cannot redefine. Refuse to staff durable roles and you accumulate the invisible debt that shows up as a model nobody trusts.

Where these engineers actually come from

Requisitions for these roles routinely ask for five years of experience in a discipline that is three years old. Nobody meets that, so either the bar quietly drops or the role stays open.

The way out is to hire for adjacency rather than tenure in a title. This is already how specialized engineering roles get filled, and the Bureau of Labor Statistics shows the pattern plainly. Entry into software developer roles requires no prior experience in a related occupation, while entry into computer network architect roles typically requires five years or more of it. Specialized roles are entered sideways, from a neighboring discipline, and the newest roles are the extreme case.

Each of the five durable roles has a feeder discipline that transfers most of the way.

That is consistent with where the demand actually sits. If the feeder disciplines are the real constraint, the shortage shows up in ordinary engineering roles before it shows up in the new titles.

Competing on the title is expensive, because supply has not caught up and rates for these roles are rising. Competing on adjacency is not, because the adjacent pool is far larger and mostly unaware it qualifies.

That changes the useful interview question. Ask what someone built in the last six months rather than how long they have held the label, since in a three-year-old field recent self-directed work is the only meaningful track record.

How to staff a role that may not exist in three years

The honest answer is that you should not hire permanently against uncertainty. You should get access to the skill and keep the commitment reversible.

For the durable roles, hire permanently where you have continuous work and use augmentation to cover the gap while you search, which our guide to nearshoring for specialized roles covers in more detail. Bertoni's remote tech talent model places engineers from Latin America who work United States business hours, which matters because these disciplines are learned through code review rather than through handoff.

For the transitional roles, do not create the seat at all. Train your existing engineers and bring in specialist help for the specific project that needs it, which is what IT staff augmentation is structurally good at.

There is a third case worth naming. Where you are unsure whether the work is continuous, run it as a scoped engagement first and let the answer emerge from the workload rather than from a forecast.

For sustained programs, a dedicated team keeps the same engineers on the system long enough to build the context these disciplines depend on, and broader software engineering support covers the ordinary capacity gaps underneath.

Two roles are worth staffing before any of the exotic ones. A strong data engineer and a competent machine learning engineer resolve more bottlenecks than a prompt specialist ever will. Our AI coaching sessions exist partly to work out which of these you actually need before anyone gets hired.

Where to start

The engineering roles worth building a job description around are the ones with a permanent problem underneath them, their own tooling, and a reason to exist after the current tools are replaced. Everything else is a skill your team should be learning.

Audit your open requisitions against those three questions, and read them alongside our view of IT staffing trends going into 2026. Then fill the durable gaps properly, and cover the uncertain ones with capacity you can stop.

If you want a straight assessment of which roles your roadmap actually requires, schedule a consultation. We will look at the work rather than the titles and tell you what to hire and what to borrow.