AI engineering roles: the ones nobody can name yet

The expectation was that AI would flatten engineering into generalists. An analysis of 47,101 technical job postings at Fortune 500 companies found the opposite: AI engineering roles are specialising, and companies are advertising roles they cannot yet name.

The headline number is that 53% of roughly 1,832 postings titled AI Engineer or ML Engineer require skills drawn from at least two different established roles. Those job adverts are not describing one job. They are describing two, under a title that fits neither.

What the research found

Andela's Emerging Skills Research, published on 10 September 2026, scored 2,026 distinct skills across those 47,101 postings. It identified 23 skill bundles that recur across Fortune 500 hiring without mapping to any standardised job title — of which 8 are genuinely new roles and 14 are hybrids of old and new.

The most striking single finding is that 6,758 job postings carry what the research calls the LLM Application Engineer skill bundle without naming it. Nearly seven thousand companies are hiring for the same role and none of them has a word for it.

The eight emerging roles it names are worth reading as a list, because they are less exotic than the framing suggests: MLOps Pipeline Engineer, LLM Application Engineer, FinOps Reliability Engineer, Docs-as-Code Engineer, Product Front-End Engineer, Lakehouse Analytics Engineer, DevSecOps Security Engineer and SecOps Observability Engineer.

Notice what most of those have in common. They are not model-building roles. They are roles about running, paying for, documenting, securing and observing systems that contain a model. The work that has multiplied is the work around the model, which matches what we see on delivery: nobody is short of people who can call an API, and everybody is short of people who can keep the resulting system honest.

It is also a fair description of what happened to the industry rather than to the technology. Titles are a lagging indicator: they are written by people copying the last advert that worked, and they stabilise years after the work does. The gap the research measures is the gap between what firms need today and the vocabulary they had two years ago.

Read it with the interest declared

The findings were picked up in The New Stack's coverage under the framing that AI is not making engineers generalists. That framing is the right one, and it is worth pausing on who is making the argument. Andela sells access to engineering talent, and research concluding that talent is hard to identify is research that supports its business. That does not make the figures wrong — the methodology is described, the sample is large and specific, and the conclusion is checkable against your own hiring — but it should temper how much weight the framing carries.

The methodology note also matters for how you read it: the approach detects emerging roles from a single data snapshot rather than tracking volumes over time. So this is a photograph of what firms are asking for, not evidence of a trend line. "Six thousand companies want this" is supported. "Demand grew by X" is not, and is not claimed.

The part we would treat as most robust is the mismatch itself, because it does not depend on interpretation. Either a posting asks for skills spanning two established roles or it does not.

Why a mis-titled job advert costs you real money

This reads like a taxonomy curiosity. It is a hiring failure with a measurable price, and it shows up in four places.

You attract the wrong shortlist. Candidates search by title. Post an AI Engineer role that is mostly retrieval plumbing, evaluation harnesses and cost control, and you will be read by people who want to train models — who will be disappointed by the work, and who will screen out the platform engineer who would have been excellent at it.

You interview against the wrong bar. A title sets the panel's expectations before anyone reads the description. We have watched teams reject strong candidates for a fundamentally integration-shaped job because the loop included a model-architecture question nobody in that role would ever answer.

You lose weeks. A role that takes four months instead of two is not just a delayed hire; it is a quarter of delivery absorbed by whoever is covering, usually your most senior person.

You lose the person afterwards. Someone hired against a title and handed a different job leaves within the year, and the search restarts having burned the internal goodwill that made the headcount available in the first place.

There is a fifth cost that is easy to miss because it never appears as a vacancy. When a title does not describe the work, internal candidates do not apply. The platform engineer three desks away who has quietly been running your inference costs down for six months does not see herself in an advert for an AI Engineer, so you pay an agency fee to hire the outside version of her, and she leaves within the year for the title you gave someone else.

Write the skills down before the title

The fix is unglamorous and takes an afternoon. Before opening a role, write the list of things this person will actually do in their first six months — not aspirations, the real work, in order of how much time it takes. Then choose the title that fits that list, even if the title is boring.

A useful test: read your draft advert and ask which existing person on the team it most resembles. If the answer is nobody, either the role is genuinely novel or the advert is a wish list assembled from several people's jobs, and the second is far more common than the first.

If the honest list is "build retrieval pipelines, write evaluation suites, manage inference costs, keep an agent from doing something stupid in production", then you are hiring a platform or backend engineer who will learn the AI-specific parts in weeks — and your market is far larger and considerably cheaper than the one you reach by advertising for an AI Engineer. If the list genuinely includes training or fine-tuning models, that is a different and much scarcer person, and pretending otherwise wastes everyone's time.

This is the same discipline that separates a good technical partner from an expensive one, and the same question we suggest asking when evaluating a development partner: can you state the work precisely enough that the right person recognises themselves in it?

The AI engineering roles skills that actually travel

For anyone deciding what to learn, or what to hire for, the durable observation is that the scarce skill is not prompting. It is verification.

The constraint on AI-assisted delivery is not generating output, it is knowing whether the output is right — which is why we keep returning to the point that AI coding agents move the bottleneck to review, and why building an evaluation suite that scores the trajectory rather than the final answer is the capability that decides whether an agent project reaches production. An engineer who can design that harness is useful whatever the title says, and remains useful when the current model generation is replaced.

Two of the eight names deserve a second look for what they reveal. Docs-as-Code Engineer appears because generated code arrives faster than anyone can explain it, and the explanation is now a deliverable rather than a courtesy. Lakehouse Analytics Engineer appears because retrieval quality is a data-modelling problem long before it is a model problem — the teams whose assistants give bad answers usually have bad data boundaries, not a bad model. Neither of those is an AI skill in any meaningful sense. Both are old disciplines that AI made load-bearing.

The same applies to the cost and observability roles on Andela's list. FinOps Reliability Engineer and SecOps Observability Engineer exist because running a model in production created bills and failure modes that nobody owned. Those responsibilities do not go away when the technology settles; they get absorbed into ordinary platform work, which is where most of these eight titles will end up within a few years.

So our practical advice is the opposite of the anxious version. You probably do not need to hire a new category of person. You need to describe the job accurately, look for engineers who are rigorous about testing systems they cannot fully predict, and accept that the title you use to advertise it is the least important part of the exercise. That is how we staff our own AI engineering work, and the people who are best at it mostly came from quality and platform backgrounds rather than research ones.