This is the most-advertised AI title in Britain — around 84 employers are using it as we index them — and it is also the newest, which means it has no gatekeeping. There is no degree for it, no chartered body, no accepted definition. Anybody who has built something with a model API can put it on a CV truthfully.

The practical consequence is volume. Post this role and you will get a great many applications, most from people who have completed a tutorial. The skill this page is about is sorting that pile quickly and without being unfair to the self-taught, who include some of the best people in the field.

What the role is, stated plainly

An AI engineer builds products on models they did not train. That is the whole definition, and it puts the job much closer to backend engineering than to data science — the model is one unreliable, slow, expensive dependency among several, and the work is making a reliable product out of it.

Which means the competences you are buying are mostly ordinary good engineering: API design, queues, caching, retries, observability, cost control, and the judgement to know which parts of a problem should not involve a model at all. The AI-specific layer — retrieval, evaluation, prompt structure — is learnable in weeks by somebody who already has the rest. The reverse is not true, and that asymmetry should drive your whole process.

A sift that works on a large, unfiltered pile

Three passes, in this order, because each is cheaper than the next.

First, look for something that ran. Not a repository — a thing with users, even a small one. A side project with fifty real users tells you more than a polished tutorial clone. You are looking for evidence that somebody has experienced their own software failing in front of somebody else.

Second, ask for one paragraph on a decision they reversed. Send it as a written question before any call. It costs you nothing, it cannot be answered from a template, and it separates people who have operated something from people who have built something once. The writing quality is a bonus signal you get free.

Third, a forty-minute conversation about their own system. No puzzles. Ask what it cost, what broke, how they knew it was working. You are listening for numbers and for specifics.

That sequence disposes of most of the pile before anybody spends an hour interviewing, which is the actual problem with this role.

The questions that separate a builder from a tutorial graduate

All four are things you cannot answer from having followed a guide.

“What did your feature cost per thousand requests, and what did you do about it?” Anybody who has shipped at any volume knows roughly, and has pulled at least one lever. A blank here is the clearest single signal.

“What happens when the provider is slow or down?” Timeouts, retries with backoff, a degraded path, idempotency on anything that writes. Ordinary distributed-systems thinking and the most common gap in candidates who came via data science.

“How did you stop a user extracting something they should not see?” The answer you want is architectural — least privilege on tools, nothing confidential in a context a user can influence, output treated as untrusted. Anybody claiming a prompt prevents it has not thought about it.

“What did you deliberately not use a model for?” Restraint is the maturity signal in this discipline. A lookup, a regular expression, a rules engine, where a model would have been slower and less predictable.

Be fair to the self-taught, because the pool is full of them

This field is four years old in its current form. Almost nobody has a decade in it, and a requirement for a computer science degree or five years of experience will exclude much of the genuinely capable population while admitting people whose relevant experience is equally thin.

So judge on artefacts rather than credentials. A public repository with a commit history, a written explanation of a design decision, a system with users — these are all more predictive here than a qualification, because the field has not existed long enough for the qualification to mean anything. Several of the strongest candidates we see moved across from backend or platform engineering in the last two years and describe themselves apologetically.

When the title is wrong for what you need

Three redirections worth making before you advertise, because each has a deeper pool under a different name.

If the substance is that answers must be grounded in your own documents, that is retrieval and the RAG engineer guide covers it. If you need models trained or fine-tuned rather than consumed, that is a different discipline and the machine learning engineer guide describes it. And if the system has to plan and act over several steps, the agentic AI engineer guide is the closer match.

The plain version of this role — build and support an AI feature in a product — is the commonest genuine need and worth naming as such rather than inflating.

Pay, and why the range is so wide

Indicatively £65,000 to £95,000 for somebody who has shipped and supported a feature, £95,000 to £130,000 for genuine seniority, and above that in London for people with scale experience. Day rates from about £500.

The spread is wider than for established titles for a structural reason: with no accepted definition, the market has not settled on what the role is worth, and candidates price themselves against what they could earn as a backend engineer plus whatever premium they believe the AI label commands. That belief varies enormously. It means a strong negotiator with modest experience can ask for more than a quiet expert, and the only defence is the evidence-based sift above.