An AI engineer, an ML engineer, and a data scientist all work with models, but they sit at different points in a model's life: the data scientist asks what the data means and whether a model should exist, the ML engineer trains and serves custom models at scale, and the AI engineer builds products on top of pre-trained models through an API. They get confused constantly because the words overlap — but the day-to-day work, the tools, and the output are genuinely different.
If you're trying to figure out which of these you're becoming — or which one you actually need to hire — this lesson draws the lines. We'll put the three roles side by side, expand what each one really does, and then answer the question that brought most people here: which of them builds the LLM apps this course is about.
AI engineer vs ML engineer vs data scientist, at a glance
The clearest way to see the difference is by what each role produces and where it sits in the model lifecycle. Read down the "primary output" column first — that's the fastest tell of who does what.
| Role | Primary output | Typical tools | Where it sits in the lifecycle |
|---|---|---|---|
| Data scientist | Insight and a decision: does a model help, and what does the data say? | Notebooks, SQL, pandas, statistics and visualization libraries | Before the model — framing the problem, exploring data, prototyping |
| ML engineer | A trained, deployed model serving predictions in production | PyTorch/TensorFlow, training pipelines, feature stores, model serving | Building the model — training, evaluation, deployment, monitoring |
| AI engineer | A product feature built on a pre-trained model, shipped and observable | Prompt editor, pipelines, eval suites, run traces, an LLM API | After the model — wiring an existing model into a reliable system |
The data scientist
A data scientist starts with a question and a pile of data, and their job is to turn one into an answer about the other. Should we even build a model for this, or does a simpler rule do? What do the numbers say about churn, or pricing, or which users convert? They live in notebooks and SQL, run experiments, and communicate findings — often the most valuable thing they ship isn't a model at all but a clear "here's what the data supports, and here's what it doesn't." When a model does make sense, they'll often prototype it to prove the idea, then hand it off to be built for real.
The ML engineer
An ML engineer builds and runs custom models in production. This is the role that gathers a dataset, designs or picks an architecture, runs training jobs, evaluates the result, and stands up the infrastructure that serves predictions at scale — the recommendation model, the fraud detector, the demand forecaster. Their world is training pipelines, feature stores, GPUs, and model-serving systems, and their hard problems are things like drift, retraining cadence, and keeping a served model fast and accurate under real load. When you need a model that doesn't exist yet, tuned to your own data, this is who builds it.
The AI engineer
An AI engineer builds products on top of models that already exist. Rather than training a model, you reach for a capable pre-trained one through an API and engineer everything around it: the prompt that shapes its behavior, the schema that constrains its output, the pipeline that sequences the steps, and the eval suite that keeps the whole thing honest as you change it. Your hard problems aren't training loss curves — they're reliability, cost, latency, and observability of a probabilistic component in your request path. You're the bridge between a raw model's capability and a feature your users can actually depend on.
In practice these roles hand off to each other rather than compete. On a mature team a data scientist might frame a problem and prove that a model helps, an ML engineer might train and serve a specialized model for it, and an AI engineer might wrap a pre-trained model in a pipeline for a different feature entirely — all in the same product. The lines blur at small companies, where one person wears two or three of these hats before lunch. But knowing whose work is whose still matters: it tells you which skill to reach for, which tool the job actually needs, and — when you're hiring — which role you're really looking for.
Which one builds AI apps?
The AI engineer does. When you build an AI app today, you almost never train the model yourself — you call a strong pre-trained one through an API and put your effort into the system around it: prompts, schemas, pipelines, evals, and traces. That's AI engineering, and it's why the role exploded the moment capable models became a few lines of API away. The data scientist might tell you whether the feature is worth building, and an ML engineer might one day train a specialized model to slot in, but the person who turns a pre-trained model into a shippable, reliable product is the AI engineer.
This is also why the barrier to entry dropped so sharply. A decade ago, putting intelligence in your product meant doing the data scientist's and ML engineer's jobs first — collect data, train a model, stand up serving infrastructure — before you could ship anything. Today a capable model is an API call, so the expensive, specialized parts are already done by someone else, and the work that's left is engineering: shaping prompts, sequencing steps, and measuring quality. You don't need a research background or a GPU cluster to start; you need the engineering habits to make a probabilistic component behave. That's the shift that turned "build an AI app" from a research project into a job you can learn.
That's also why so much of the conversation collapses into a narrower question — where does prompt work end and engineering begin? Next, read "AI engineering vs prompt engineering" to see why a great prompt isn't the same as a reliable system, and what the discipline adds on top of the prompt.