The Three Roles

Before the first module, it helps to name the three roles this path sits between, because the differences shape almost everything you are about to learn.

When I started, the work was barely divided. Someone explored the data, trained a model, and somehow it ended up in production. As models became one part of a much larger system — and then as foundation models made training optional for many problems — the work split into three roles with genuinely different questions to answer. You will work alongside all three, and this path is about the engineering half of that picture.

What a data scientist does

A data scientist proves that a model can work. This is the research-focused role: they explore the dataset, frame the problem, try approaches, and produce something that scores well — the creative, uncertain work of finding signal in data and showing that a useful prediction is even possible. It is research in the practical sense, running experiments to answer a question, not engineering a system anyone else has to run.

The output is usually a notebook: cells that run top to bottom, in order, on one machine, and produce a number worth believing in. That is the right output for the job. The question a data scientist is answering is “can this work?”, and a notebook answers it well.

What a machine learning engineer does

A machine learning engineer makes a trained model something other people can rely on — most often a classical model, the kind a data scientist trains on tabular data with tools like scikit-learn or XGBoost. The question changes from “can this work?” to “will this keep working when I am not watching it?” — and that second question is most of the job.

Concretely, the work is turning a prototype into a system: a notebook becomes a package that installs anywhere and runs as a program; inputs are validated at the boundary so bad data fails loudly instead of scoring nonsense; the environment is pinned so it reproduces on another machine; the model is served behind an API, deployed to the cloud, and monitored so you find out it has drifted before your users do. Each of those is a specific failure waiting to happen, and the engineer’s judgment is knowing which ones matter and closing them before they fire.

None of this makes the model more accurate. It makes the model dependable, which is a different and equally hard problem.

What makes the role hard to pin down is that it sits at the intersection of three disciplines and borrows from each. From software engineering it takes the craft of writing modular code, testing it, and running it as services and containers. From data engineering it takes building the pipelines that feed the model — the ETL and feature work — though usually not the petabyte-scale streaming infrastructure a dedicated data engineer owns. From data science it takes enough statistics and modeling judgment to tell a real result from a flattering one. You do not need to be the best in the room at any of the three; you need to be fluent enough across all of them to carry a model from a notebook to production without dropping it at a boundary, because every one of those boundaries is owned by a different specialty.

That is also why the part of the job that surprises people is not the code, it is the coordination. A machine learning engineer spends much of the week as the connective tissue between teams: getting the data they need from data engineering, the framing they need from data science, and the integration they need from the product team. A large share of the work is communication — explaining to non-technical stakeholders where machine learning actually solves a business problem and where it does not, and making sure the data a future model will need is being captured now, upstream, before anyone has asked for it. The model is the visible part; the relationships that keep it fed and pointed at a real problem are most of what the role actually is. Building the system is hard, and most of this path is about building it well. But the other half of the job is translation: turning what you built into something other people can understand, trust, and act on — what it does, what it does not do, and what it can be relied on for. An engineer who can do the first but not the second ships systems nobody adopts, and this path treats that translation as a skill to practice, not an afterthought.

What an AI engineer does

An AI engineer — an LLM engineer — works on systems built on top of a large language model someone else already trained. That is the main difference from machine learning engineering — there is no training run to operationalize, the model is a given, and the engineering is everything around it. The “given” model comes in two forms, and the role spans both. One is a closed model reached through an API — Anthropic’s, for instance — where you never see the weights and the work is entirely the system around the calls. The other is an open-source model you host yourself: you download the weights and stand up the serving infrastructure, which adds the deployment, GPU, and latency concerns of running a large model in production on top of the product work. Either way the model is a starting point you build around, not something you trained.

The question here is “how do I get reliable behavior out of a model I do not control?” The work is prompting and context design, retrieval so the model answers from your data rather than its memory, tool use and agent loops, and — the part that is easy to skip and expensive to skip — evaluation, because a language model has no single accuracy number you can read off a test set. Much of the discipline overlaps with machine learning engineering: it still has to be packaged, served, deployed, and monitored. What differs is that the failure modes are behavioral — a wrong-but-confident answer, a prompt injection, a runaway cost — rather than a metric that drifted.

Those are three clean definitions, and real teams are messier than definitions. On a large team the roles are separate people with separate titles. On a small team one person is the data scientist and the machine learning engineer, exploring in a notebook in the morning and hardening it into a package in the afternoon. Job titles drift too: plenty of postings say “data scientist” for work that is mostly engineering, or “ML engineer” for a role that is really building LLM products. So the useful skill is not memorizing which title does what — it is recognizing which kind of work is in front of you, because that is what tells you whether the job right now is finding signal, making something dependable, or getting reliable behavior out of a model you did not train. The same person often does all three in a week.

The handoffs

Most of this work starts at a handoff, and it helps to picture what literally crosses it. A data scientist hands over a .ipynb notebook, maybe a saved model file, and a number to beat — “test AUC 0.81” — along with the implicit claim that the columns it expects and the order the cells run in are written down somewhere. The machine learning engineer’s job begins where that proof ends, and the first question they ask of the handoff is blunt: will this run anywhere but your laptop? Usually the answer is no — the notebook depends on cells run in order, paths that exist only on one machine, and library versions nobody recorded — and closing that gap is the work. An AI engineer skips the training entirely and starts from a model that already exists — whether a closed one behind an API or an open one they host themselves — then does the same kind of engineering around it.

This path teaches the engineering side of that picture — the machine learning engineer’s job first, because it is the foundation the AI engineer’s work is built on too. You will take a working script, turn it into a package, put it under version control, make its imports robust, validate its inputs, and make it reproducible — the first half of turning a prototype into a product. You do not need to have been a data scientist to do this work. But you will almost always start from someone else’s model, trained or pretrained, and turning it into a system people can trust is the role you are here to learn.

It is worth saying plainly where this leaves you, because the title you are hired under may not match the work. You might be hired as a “data scientist” and discover the job is mostly making models dependable, or hired as an “ML engineer” and spend your days on LLM products. The engineering this path teaches is the part those titles have in common — the work that turns any model, trained or pretrained, into something a team can run and trust. Learn it and you are equipped for the engineering half of all three roles, whatever the business card ends up saying.