Somewhere around late 2022, every developer CV grew an AI section. Prompt engineering now sits next to Python, "LLM integration" next to a decade of backend work, and profiles that once said full-stack quietly became "AI engineer". If you are trying to hire AI engineers in 2026, you are searching the noisiest talent pool I have seen in my career.

One pair of numbers explains the noise. In the Stack Overflow 2025 AI section, 84% of respondents said they use or plan to use AI tools in their development process. In the 2025 developer-roles data, just 1.4% identified as AI/ML engineers. Nearly everyone uses AI; almost nobody builds it. That wedge is why the CV keyword proves nothing, and why the screen has to reach the job underneath the title.

TL;DR: "AI engineer" currently covers four different jobs: the ML engineer, the applied LLM engineer, the MLOps engineer, and the rebadged generalist. The 84%-versus-1.4% gap between AI users and AI builders means the keyword alone tells you nothing. Screen for the specific job your product needs, and use one question as your sharpest instrument: show me the eval suite from your last LLM project.

Why "AI engineer" is the most inflated title in tech right now

The title inflated because the tools behind it became genuinely universal. That 84% adoption figure is up from 76% the year before in the same survey section, which also reports that 51% of professional developers now use AI tools daily. Familiarity with AI has become table stakes across the entire profession.

The builder population, meanwhile, remains tiny. Alongside the 1.4% who identify as AI/ML engineers, the roles data puts data scientists at 1.2% and "developer, AI apps" at 0.5%. For scale, full-stack developers are 27% of respondents and back-end developers 14.2%. Builders of AI systems remain a rounding error next to the people who merely use them, and every one of those users can plausibly type "AI" onto a CV.

Even the vocabulary is brand new. Stack Overflow only introduced "AI/ML engineer" as a distinct role label in 2025; the 2024 edition offered "data sci. or ML specialist" at 1.7% and "developer, AI" at 0.9% instead. When Stack Overflow's annual survey settled on a name for the job less than two years ago, it is no surprise that job ads are still confused about what they are asking for.

The inflation has a start date, too. ChatGPT launched on 30 November 2022, and that is the moment "AI experience" began migrating from research labs onto mainstream CVs.

The four jobs hiding under one title

Four distinct roles currently share the "AI engineer" badge, and each demands a different screen. Every profile below comes with one question a non-specialist can ask without bluffing.

• The ML engineer. Trains, tunes and ships models, and owns the pipelines that feed them. Google's ML-engineer certification describes the role as one that "builds, evaluates, productionizes, and optimizes AI solutions", and it demands MLOps knowledge, ML pipeline creation and metrics interpretation, while listing prompt and context engineering as merely foundational familiarity. Read that again: a vendor certification treats prompting, the skill most CVs lead with, as the entry-level layer. The question to ask: tell me about a model you took to production, and what drifted after launch.
• The applied-AI or LLM engineer. Integrates and orchestrates models that someone else trained: retrieval-augmented generation, agent workflows, model APIs, context management. This is the profile most 2026 briefs really need, and the craft is judgment about when not to reach for heavier machinery. The question to ask: describe something you refused to fine-tune, and how you solved it with retrieval instead.
• The MLOps engineer. Productionises other people's models: serving, scaling, monitoring, retraining. The exam for the same Google certification devotes whole sections to serving and scaling models, automating and orchestrating pipelines, and monitoring AI solutions, which tells you this is a discipline in its own right. The question to ask: how do you monitor a model in production, and what would trigger a retrain?
• The rebadged generalist. Uses Copilot or ChatGPT daily and relabelled the CV to match the market. By the survey numbers this is simply what most developers now are, and that 84-to-1.4 split explains why this profile dominates every keyword search. Often a perfectly good hire for a different role. The question to ask: what have you built with a model, beyond building with a model's help? The pause tells you most of what you need.

Evals: the one discipline that separates builders from users

If I could keep only one screening instrument for AI roles, it would be evaluation discipline. Anthropic's evaluation guide opens with the principle that "Building a successful LLM-based application starts with clearly defining your success criteria and then designing evaluations to measure performance against them". OpenAI's Evals repository puts it even more bluntly: "If you are building with LLMs, creating high quality evals is one of the most impactful things you can do". When both major labs lead with the same discipline, that is the profession defining itself.

The trust data explains why evals matter so much. In the same 2025 AI section, 46% of developers distrust the accuracy of AI output against 33% who trust it, and only 3% describe themselves as highly trusting. Professionals who work with these systems daily know the output is unreliable; systematic evaluation is the professional response to that unreliability. A candidate who ships LLM features without evals is not moving fast, they are shipping untested software.

So ask the sharpest question in this market: show me the eval suite from your last LLM project. Builders light up. They talk about success criteria, golden datasets, regression cases, the failure that made them add a test. Users stall, or describe eyeballing outputs until they looked right. The AI job specs I read almost never mention evals at all, which means the hiring managers who do ask this question enjoy an instrument most of the market has not discovered yet.

Real demand is exactly why precision matters

None of this is demand-denial. Stanford's 2025 AI Index reports US private AI investment growing to 109.1 billion dollars, and 78% of organisations reporting AI use in 2024, up from 55% the year before. On the product side, Salesforce's Q4 FY26 results put Agentforce at roughly 800 million dollars in ARR, up 169% year over year by the quarter ended January 2026. It is a vendor-reported figure, but it shows how fast enterprise AI budgets convert into shipped products, a dynamic I covered from another angle in hiring Salesforce developers.

Hot markets are precisely where title inflation gets expensive. When demand is this strong and fewer than 2% of developers identify as AI/ML engineers, every vague brief attracts a flood of rebadged CVs, and the cost of picking the wrong one lands six months later, in production. LinkedIn's Work Change Report projects that by 2030, 70% of the skills used in most jobs will change, with AI emerging as a catalyst; the pressure to hire is real and rising. That pressure is an argument for naming the job precisely rather than grabbing the hottest label on the market.

Do you need an AI engineer at all?

For many products, the honest answer is no. If your roadmap says "add an AI assistant to our app", the profile that ships it is usually a strong backend engineer plus a well-evaluated API integration: an applied-LLM problem at most, and sometimes not even that. Model APIs have made the integration layer accessible to any disciplined engineering team that takes evals seriously.

Reserve the specialist searches for specialist problems. You need an ML engineer when you are genuinely training or tuning models on your own data. You need MLOps when you are serving models at a scale where latency, cost and drift become operational problems. Everything below those thresholds is software engineering with an unusually capable dependency.

I give this advice even when it costs me the search, because a recruiter who never tells you that you do not need the hire is selling, not advising. It is also why the briefs that do come back are the right ones.

How to screen an AI engineer before you hire

1. Name which of the four jobs your brief actually is. ML engineer, applied-LLM engineer, MLOps, or a strong generalist with AI literacy. Write the brief around the job, not the title; this framing is the backbone of my data and analytics practice.
2. Ask for the eval suite. "Show me the evals from your last LLM project" separates builders from users faster than any other question, and you do not need to be technical to hear the difference between a testing philosophy and a shrug.
3. Probe the fine-tune-versus-retrieval judgment. Ask when they would fine-tune a model and when retrieval solves it more cheaply. Strong candidates reach for the boring answer first; weak ones reach for the impressive one.
4. Weight production evidence over demo videos. Anyone can record an impressive demo in a weekend now. Ask what happened in week six: drift, cost surprises, users breaking the prompt. Only people who have operated a system can answer.
5. Run the anti-sell check. Describe the first six months of real work and ask the candidate whether the role needs an AI engineer at all. Honest candidates audit your brief for free. And check the layer below while you are at it: models are only as good as the pipelines feeding them, territory covered in depth in hiring data engineers.

Common questions about hiring AI engineers

What is the difference between an AI engineer and an ML engineer?

In practice, "AI engineer" in 2026 usually means an applied-LLM engineer who integrates and orchestrates existing models, while an ML engineer trains and tunes models and builds the pipelines around them. Google's certification for the ML role expects MLOps, pipeline creation and metrics interpretation, with prompt engineering as merely foundational, which is a sharper distinction than most job ads manage.

Do we need a dedicated MLOps engineer?

Only if you are serving models at meaningful scale. MLOps earns its salary when serving, scaling and monitoring become daily operational concerns; below that threshold, a capable platform engineer plus your applied-LLM engineer can cover it. Hiring MLOps before you have models in production is buying the fire brigade before the building.

Can our backend team just use a model API?

Often, yes, and it is the honest first option to test. A disciplined backend team with a well-designed integration and a proper eval suite covers a large share of 2026 AI roadmaps. The failure mode is skipping the evals: with 46% of developers distrusting AI output accuracy, the real risk is shipping unevaluated LLM features, whatever the titles on the team.

What should an AI engineer's portfolio show?

Production evidence with evaluation artefacts. Look for a system that ran in front of real users, the eval suite that guarded it, and a candid account of what drifted or failed after launch. A portfolio of polished demos without evals or operational history is the signature of the rebadged generalist, whatever the title says.

---

I keep two to four active searches at a time, so every AI brief starts with the conversation above: which of the four jobs is this, and does it exist at all? Three CVs that fit beats thirty that don't. If you're hiring on the AI side, tell me about the role and I'll tell you honestly which builder you need, or whether your backend team plus an eval suite gets you there first.