There was a time when a company could say: “We need a Java developer.” The technology was reasonably clear. The responsibilities were reasonably clear. And the skills expected from the person were reasonably clear.
Then came AI.
Today, a typical AI job description can look something like this:
LLMs. RAG. Prompt Engineering. Agents. Agentic AI. Machine Learning. Deep Learning. Python. LangChain. Vector Databases. MCP. Cloud. MLOps. Kubernetes. APIs. Fine-tuning.
And finally: Experience: 3–5 years.
Something doesn’t feel right.
The problem isn’t that these technologies are unimportant. The problem is that AI has become an ecosystem, but we are still trying to describe it as a single job.
AI has quietly split into several different engineering jobs
Look at what is happening today.
Someone is working on how a large language model — the kind of AI that reads and writes text, like ChatGPT — understands context, how it behaves, and how its performance can be improved.
Someone else is building a system that takes thousands of company documents, turns them into a searchable form, finds the right passage, and hands it to the model.
Another engineer is building agents — AI that can call other software, look up a database, use a tool and finish a task, instead of only replying with text.
Another person is designing workflows where several agents plan, act, check their own work and recover when something fails.
And another engineer is taking all of these capabilities and turning them into a real product that customers can actually use.
We call all of them “AI Engineers.”
Technically, that’s understandable. Professionally, it creates confusion.
So what exactly is an AI Engineer?
An AI Engineer is usually the person who connects the pieces into a working product. They take an existing model, add company knowledge to it, give it tools to act with, wire it into current systems, and get it running safely for real users. They build with models rather than build the models themselves.
Perhaps the easiest way to understand today’s AI landscape is to stop thinking about job titles first. Think about the AI system itself.
At the centre, you may have a large language model. The model provides the reasoning and language ability. But a model by itself doesn’t know your company’s latest policies, customer records or internal documents.
That’s where RAG comes in. RAG stands for retrieval-augmented generation, and it simply means fetching the right document first and giving it to the model before it answers. Amazon Web Services describes it as pointing the model at an outside knowledge source instead of relying only on what it learned during training.
But knowing something isn’t the same as doing something. If the AI needs to search a system, call another piece of software, update a database or perform an operation, we introduce tools and agents.
As these systems become more independent, we start talking about agentic AI.
And eventually, somebody has to bring all of this together into a reliable application, connect it to existing company systems, secure it, deploy it and keep watching it. That’s where the AI Engineer becomes extremely important.
LLM Engineer: going deeper into the brain
An LLM Engineer is mainly concerned with the language model itself.
Their world includes model behaviour, prompting, context, embeddings (turning words into numbers a computer can compare), fine-tuning (retraining a model on your own examples so it fits your task better), evaluation and speed.
They work much closer to the model than an application-focused AI Engineer. The question they are trying to answer is often: “How can we make this model perform better for our particular problem?”
This can involve deep knowledge of how these models are built, how they are retrained, and how their answers are measured. It’s a specialised discipline. And an excellent LLM Engineer doesn’t necessarily need to be an expert at building an entire company application.
RAG Engineer: giving AI the right knowledge
Now consider a different problem. Suppose an organisation has 20 years of documents, policies, manuals, contracts and internal knowledge. The model doesn’t automatically know any of it. Someone has to build the bridge between the company’s knowledge and the model.
That’s where RAG engineering comes in. The work may involve breaking documents into pieces, converting them into a searchable numeric form, storing them in a vector database (a store built for finding text by meaning rather than by exact words), searching, filtering and ranking the results.
The challenge isn’t simply: “Can I connect a vector database to a model?”
The real challenge is: “Can I consistently find the right information, and give the model enough evidence to produce a reliable answer?”
That’s a very different engineering problem.
AI Agent Engineer: moving from answering to doing
Now imagine telling an AI: “Find the relevant customer information, check the order status, calculate the refund and create a support ticket.”
This is no longer just a question-answering system. The AI has to decide what actions are required. It may need to:
- call another piece of software,
- query a database,
- use a calculator,
- inspect the result,
- decide what to do next,
- and finally complete the task.
This is where AI Agent Engineering comes into the picture. The focus shifts towards tool calling, sequencing the steps, memory, keeping track of state, handling events and running actions safely.
The question becomes: “How do we make AI capable of performing useful actions?”
And then comes Agentic AI
Agentic AI takes this one step further.
Instead of giving the AI one fixed sequence — Step 1, then Step 2, then Step 3 — we let the system reason about the task. It might decide: plan, act, look at the result, judge it, change the plan, then act again.
This creates much more powerful systems. It also creates much harder engineering problems:
- What happens when the agent makes a wrong decision?
- What happens when a tool fails?
- What happens when the agent gets stuck?
- How do we stop it from taking an unsafe action?
- How do we know why it made a particular decision?
- How much does every one of these loops cost?
- How do we bring a human into the process when needed?
These are not simply “prompt engineering” questions any more. They are AI systems engineering questions.
And this is where the AI Engineer fits
An AI Engineer is often the person who connects all these pieces.
They may not be the deepest expert in how the model is built. They may not spend their whole day training models. They may not specialise only in search and retrieval. They may not design every part of a multi-agent system.
Instead, their strength is understanding enough of these capabilities to build a complete, production-ready AI solution.
They might take LLM + RAG + tools + agents + APIs + database + cloud, and turn it into a real product.
That’s a very different skill from simply knowing how to use a model.
What is the difference between an AI Engineer and an ML Engineer?
An ML Engineer builds and trains the model itself, working with data, features, training and accuracy. An AI Engineer works one layer above, taking models that already exist and turning them into applications, agents and products. The two overlap, but they are not interchangeable jobs.
This distinction matters. Machine Learning Engineering didn’t disappear because generative AI arrived. ML Engineers still work on the chain of data, features, model, training, testing, deployment and monitoring.
They may work with classical machine learning, deep learning, recommendation systems, computer vision (software that understands what a camera sees), forecasting or other predictive models. Some ML Engineers will specialise in large models. Some won’t. That’s perfectly fine.
Recruiters increasingly draw the same line. Upwork’s own guide for hiring managers separates the two roles the same way: one builds models, the other builds with them.
The roles at a glance
Each role is really defined by the question it exists to answer.
- LLM Engineer — “How do we make this model perform better for our problem?”
Focus: model behaviour, prompting, fine-tuning, evaluation, speed. - RAG Engineer — “Can we reliably find the right information for the model?”
Focus: documents, embeddings, vector search, ranking, retrieval quality. - AI Agent Engineer — “How do we make AI perform useful actions?”
Focus: tool calling, workflows, memory, state, safe execution. - Agentic AI Architect — “How does the system plan, recover and stay safe on its own?”
Focus: planning loops, failure handling, cost, oversight, guardrails. - AI Engineer — “How do we turn all this into a product people can use?”
Focus: integration, APIs, cloud, security, deployment, monitoring. - ML Engineer — “How do we build and train a model that predicts well?”
Focus: data, features, training, evaluation, deployment, monitoring.
So should one person know all of this?
No. A good AI professional should have breadth, but breadth does not mean expertise in everything. Understanding how the pieces fit together is reasonable to expect. Being a specialist in all of them is not, and asking for it is the fastest way to write a job advert nobody can honestly answer.
This is probably the biggest misunderstanding in today’s AI hiring market.
- Someone can understand large language models without being a model-training specialist.
- Someone can be excellent at RAG without being an expert in deep learning.
- Someone can build sophisticated AI agents without knowing how to train a model from scratch.
- Someone can build production AI applications without writing the underlying algorithms.
- And someone can be an exceptional ML Engineer without being an expert in agent architecture.
That is not a gap. That is specialisation.
The real problem with today’s AI job description
Perhaps this is where organisations need to rethink their approach.
Instead of writing: “Looking for an AI Engineer with expertise in LLM, RAG, Agents, ML, Deep Learning, MLOps, Cloud, Kubernetes, Python, Java, React, Vector DB, Prompt Engineering, Fine-tuning…”
we should first ask: What problem are we actually hiring this person to solve?
- Building models? Then hire for ML or LLM Engineering.
- Building company knowledge systems? Then emphasise RAG and data retrieval.
- Building automated workflows? Then emphasise Agents and Agentic AI.
- Adding AI to an existing product? Then emphasise AI Engineering and software engineering.
- Building the company-wide AI platform? Then you probably need an AI Architect or AI Platform Engineer.
The technologies may overlap. The depth doesn’t have to. If you are hiring right now, our guide to AI job roles, salaries and who is hiring in 2026 is a useful companion to this.
AI is becoming like software engineering
Think about traditional software development. We don’t expect one person to be, at the same time, a database specialist, a frontend specialist, a backend specialist, a cloud architect, a security engineer, a DevOps engineer and a distributed systems expert.
A good software engineer understands the broader system. But people specialise.
AI is heading in exactly the same direction. The difference is that the specialisation is happening much faster.
The real skill is knowing where you fit
For people building careers in AI, this is actually good news. You don’t need to become an expert in everything called AI.
Instead, build a strong foundation and then decide where you want your depth. You could go deeper into models. Or knowledge and RAG. Or agents and automated systems. Or production AI applications. Or machine learning. Or eventually AI architecture and platform engineering.
The strongest professionals will probably be the ones with T-shaped skills: a broad understanding across the AI ecosystem, with deep expertise in one or two areas. If you are picking a direction, it helps to know which AI skills clients are actually paying for right now.
One AI industry. Many different engineering problems.
That’s perhaps the most important shift happening right now.
LLM Engineering is not the same as RAG Engineering. RAG Engineering is not the same as Agent Engineering. Agent Engineering is not the same as Agentic AI architecture. AI Engineering is not the same as ML Engineering.
And none of these roles exist in isolation. They form an ecosystem.
The future AI team may not be about finding one person who knows everything. It may be about building a team where each person understands the bigger picture while bringing different depth and expertise.
Because as AI becomes more capable, the technology stack becomes broader. And when the technology becomes broader, job descriptions need to become clearer — not longer.
Maybe the next step in AI hiring isn’t another AI title. Maybe it’s simply better clarity about what we actually expect an AI professional to build.
Frequently Asked Questions
What is the difference between an AI Engineer and an ML Engineer?
An ML Engineer builds and trains models from data. An AI Engineer takes existing models and turns them into working products, connecting them to company systems, tools and users. The skills overlap, but the daily work and the goals are different.
Do I need to know LLMs, RAG and agents to get an AI job?
You should understand what each one does and how they fit together. You do not need to be an expert in all of them. Most employers get better results by hiring for depth in one area plus broad understanding of the rest.
Is prompt engineering still a real job?
It is now usually part of a bigger role rather than a job on its own. Prompting matters, but the harder work sits around it: retrieving the right data, calling tools safely, handling failures and keeping costs under control.
Why do AI job descriptions list so many skills?
Because AI split into several engineering disciplines very quickly, and hiring templates have not caught up. Many adverts combine requirements from two or three different jobs, which attracts a lot of applicants and the right one for none of them.
How should a company write a better AI job description?
Start with the problem, not the tool list. Decide whether you are building models, knowledge systems, automated workflows, or a product on top of existing models. Then list the skills that problem actually needs, and mark the rest as nice to have.
This article is based on an original piece by the author on how AI roles are splitting into separate engineering disciplines.
