The title "AI Engineer" is on job boards, LinkedIn bios, and company org charts. It did not exist five years ago. Now it is one of the most posted roles in software.
The problem is that the title hides at least three different jobs.
The title is broken
Ask ten AI engineers what they do and you will get ten different answers. One is building a RAG pipeline for a legal product. Another is maintaining vector database infrastructure for a machine learning team. A third is doing statistical modelling that got relabelled during a reorg.
Same title. Completely different work. This is not a rounding error — it is the defining feature of the role right now.
The clearest way to split it is by what the job actually produces.
Three roles under one name
AI-First (roughly 69% of roles): These engineers build things that use AI directly. RAG systems, agents, LLM-powered features, chatbots, summarisation tools, structured extraction pipelines. The AI is the product, not the infrastructure behind it. Most AI engineer job postings fall here.
AI-Support (roughly 28%): These engineers build the platform that AI-First engineers work on. Evaluation frameworks, prompt versioning systems, observability tooling, internal APIs for model access. They are sometimes called ML Platform engineers or AI Infrastructure engineers. The user is often another engineer, not an end customer.
Traditional ML (roughly 2%): Roles that were called Data Scientist or ML Engineer six months ago and got renamed. The work involves training and fine-tuning models, not integrating them. The title changed; the job description did not.
When you read a job posting, the title tells you almost nothing. The responsibilities section tells you which of these three you are looking at.
It is a full-stack role
The other thing the data shows clearly: AI engineering is not a narrow specialisation. Only about 1.4% of AI engineer roles expect pure GenAI work. The rest require cloud infrastructure, containerisation, CI/CD, and often frontend or API development on top of that.
This catches candidates off guard. They study RAG architecture and agent frameworks and show up to interviews unprepared for questions about Kubernetes, database design, or system reliability. The AI-specific knowledge matters, but it sits on top of a foundation of general software engineering.
If you are preparing for these interviews, the question is not whether you need cloud and Docker knowledge. You do. The question is how deep you need to go, and that depends on which of the three roles above you are targeting.
Why this matters for interviews
The confusion in job titles creates a specific interview trap. A candidate prepares for one version of the job and interviews for a different one.
The AI-First interview will spend most of its time on system design: retrieval quality, latency, evaluation strategy, failure modes. The AI-Support interview will test infrastructure depth: how you would design an internal LLM gateway, how you handle rate limits and cost attribution, what an evaluation framework looks like at scale. A mislabelled ML interview will ask about training data, loss functions, and model selection, even if the title says nothing about any of that.
Reading the job description carefully is not just preparation hygiene. It is how you figure out which job you are actually interviewing for.
What distinguishes the best candidates
The engineers who do well in these interviews are not necessarily the ones who know the most about language models. They are the ones who can reason clearly about systems: what breaks, why, and what you would do about it.
A strong AI engineer answer does not start with a model. It starts with a problem statement, works through the constraints, and picks tools that fit. The model is one component. The evaluation strategy, the observability layer, the data pipeline, the deployment infrastructure: those are the other components, and they take up most of the actual engineering time.
If you are preparing for AI engineer roles, get clear on which of the three jobs you are targeting. Then build the preparation around what that specific role actually tests.