An AI Engineering Roadmap That Puts Things in the Right Order

The short answer: an AI engineering roadmap is about order, not topics

If you have looked at more than one AI engineering roadmap, you have noticed they are the same twenty topics rearranged: tokens, prompting, embeddings, RAG, vector databases, evals, tool calling, MCP, agents, fine tuning, guardrails. The list is not the hard part. The order is. Learn those topics in the wrong sequence and every one of them feels harder than it is, because you are missing the thing underneath it.

Here is the order I would give you if you asked me in person, with something specific to build at each stage. I am a Lead Full Stack Engineer and I build LLM features into real products, so this is written from the side of shipping things, not from the side of reading about them. That distinction matters more in this field than in most: the gap between people who can discuss a retrieval system and people who have made one work on messy documents is enormous, and employers can tell the difference in about five minutes.

The whole roadmap fits in roughly three to four months of consistent evenings if you can already build a basic web or backend app. It is the same path as the Sefism AI engineering roadmap, which has a Python track and a TypeScript track.

What an AI engineer actually does in 2026

Before the stages, it helps to be clear about the job, because a lot of students are learning for a different job than the one they want.

An AI engineer builds products on top of models someone else trained. You call a model through an API, feed it the right context, connect it to tools and data, measure whether it works, and run it in production at a known cost. It is software engineering with a probabilistic component in the middle.

A machine learning engineer trains, tunes and serves models themselves. That job needs statistics, linear algebra, data pipelines and a lot of experimentation. If that is what excites you, the machine learning roadmap is the right path, and it is a longer one.

If you are unsure which side you belong on, read my answer on whether to learn AI, ML or software engineering first. And if maths worries you, AI engineering is the more forgiving of the two: intuition matters far more than derivations.

Prerequisites before you start this roadmap

• One programming language you are comfortable in. Python or TypeScript. Not "watched a course", but "can build a small API without a tutorial open".
• HTTP and JSON. Every model is an HTTP endpoint that takes JSON and returns JSON.
• A database. Basic SQL, because your retrieval layer will probably live next to one.
• Git. You will be iterating on prompts and you want them versioned like code.

If those are shaky, fix them first. The AI part sits on top of ordinary engineering, and weak foundations show up fast.

The AI engineering roadmap in seven stages

Here is the whole path at a glance, then each stage in detail.

Stage 1: how LLMs work, tokens and the context window

A language model predicts the next token. Everything else it appears to do is built on that. A token is a chunk of text, and OpenAI's own rule of thumb is that one token is roughly four characters of English, so 100 tokens is about 75 words.

Tokens matter for three practical reasons: you are billed in them, context limits are measured in them, and they explain strange behaviour like a model miscounting letters in a word it never saw as letters.

The second idea here is the context window as a budget. Bigger windows do not mean you should fill them. The well known Lost in the Middle paper showed that models use information at the start and end of a long context better than information buried in the middle. Everything you add competes for attention.

Build: a small script that takes a prompt and a document, counts tokens, and estimates cost at a model's published price. Boring, and it will change how you think about every design decision after it.

Stage 2: prompting and model APIs, without a framework

Now call a model directly. Learn the chat messages format, system prompts, how to state the output format you want, and how two or three examples (few shot prompting) change the result more than clever wording does. Keep prompts in version control from day one.

Build: a command line tool that takes a file and does something useful with it through a model API. Summarise a long document, extract structured fields from a messy text file, turn meeting notes into action items. No framework, just HTTP calls.

Why this first: every framework you meet later is hiding these calls. When the abstraction misbehaves, knowing what is underneath is how you debug it. Anthropic's free prompt engineering documentation is a good reference for this stage.

Stage 3: RAG, giving the model your own data

The model knows nothing about your documents, your company or anything that happened after training. Retrieval augmented generation fixes that, and it is where most real AI applications live.

Learn embeddings, which turn text into numbers positioned by meaning, so "how do I cancel" lands near "ending your subscription". Then chunking, which matters far more than people expect: splitting a document badly is one of the most common causes of bad answers. Then semantic search, then putting what you retrieved into the prompt with instructions to cite it and to say so when nothing relevant came back.

You do not need an exotic database for this. pgvector inside Postgres is plenty for learning and for many production systems. And for small collections you may not need retrieval at all: Anthropic notes in its contextual retrieval write-up that a knowledge base under about 200,000 tokens can often just go straight into the prompt.

Build: a question answering tool over a folder of your own documents: your university notes, a codebase, a set of PDFs.

The lesson you will learn the hard way: when an answer is wrong, print the chunks that were actually retrieved before you touch the prompt. It is nearly always retrieval. I go deeper into this choice in RAG, fine tuning or a better prompt.

Stage 4: evals, measure before you add anything else

This is the stage most people skip, and it is the one that decides whether you improve your system or just keep changing it.

An eval is a set of inputs, a definition of a good output, and a score. Twenty to fifty real questions with known good answers, in a spreadsheet, is a real eval. Start by reading actual outputs and writing down how they fail; Hamel Husain and Shreya Shankar call this error analysis, "the most important activity in evals". Then add simple code checks (did it cite a source, is the JSON valid) and, only after that, an LLM acting as a judge, checked against your own labels so you know it agrees with you.

Build: a script that runs your stage 3 tool against your test set and prints a score. Then change your chunk size and run it again.

Why here and not later: everything after this point is a change you need to be able to measure. Without a score, "the new model feels better" is the best you will ever be able to say. AI Evals: Everything You Need to Know is the best free resource I know on this.

Stage 5: tool calling, structured output and MCP

Tool calling lets the model act. You describe functions, the model asks to call one, your code runs it, and the result goes back into the conversation.

Then structured output, so what comes back is parseable rather than hopefully parseable: you define a schema and the model returns that shape. Then the Model Context Protocol, the open standard for exposing tools and data so you write an integration once and any compatible client can use it. MCP started at Anthropic and in December 2025 moved to the Linux Foundation's Agentic AI Foundation, which is a good sign it is here to stay.

Build: something that calls two or three real APIs and combines the results. An assistant that queries a database and a weather or calendar API and drafts a summary.

The lesson: when the model calls your tool wrongly, read your own tool description as if you had never seen the code. It is usually vague. Anthropic's guide to writing effective tools for AI agents puts it well: describe the tool the way you would to a new hire.

Stage 6: agents and durable execution

Now agents, and now they will make sense, because you understand what they are looping over.

Learn the difference between a workflow (you wrote the steps) and an agent (the model decides the steps). Anthropic's Building Effective Agents is the clearest statement of this, and its core advice is worth taping to your monitor: start simple, measure, and add multi step agentic systems only when simpler solutions fall short. Then write an agent loop by hand, manage context across steps, set limits on steps, time and cost, and add checkpoints so a run can resume.

Build: an agent that completes a task needing at least five steps, survives a failure in the middle, and resumes rather than restarting.

The honest note: you will discover that most tasks you wanted an agent for would have been better as a fixed pipeline. That discovery is worth the four weeks. I cover the six shapes these systems take in six ways to structure work for an AI agent.

Stage 7: running AI systems in production

Tracing, so you can see which documents were retrieved, what the final prompt looked like and which tools ran. Input and output guardrails. Defence against prompt injection, which sits at the top of the OWASP Top 10 for LLM applications as LLM01. Prompt caching and model routing for cost. Fine tuning comes last, and only when you need consistent behaviour rather than new knowledge.

Build: deploy one of your earlier projects somewhere real, with tracing, a cost cap and a way to see what users actually asked.

Common mistakes on the AI engineering roadmap

These are the patterns I see most often when students and working developers show me what they have been learning.

• Starting with agents. Agents are the exciting part, so people start there, and then cannot debug anything because they do not understand the calls underneath.
• Skipping stage 4. Evals feel like paperwork. They are the difference between an engineer who can say "reranking improved accuracy from 72% to 85% on our test set" and one who says "it seems better".
• Framework hopping. Pick one framework, or none, and build. The concepts transfer. The frameworks will all look different next year.
• Training models from scratch. Fascinating, expensive, and unrelated to almost every AI engineering job.
• Fine tuning to teach facts. Fine tuning changes behaviour. If the goal is knowledge, the answer is retrieval.
• Reaching for multi agent systems. They are the most over used pattern in the field. Anthropic reported that its own multi agent research system used about fifteen times more tokens than a normal chat. Worth it for some problems, wasteful for most.

If the vocabulary in this list still feels slippery, the AI engineering words you keep hearing, explained properly is the companion to this post.

AI engineering projects that show you can do the job

A portfolio for this field is not a list of certificates. It is two or three projects where someone can see you made hard decisions.

If you are a student, any of these can grow into a strong final year project, especially if it solves a problem for real users.

Resources worth your time for each stage

Free and genuinely good:

• Stages 1 and 2: Generative AI for Beginners by Microsoft, a hands on course that starts from zero.
• Stage 3: RAG Techniques, an open source collection of retrieval patterns with runnable notebooks.
• Stage 4: AI Evals: Everything You Need to Know, the guide linked above.
• Stages 6 and 7: Building Effective Agents, then Anthropic's piece on effective context engineering once your system basically works.

If you would rather be taught than assemble it yourself, Grokking Modern AI Fundamentals is a solid guided course for the early stages, and Grokking the AI System Design Interview is a reasonable next step once you are thinking about how whole systems fit together. For one book that covers the field end to end, Chip Huyen's AI Engineering is the one I would pick.

Everything above, plus more, is in the AI section of the resource library.

A realistic AI engineering timeline

Three to four months of consistent evenings, at around 15 hours a week, gets a working developer to the point of building useful things. A student still learning to program should add a few months for the prerequisites first. That is honest, and it is also good news: the number of people who have shipped a working retrieval system with a real eval behind it is much smaller than the number who can talk about one.

If you are wondering whether you are already behind, you are probably not. I answered that directly in am I falling behind if I am not building AI projects. And if you are in Pakistan and want the local job market picture on top of this learning path, read how to become an AI engineer in Pakistan.

The stages people skip, and later regret skipping, are four and five. Measurement and tool design are unglamorous, and they are exactly what separates a demo from something people use.

Learn it on Sefism

• AI engineering roadmap (Python) and the TypeScript edition
• AI engineering cheat sheet, the one page version of every stage above
• Which AI topics are worth learning: agents, RAG, MCP, LLMs
• How to become an AI engineer in Pakistan
• AI resource library
• Grokking Modern AI Fundamentals for a guided start

FAQ

How long does it take to become an AI engineer?

If you can already build a web or backend app, about three to four months of consistent part time study gets you to building useful LLM features. From zero programming, plan for closer to a year, because the software engineering foundations come first.

Do I need machine learning or advanced maths for AI engineering?

Not much. AI engineers build on models that already exist, so you need intuition about how they behave, not the ability to derive gradients. Machine learning engineering, which trains models, needs far more maths.

What is the difference between an AI engineer and an ML engineer?

An AI engineer builds products on top of existing models using APIs, retrieval, tools and agents. An ML engineer trains, evaluates and serves the models themselves. The skills overlap but the day to day work is different.

Should I learn Python or TypeScript for AI engineering?

Either works. Python has the most tutorials and data tooling; TypeScript fits naturally if you already build web apps. Pick the one you know and the concepts transfer.

What should my first AI engineering project be?

A question answering tool over your own documents, with citations, that says "I could not find that" when retrieval comes back empty. Then add an eval set and show a before and after score.

Ask your own question

If your situation is different from the ones above, the career questions library has honest answers to the questions students and engineers ask me most.

Want a learning roadmap built around you, written answers to your own questions and a place to discuss your FYP? Create your free Sefism account. Members can also book a one to one session when they want to talk it through.

Stay in touch

• LinkedIn: where I share roadmaps, career advice and honest takes on hiring. Follow, or message me.
• X (Twitter): short practical thoughts on engineering and careers.
• Instagram: quick tips and a more personal side.
• Sefism Discord: meet other students and engineers working through the same job market and share what is working.
• Sefism on YouTube: walkthroughs and talks.