AI engineer roadmap 2027

Why another roadmap

You have probably seen roadmaps with 200 boxes connected by arrows. They are useful as a map of the field, but they create a problem, because when you see 200 topics you assume you need to finish them before you are allowed to build, and most people stop somewhere in the middle without ever deploying anything.

So this roadmap is organised differently. Every stage has a short list of topics, a build that uses those topics, and a way to check that you are done. You don't move to the next stage because you finished reading, you move because your build works, it is on GitHub, and you can explain what broke and how you fixed it.

I also don't expect you to follow it in a straight line. If your problem needs retrieval in week 2, open the retrieval pages in week 2. The order below is the order in which the components usually depend on each other, and it is a good default when you don't have a problem of your own yet.

How to read each stage

Each stage below has four parts.

• What you learn: the topics, with links to the pages that explain them.
• What you build: one project that forces you to use those topics together.
• How you know you're done: a check you can run on your own work.
• Common mistake: the thing I see most often at that stage.

The time for each stage is an estimate for someone giving 1 to 2 hours a day who already knows basic programming. If you are starting from zero, add time to the first two stages, and if you already work as a backend developer, you will move through them much faster.

Stage 0: builder foundations

AI engineering is software engineering with models inside it. Whatever you build, there will be APIs, a database connection, a backend, often a frontend, and a deployment, so the software part is never optional.

What you learn:

• Python for AI engineers: variables, data types, functions, classes, error handling, virtual environments and packages.
• Linux terminal and Git and GitHub: you will use both every day.
• Working with APIs: HTTP requests, JSON, API keys and rate limits.
• Data formats and basic SQL, because most company data lives in relational databases.

Why Python and not another language? There are three reasons. Python has a huge community, so when you are stuck there is almost always an answer out there. It is easy to read, so even if you have never seen a Python program, you can usually guess what it does from the words in it. And it is a high-level language, which means it follows abstraction, showing you only what is essential, just like an ATM shows you the screen and the cash slot and hides how your balance is stored and checked. Most AI libraries and model APIs ship Python first, so it is also where the examples and SDKs are.

What you build: a small command line tool that calls a public API, saves the result to a file, and runs inside its own virtual environment, pushed to GitHub with a README.

How you know you're done: someone else can clone your repo, follow the README and run it without asking you anything.

Common mistake: skipping Python because a coding assistant can write it. Tools like Claude Code, Cursor and Gemini can write a lot of code for you, and I use them every day, but they still have real limitations, and if you don't understand the code they produce, it becomes very hard to build anything meaningful with it. The way to use them well is to understand the design of your solution, divide it into small parts, and give those parts to the tool, which then does the job of a junior developer for you.

Time: 2 to 4 weeks (estimate).

Stage 1: how LLMs work

Before you build with an LLM, you need a working picture of what happens between the text you send and the text you get back. You don't need to train a model at this stage, but you do need to know why a model forgets things in a long conversation, why the same prompt gives different answers, and why your bill depends on tokens.

What you learn:

• Tokens and tokenization: how text becomes numbers, and why token count drives cost and limits.
• Embeddings: how meaning becomes a vector, and why similar meanings end up close to each other.
• The transformer and attention, at the level of intuition: what attention does, not every equation.
• Context windows: how much the model can see at once, and why fitting into the window doesn't mean the model will use every detail correctly.
• Sampling and temperature: why output changes between runs.

What you build: a script that sends a request to an LLM API and logs the input tokens, output tokens and cost of every call to a file, which we call a token tracker. Then a simple tokenizer from scratch that splits text, builds a vocabulary and converts text to IDs and back.

How you know you're done: you can explain, with your own logs, why one request cost more than another.

Common mistake: treating the model as a database that remembers everything you said. A model only sees what is inside its context window for that request.

Time: 2 to 3 weeks (estimate).

Stage 2: prompts, context and structured output

Most failures in early AI apps are not model failures. They come from vague instructions, missing context or outputs that the rest of your code can't parse.

What you learn:

• System prompts and few-shot examples.
• Structured output with Pydantic, so the model returns JSON your code can validate.
• Context engineering: deciding what goes into the context window and what stays out.
• Prompt testing and versioning.

What you build: an extractor that reads unstructured text (emails, invoices or job posts) and returns validated JSON, with a set of 20 or more test inputs, including bad ones, that you run every time you change the prompt.

How you know you're done: you change the prompt, run your tests, and you can see exactly which cases got better and which got worse.

Common mistake: judging a prompt by trying it on two examples in a chat window.

Time: 1 to 2 weeks (estimate).

Stage 3: retrieval and RAG

Retrieval-augmented generation (RAG) is how you give a model information it was never trained on, like your company's documents, without retraining it. You find the relevant pieces of text first, then you put them into the prompt. It is the most common pattern in enterprise AI work, and it is where most developers first meet their own messy data.

What you learn:

• Document parsing and chunking.
• Vector databases and what happens inside them, including cosine similarity.
• Hybrid search and reranking.
• RAG evaluation and failure modes.

What you build: first, a vector store from scratch in plain Python, with your own dot product, magnitude and cosine similarity functions, so you see what a vector database does. Then a question answering system over a real set of documents using a proper vector database, with citations to the source chunk.

How you know you're done: you have a list of questions with known answers, you can measure how often the right chunk is retrieved, and you can show one case where retrieval failed and what you changed.

Common mistake: blaming the model for wrong answers when the right chunk was never retrieved.

Time: 3 to 4 weeks (estimate).

Stage 4: agents and tool use

An LLM answers you. An agent performs a task for you, by deciding which tools to call, calling them, looking at the result and deciding what to do next. That makes agents more flexible than automation scripts, because a script only handles the exact cases you coded, but it also makes them more expensive, slower and harder to test.

So the first question at this stage is always whether you need an agent at all. If a Python script or a normal workflow can do the job, use the script, because it needs no API calls, no token tracking and no LLM in the loop, and solving a problem with less software and less maintenance is also good engineering.

What you learn:

• Tool calling and tool design.
• Workflows vs agents, and planning patterns like ReAct (reason, then act, then observe).
• Agent memory and state and recovery.
• Model Context Protocol (MCP), the open standard Anthropic introduced in November 2024 for connecting models to tools and data, and agent to agent protocols like A2A, which Google announced in April 2025.
• Human in the loop and cost control.

What you build: a single agent for one very specific task, with 2 to 4 tools, a step limit, logging of every tool call, and a clear behaviour when a tool fails.

How you know you're done: you can show the trace of a run where a tool failed and the agent handled it the way you designed.

Common mistake: building a multi-agent system before a single agent works reliably.

Time: 3 to 4 weeks (estimate).

Stage 5: evaluation, deployment and LLMOps

This is the stage most learners skip, and it is the stage companies care about the most. A project on your laptop shows that you learned something, while a deployed project with an API endpoint shows that you can ship, and production experience is what recruiters ask about first for AI roles.

What you learn:

• Evals and reliability: offline test sets, online checks, LLM-as-judge and its limits.
• Serving with FastAPI and packaging with Docker.
• Secrets management and cloud basics.
• LLMOps: tracing, monitoring, latency and cost.

What you build: take your RAG system or your agent from the earlier stages, put it behind an API, deploy it, add tracing, and run your eval set against the deployed version.

How you know you're done: you can share a live endpoint, and you can show what each request costs and how long it takes.

Common mistake: deploying once and never checking it again.

Time: 2 to 3 weeks (estimate).

Stage 6: model adaptation and local models

Most AI engineering work in 2026 adapts models that someone else trained, through prompts, retrieval and tools. Fine-tuning is the next step when those are not enough, for example when you need a consistent output style, a smaller and cheaper model for one narrow task, or a model that runs inside your own infrastructure.

What you learn:

• When to fine-tune and when not to.
• Building a fine-tuning dataset.
• Parameter-efficient fine-tuning like LoRA.
• Evaluating a fine-tuned model against the base model.
• Running models locally, so your data stays on your own machine, and the basics of quantization.

What you build: fine-tune a small open model on one narrow task and compare it with the base model plus a good prompt on the same test set.

How you know you're done: you have numbers that show whether fine-tuning was worth it, and it is fine if the answer is no.

Common mistake: fine-tuning to add knowledge, when retrieval would do that job better and cheaper.

Time: 2 to 3 weeks (estimate).

Stage 7: AI system design

Once you can build the components, the next level is designing how they fit together for real users, real load and real budgets. This is where an AI engineer becomes someone who can lead a build, because coding assistants can write a component for you, but they can't decide the architecture of the whole system for your constraints.

What you learn:

• The LLM inference pipeline: everything that happens between a user request and a response.
• Architecture patterns and non-functional requirements like latency, availability and privacy.
• Capacity and cost modelling.
• Security and governance: prompt injection, data access and compliance.

What you build: write a design document for one of your earlier projects as if 10000 users will use it tomorrow, then change the parts of the system that the document shows will break.

How you know you're done: you can explain your design out loud, including what you would change at 10x the load and what you chose not to build.

Time: ongoing.

What runs alongside every stage

Some things don't belong to one stage, because you need a little of them every week.

• AI data structures and algorithms: tensors, vectors, the KV cache, nearest neighbour search. These are the data structures inside the systems you build, and interviewers ask about them.
• Math, when a component needs it. The math page explains exactly how much and when.
• One research paper a week. Start with Attention Is All You Need, the original RAG paper and ReAct, and read them after you have built the component they describe, because the paper makes much more sense then.
• Interview questions for whatever you built that day, written in your own words.
• Building in public: a GitHub commit for each build and a short post about what you built and what broke.

What changed in this roadmap for 2027

Older AI roadmaps, including the data science roadmap I made in 2021, started with statistics, then machine learning algorithms, then deep learning, and only at the end touched deployment. That order made sense when most of the work was training your own models.

Three things have changed since then. First, most AI engineering work now adapts foundation models through prompts, retrieval, tools and fine-tuning instead of training models from scratch, so evaluation and inference cost became bigger problems than model training, which is also how Chip Huyen describes the shift in her book AI Engineering. Second, coding assistants now do a large part of what a junior developer used to do, so the value moved toward understanding architecture, components and trade-offs. Third, agents and tool protocols like MCP moved from experiments into real products, so tool design, failure handling and cost control are now part of the core roadmap instead of advanced topics.

Machine learning and deep learning are still in this roadmap, inside the LLM fundamentals and model adaptation stages, because each generation of AI solves certain problems better than the next one. A good flow when you get a problem is to check whether it can be solved without AI, then with classical machine learning, then with deep learning, and only then with generative AI. Using an LLM for everything is not a strategy.

My expectation for 2027 is that the skills that matter most will be evaluation, system design and the ability to explain what your system does when it fails. This is my prediction, not a statistic, and if coding agents become reliable enough to own production systems end to end without review, the weight of this roadmap will move even further toward design and evaluation.

How long it takes

This depends on three things: how much programming you know, how many hours you give, and whether you build or only watch.

As an estimate, a developer who already writes code at work and gives 10 to 15 hours a week can reach a deployed agent with evals in about 4 to 6 months. Someone starting from zero should plan for longer, and should add more theory between the first builds, because a complete beginner doesn't yet have the vocabulary to research a problem on their own.

How you spread the hours matters more than the total. 2 hours every day works much better than 10 hours on Saturday, because you meet the same problem again before you forget it, and the builders in my cohorts who gave around 10 hours a week, spread across the week, understood the material much better than those who tried to finish everything in one sitting.

What not to do

• Don't finish a full math course before you start. Learn the math behind each component when you build it.
• Don't collect certificates instead of projects. A certificate can help you get an interview, but a deployed project you can explain is what gets you through it.
• Don't learn every framework. Learn one well, and learn what it does underneath, so you can switch when you need to.
• Don't use an LLM where a script works.
• Don't ship code you can't explain. If someone asks in an interview what you built with a coding assistant, you should be able to walk them through every part of it.

From the floor

When I started the 75 day AI engineering challenge, I used a simple framework: learn, build, deploy, market. Most people learn and stop. Some build, but the project stays on their laptop. When you deploy it, you get an API endpoint that you can share with recruiters and clients, and when you market it, through a post or a video about what you built, you start building distribution, which is what brings opportunities to you later.

The AI Engineer HQ cohort started in 2019 as a machine learning engineering program. Every time the field moved, we changed the modules, and the biggest change was moving from learning algorithms one by one to building one system per module, with each module ending in a build, a deployment and a post about it. In one version, the split was 80% engineering and 20% business, because builders also need to explain use cases and return on investment to the people who pay for the system.

Related

• How to learn AI engineering by building
• Your first 30 days in AI engineering
• How much math do you need for AI engineering?
• What does an AI engineer actually do in 2027?

Sources

• Model Context Protocol announcement, Anthropic (November 2024)
• Announcing the Agent2Agent Protocol, Google Developers Blog (April 2025)
• AI Engineering by Chip Huyen, O'Reilly
• The AI engineering stack, Chip Huyen in The Pragmatic Engineer