An AI engineer is not a machine learning engineer
The Ship AI Engineer team · Published 2026-08-07
Search for how to become an AI engineer and you get seven versions of the same list. Python, then linear algebra and statistics, then classical machine learning, then deep learning, then train a convolutional network, then pick between TensorFlow and PyTorch, then choose a specialisation. Twelve months.
Now search for AI engineer vs ML engineer and the same search engine will tell you, in the first result, that an AI engineer builds products on top of models somebody else trained (APIs, retrieval, agents) and that you do not need a doctorate or a deep mathematics background to do it.
Both pages cannot be right. The second one is.
The two jobs, in one sentence each
A machine learning engineer builds the model: gathers and cleans the data, designs the architecture, runs the training, and operates the result. The mathematics is not decoration there: it is the job. Linear algebra, statistics, optimisation, and a great deal of patience with GPUs.
An AI engineer builds the product around a model that already exists. You send a request to a model, shape what comes back into something your program can use, give the model your own documents so it stops inventing answers, give it tools so it can do things instead of describing them, measure whether any of it works, and then run the whole arrangement without going bankrupt.
You will write a lot of Python. You will not write a training loop.
Why the wrong answer ranks
Not because anybody is lying. The roadmaps were written when "AI engineer" and "ML engineer" genuinely meant the same thing, and the phrase kept its old contents while the job underneath it changed. Then everyone else wrote the roadmap that was already ranking. That is how a search result becomes a consensus without anyone checking it.
The cost of the mistake is not abstract. Someone who accepts the ranked answer spends their first two months on matrix calculus for a job that will never ask them for it, and quits before reaching the part they were actually interested in, which was, almost always, building something.
What the work is actually made of
Six things, roughly in the order they bite:
Calling a model. An HTTP request with a body, headers and a status code. Nothing mysterious survives your first look at it. What is not obvious is everything around it: what happens on a 429, what a timeout costs you, and why retrying immediately makes an overloaded service worse.
Getting output a program can use. A model returns prose by default and your code cannot consume prose. Constraining a model to return a shape you specified, and then validating that it actually did, is the line between an AI demo and an AI feature.
Giving it your own data. Models do not know your handbook, your product or your contracts, and asked about them they will produce something fluent and wrong. Retrieval (finding the relevant passages and passing them in) is the standard answer, and most of the difficulty is in getting real files into clean text rather than in the clever part.
Giving it tools. A model cannot do anything; it can only ask you to. Handing it a list of functions it may request, running them yourself, and deciding when the loop stops is the whole of what gets called an "agent".
Knowing whether it works. This is the part that separates people who ship from people who demo. Twenty saved examples with agreed-good answers, run after every change, is the difference between improving a prompt and merely moving it.
Running it. Cost per token becomes cost per month, and the number that decides an architecture is the monthly one. Caching, routing cheap requests to cheap models, and a hard spending cap you enforce yourself, because your provider will bill for whatever happens, including a loop you did not intend.
What you can genuinely skip
Backpropagation. Gradient descent. Building a neural network from scratch. The bias–variance tradeoff. Choosing between TensorFlow and PyTorch. Training a convolutional network on a dataset of cats.
None of that is useless knowledge and all of it is somebody's job. It is not the first thing standing between you and a working product, and treating it as the first thing is why so many people never reach the second.
What you cannot skip, and probably wanted to
Here the ranked roadmaps and this page agree, and it is the boring half:
- The terminal, a project folder and a virtual environment. Every tool in this field is documented as a command first.
- Git. Not for the version control theory, because the artefact you show an employer is a repository, and because you will need to get back to the version that worked.
- Enough Python to read code you did not write. Including code a model wrote for you, which is the specific skill nobody teaches and everybody now needs.
- How a web application is put together. Client and server, status codes, a database, who is allowed to see what. An AI feature with no application around it is a script on your laptop.
How long
Third-party estimates put it at three to six months for someone who already writes software, against the twelve months the roadmaps quote for the machine learning path. That is not our measurement and you should treat it as what it is: other people's estimate of other people's progress.
What we can say precisely is what is inside this course, because it is counted rather than claimed: 17 modules, 98 lessons, about 34 hours of lesson time, and 17 projects that are not included in that figure, because a project takes as long as it takes, and quietly folding a guess into a headline number is how course marketing loses its credibility.
Where to start
If you want the shape of the field before committing to anything, the knowledge map is the whole of it: 105 ideas, each defined in a sentence, free and with nothing to sign up for. If you want to feel the part that surprises people most, the cost game is one real decision with the arithmetic switched on.
And if you want the honest version of what goes wrong afterwards, the case library is seven real failures from this product's own history, including the one where the tests were green and the page was leaking answers.
Keep reading
2026-10-06
Resources worth following as an AI engineer: what to read, and when
A new post, model or tool appears in this field every day, and trying to follow all of it is the fastest way to learn none of it. A handful of resources that genuinely help, and the stage of learning at which each one is worth reading.
2026-10-05
Being an engineer in the age of AI: code got cheap, structure didn't
Writing code has never been this fast. But code produced quickly amplifies whatever structure sits underneath it. Why engineering matters more today, not less, and where to go deeper.
2026-10-02
Shipping an AI application: spending caps, caching, monitoring and model changes
In an ordinary web app every request costs roughly the same. In an app with a language model inside, it doesn't. Capping cost when you ship, using caching safely, watching the right things, and being ready when the provider retires a model.
2026-09-30
An AI engineer portfolio: what a project that gets you hired looks like
A chatbot demo impresses nobody anymore. Six signs that make an AI project credible, five project ideas that each show a different skill, and a README someone can read in two minutes.
2026-09-27
Prompt injection and abuse: why the server has to be the single source of truth in an AI app
An application with a language model inside carries every security problem of an ordinary web app and adds new ones. Why prompt injection can't be fully prevented, how to limit the damage, protecting the endpoint, and why the model's output can't be trusted.
2026-09-23
Building your first test set for an LLM application: a guide to evaluation
You changed the prompt and the answers look better. Do they? Building a first test set, taking a baseline, seeing what the average hides, the limits of one model grading another, and watching the system once it's live.
2026-09-19
When should you fine-tune, and when is it a waste of time?
Training a model on your own data is an attractive idea. Most of the time it's the wrong tool. What fine-tuning teaches and what it doesn't, how it compares with prompting and RAG, data quality, leakage, LoRA, and licences on open models.
2026-09-14
7 questions to ask before you pick an AI engineering course
Seven questions worth asking before you spend money and months on an AI engineering course. A short answer to each, and the concrete sign you can check in the syllabus before you buy.
2026-09-09
AI with image and audio input: the costs and failures your tests don't show
Handing a model a photo or a recording isn't the same as sending text. Request size, unreadable images, sentences invented in silence, generation that takes seconds, and an image paid for again on every turn.
2026-09-04
When don't you need an agent? Building and stopping a tool-using system safely
"Agent" is today's most requested and most easily misbuilt thing. The difference between a fixed workflow and an agent, why tool descriptions are critical, how to stop the loop, and how to protect irreversible actions.
2026-08-31
Why does RAG give wrong answers? Most failures are in retrieval, not the model
When a system that answers from your documents says something wrong, the model is the first suspect. Most of the time the culprit is the chunk it was given. Finding where the failure is, containing invention, citing sources and measuring properly.
2026-08-26
How to become an AI engineer: a roadmap that builds products, not models
Most roadmaps in the search results describe a different job. What the AI engineers being hired today actually know, the order to learn it in, and what makes each stage "done".
2026-08-21
When do you actually need a vector database? A practical guide to embeddings
The first step people take after deciding to build semantic search is usually picking a vector database. Most of the time it's an early step. What an embedding is, what a similarity score doesn't tell you, and the real reasons to move to a database.
2026-08-17
Managing prompts like code: versions, templates, schemas and tests
A prompt that works in a chat window quietly breaks inside an application. Keeping prompts in the repository, separating user input from instructions, validating the answer against a schema, and shipping a change only after measuring it.
2026-08-12
Why LLM APIs break under real traffic: rate limits, retries and timeouts
Three errors you never saw in development arrive together in the first busy hour. Telling 429 from 5xx, retrying properly, setting timeouts, and keeping the product up when the provider goes down.
2026-08-07
Do you need maths to become an AI engineer?
The honest answers to the six questions that stop people before they start: maths, degrees, machine learning, Python, hardware and money. Short answers first, reasons after.