An AI Engineering Roadmap That Puts Things in the Right Order

The order matters more than the list

Every AI engineering roadmap is the same twenty topics in a different arrangement, and the arrangement is the only part that matters. Learn them in the wrong order and each one feels harder than it is, because you are missing the thing underneath it.

This is the order that works, with what to actually build at each stage. Building is not optional here. This field has an unusually wide gap between people who have read about it and people who have shipped something.

Stage one: what the model is doing, about two weeks

Before any framework, understand tokens, context windows and why cost and limits are measured the way they are. Then prompting, properly: being specific, stating the output format, giving examples.

Build: a command line tool that takes a file and does something useful with it through a model API. Summarise a document, extract structured fields from a messy text file, convert one format to another. No framework, just HTTP calls.

Why this first: every abstraction you meet later is hiding these calls. Knowing what is underneath means you can debug the abstraction when it misbehaves.

Stage two: giving it your own data, about three weeks

The model knows nothing about your documents. Retrieval fixes that, and retrieval is where most real applications live.

Learn embeddings, meaning text turned into numbers positioned by meaning. Then chunking, which matters far more than people expect, because splitting a document badly is the single most common cause of bad answers. Then retrieval, then putting what you found into the prompt.

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

The lesson you will learn the hard way: when the answer is wrong, print the chunks that were actually retrieved before you touch the prompt. It is nearly always retrieval.

Stage three: measuring it, about one week

This is where most people skip ahead, and it is the stage that decides whether you improve or just keep changing things.

An eval is a set of inputs, a definition of a good output, and a score. Twenty examples in a spreadsheet is a real eval.

Build: a script that runs your stage two tool against twenty questions with known good answers and prints a score.

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.

Stage four: letting it act, about three weeks

Tool calling: you describe functions, the model requests them, your code runs them, results go back.

Then structured output, so what comes back is parseable rather than hopefully parseable. Then the Model Context Protocol, which is the standard way to expose tools so you write the integration once.

Build: something that calls two or three real APIs and combines the results. A tool that reads your calendar and your email and drafts a summary. An assistant over a database.

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.

Stage five: multi step work, about four weeks

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

Agent loops. The workflow patterns: routing, parallelisation, orchestrator and workers, reflection, planning. Memory and state across steps. And the durable execution problem, meaning what happens when step six of nine fails.

Build: an agent that completes a task requiring 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.

Stage six: making it production shaped, ongoing

Observability, so you can trace what happened. Guardrails on input and output. Caching and model routing for cost. Fine tuning, last, and only when you need consistent behaviour rather than knowledge.

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

What to skip, at least at first

Training a model from scratch. Fascinating, expensive, and unrelated to almost every job in this field.

Framework comparison articles. Pick one, build with it, move on. The concepts transfer and the frameworks will all have changed by next year.

Multi agent architectures. They are the most over reached for tool in the field. Learn them at stage five, use them rarely.

Resources worth your time

Free and genuinely good:

• Generative AI for Beginners by Microsoft, for stage one.
• Deep Dive into LLMs by Andrej Karpathy, when you want to know what is underneath.
• Hugging Face AI Agents Course for stage five, with a graded project at the end.
• Effective Context Engineering by Anthropic, once your system basically works.

Structured, if you would rather be taught than assemble it yourself: Design Gurus covers modern AI fundamentals as a guided course, and their AI system design material is a reasonable next step once the fundamentals are in place.

Everything above, plus more, is collected in our AI resource library.

A realistic timeline

Three months of consistent evenings gets you to the point of building useful things. That is genuinely most of the value in this field right now, because the number of people who have shipped a working retrieval system is much smaller than the number who can discuss one.

The stages that people skip, and then regret skipping, are three and four. Measurement and tool design are unglamorous and they are what separates a demo from something people use.