How to become an AI engineer: a roadmap that builds products, not models
The Ship AI Engineer team · Published 2026-08-26
Search how to become an AI engineer and you get the same list, over and over: linear algebra and statistics first, then classical machine learning, then neural networks, then a deep learning framework, then a specialisation. A year, sometimes more.
That list isn't wrong. It's the list for a different job: the machine learning engineer, the person who trains models. Most roles opened as "AI engineer" today want someone who builds products on top of a model somebody else trained. We covered the difference between the two in a separate post. This one answers the question after it: what do you learn, in what order, and how do you know you've finished a stage?
What does an AI engineer actually do?
They make an existing language model part of a product, and they own whether that product works for real users: correctly, quickly and at a sensible cost.
Very little of the day touches the model itself. The work is in the software around it: deciding what context goes to the model (the user's documents, earlier messages, a tool's result), controlling the shape of the answer, keeping the token budget and latency in check, keeping the system up when the provider errors, and measuring how often the answer is wrong. It helps to think of the model like a database: powerful, and the component that sinks the product if you don't know when it will return the wrong thing.
Where should you start?
With an API call. Not with maths.
Once you can run Python, tell whether your terminal is in the right folder and save a change with Git, the first real step is to send a request to a language model from code and print the answer. The shape of that call (a list of messages goes in, text and usage information come out) is the core of everything that follows. If you're wondering how much maths you need, the short answer is arithmetic; the reasoning is in another post.
In what order should you learn it?
In seven stages, each built on the one before. A stage closes when you meet its "done" bar, not when you've read about it.
- A working environment. Python, the terminal, virtual environments, Git and GitHub. People who skip past this lose the most time here later: a command run in another folder, a package installed into the wrong environment, an API key that made it into the repository. Done when: you can bring your project up from scratch on a clean machine using only the commands in its README.
- Model APIs. The shape of a request and a response, tokens, the context window, rate limits and transient errors. This is where you learn the model doesn't "remember" the conversation and the whole history is resent on every request, which is also why long chats get expensive and eventually forget their beginning. Done when: you have a call with retries and a timeout that logs the token usage of every request.
- Prompts managed like code. Keeping prompts in a versioned file in the repository rather than a chat window; separating user input from instructions; asking for output a program can read and validating it against a schema. "The model sometimes writes an explanation instead of JSON" gets solved here. Done when: your code catches a malformed answer and raises a meaningful error.
- Answering from your own data. Embeddings, vector search and RAG. Here you find out the difficulty isn't the search, it's the data: broken text out of a PDF, a table split down the middle, three versions of the same document. Most wrong answers come from retrieving the wrong chunk. Done when: the system says "I don't know" to a question the documents don't answer, and shows the source of every answer it does give.
- Agents and tool use. Letting the model call a function, handing the result back, and deciding yourself when the loop stops. The most important code here is the code that stops: a step limit, a cost limit and human approval before anything irreversible. Done when: your agent doesn't loop forever when a tool fails.
- Evaluation. A fixed set of questions, expected answers and a score. It's the only thing that can tell you whether a prompt change made the system better; without it every change is a guess. Done when: one command runs the set and produces a score you can compare with the previous version.
- Shipping. Authentication, a database, rate limits against abuse, secret management, deployment and monitoring. Leaving an endpoint that calls a language model open without limits hands your bill to strangers. Done when: the app has an address on the internet, a monitoring view and a spending cap per user.
If you want to see how these concepts connect on a single page, the knowledge map lays out a hundred and five of them with their definitions, no account needed.
How long does it take?
It depends on who is starting and what you count as done; there is no single honest number.
Someone who has built software skips the first stage, reaches the second in their first week and spends most of their time in stages four to seven. For someone who has never written code, the first stage alone can take weeks, and that's normal. To give one yardstick from our curriculum: reading and exercises across 17 modules and 98 lessons come to about 34 hours. On top of that sit 17 projects, which aren't in that figure, because how long a project takes is what varies most from person to person. The projects set the timeline, not the lessons.
Do you need a certificate?
No. In this field the document people look at is a working repository, not a certificate.
Someone assessing a candidate usually checks three things: does the project run with one command, has failure been thought about, and is there a measurement. A repository that shows those three says far more than a certificate they've never heard of. Writing honestly in the first paragraph of the README what the project does and what it doesn't is something most candidates skip, and it's the fastest way to earn trust.
What is the most common mistake?
Moving on to the next topic without finishing anything.
Watching videos feels like progress, because every day brings a new concept. But the day you actually build a RAG system, problems turn up that no video showed you: a search that returns a different chunk for the same question every time, a parser that's perfect on the test data and falls over on a real document, a bill you didn't expect. Most of the learning starts that day. Examples of how real projects break are on the failure cases page, and how one architecture decision changes the cost is in the cost game.
Who is this path not for?
People who want to train models, design new architectures or do research.
That goal really does go through maths, and the path above doesn't teach it. Both are worthwhile careers; they just aren't the same career. Knowing which one you want is the easiest way to spend your first month in the right place.
Sources
- Anthropic: Building effective agents: the provider's own take on when an agent is needed and when a simple workflow is enough. (added 2026-08)
- Lewis et al. (2020): Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks: the paper that introduced RAG. (added 2026-08)
- Anthropic: Create strong empirical evaluations: how to build an evaluation set. (added 2026-08)
- OWASP: Top 10 for LLM Applications: security risks specific to applications that call language models. (added 2026-08)
- The Twelve-Factor App: the basics of a deployable app, including keeping config and secrets out of the code. (added 2026-08)
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-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.
2026-08-07
An AI engineer is not a machine learning engineer
Search "how to become an AI engineer" and the first page teaches linear algebra, CNNs and training loops. That is a different job. Here is what the work actually is, and what you can skip.