Build products on top of language models that survive real users.
Read the guide: AI engineer roadmap: what to learn, and in what order
Direct Answer: Build products on top of language models that survive real users — grounded answers, structured output, tools, evals, and a bill you can predict.
Tokens, context windows, sampling, and the shape of a real API call.
Instructions that hold up under real input, and output your code can trust.
Giving the model facts it was never trained on, and knowing when retrieval is what failed.
Letting the model act, keeping the loop bounded, and the three ways these systems break.
Measuring a system that never returns the same answer twice, then running it affordably.
Getting tokens to the user quickly, serving many at once, and staying useful when the provider is not.
Changing the model itself once prompting has plateaued, and handling input that was never text.
Grounding answers in sources that change while the user is typing, and that not every user is allowed to see.
Carrying useful state across turns and sessions without letting the context window or the bill grow without bound.
Splitting work across several models and dozens of tools, and paying the coordination cost deliberately rather than by accident.
Attacking your own system the way a motivated user will, then building defences that still hold after contact.
Keeping quality rising over years while models deprecate, inputs shift, and every fix risks breaking something that already worked.
Topic checks
Each one opens the next topic
Chapter quizzes
Each one opens the next chapter
50-question final
50 of 100 marks to pass
Certificate
Issued instantly, verifiable
One attempt, 60 minutes. If you don't pass, you can retake once after 30 days.
A sensible AI engineer roadmap starts with ordinary programming, then goes in this order: how a model call actually works, structured output, retrieval over your own documents, tools and agents, and finally evaluation, cost and safety. You do not need to train a model from scratch to do this job. You need to build software on top of models that other people trained, and make it hold up when real users arrive with messy input.
That distinction is the whole point of this guide. Most roadmaps you will find online are machine learning roadmaps with a new title: linear algebra, then neural networks, then transformers, then maybe an API call in month nine. That path suits research. It is the wrong path if you want to ship a support bot or a document search tool next year. Our free AI Engineering with LLMs course follows the second path, and the roadmap below is built the same way.
An AI engineer writes the code around a language model. Concretely, that looks like:
Notice what is missing: calculus, training runs, GPU clusters.
| AI engineer | ML engineer | |
|---|---|---|
| Main material | prompts, APIs, retrieval, tools, evals | datasets, training, model architecture |
| Typical first task | wire a model into an existing product | improve a model's accuracy on a task |
| Maths needed day to day | light | substantial |
| Starting point | a working backend developer | a strong Python and statistics base |
If the right column is what you want, start with AI and ML Essentials instead. If the left column is what you want, keep reading.
This is the step people skip. Nearly every hard bug in an LLM feature is a normal software bug wearing a costume: a request with no timeout, a retry loop that hammers a provider that is already down, user input pasted straight into a string, a refund issued twice because a request was replayed.
Before the roadmap proper, you should be able to write a small API in Python or JavaScript, call another API from it, read JSON, handle an error, and put it somewhere a friend can reach. The AI Engineering course is marked Intermediate for this reason, and its code examples are almost all in JavaScript, with a little Python. If you are not there yet, Python Development is the gentler start, and our post on which programming language to learn first in Pakistan will help you choose without switching four times.
Learn what a token is, why the context window is a single budget shared by input and output, and why every request resends the whole conversation. Learn what temperature does, and why temperature 0 still does not give you true determinism.
A prompt that works on three examples you tried is not a prompt. Learn to keep instructions and user data in separate places, change one thing at a time, and use few-shot examples rather than paragraphs of description. Above all, learn structured output: give the model a schema, validate the result anyway, and retry once with the validation error. Truncated or malformed JSON is one of the first production failures most teams meet.
If you want to go deeper on this layer alone, Prompt Engineering is a shorter companion course.
Retrieval augmented generation is how a model answers from facts it was never trained on. Learn embeddings and cosine similarity, how to chunk and clean documents before indexing, and how to order what you pack into the context. When an answer is wrong, check whether retrieval found the right passage before blaming the model; a retrieval miss often looks exactly like a hallucination.
Function calling lets the model choose an action, but your code executes it, and the arguments the model produces are untrusted user input. Learn the agent loop, and just as importantly, when not to build one. Learn why prompt injection has no fix that lives inside the prompt, and why code execution needs a real sandbox, never your own server process.
This is where hobby projects and production systems part ways. Build an eval set from real traffic, run it like a test suite, and accept that offline evals are not enough on their own. Learn how caching cuts cost, and choose a model with your own bake-off rather than a public leaderboard.
Once the core is solid, the remaining topics are about running these systems for months: streaming, queues and fallbacks, fine-tuning and distillation when prompting has plateaued, permission-aware retrieval, conversation memory, multi-agent orchestration, red-teaming, and drift.
The AI Engineering with LLMs course has 12 chapters of 4 lessons each, 48 lessons in total, with each lesson marked at 12 to 15 minutes of reading. It is text and code, not video.
| # | Chapter | What you come away able to do |
|---|---|---|
| 1 | How Models Actually Work | reason about tokens, sampling, API calls and knowledge cutoffs |
| 2 | Prompting and Structured Output | write prompts that survive real input and get JSON that parses |
| 3 | Embeddings and Retrieval-Augmented Generation | build and debug a RAG pipeline over your own documents |
| 4 | Tools, Agents, and Failure Modes | add function calling, bound an agent loop, handle injection and PII |
| 5 | Evaluation, Cost, and Shipping | evaluate non-deterministic output, cache, and pick a model by bake-off |
| 6 | Streaming, Throughput, and Reliability | stream safely, queue work, add fallbacks and idempotency |
| 7 | Fine-Tuning, Distillation, and Multimodal | know when to fine-tune, build cascades, handle documents and voice |
| 8 | Databases, Live APIs, and Permissioned Retrieval | run text to SQL on a read-only role, respect who may see what |
| 9 | Memory, Compaction, and the Long Conversation | summarise long chats and store memory users can delete |
| 10 | Orchestration, Sub-Agents, and Tool Ecosystems | split work across agents and choose from large tool registries |
| 11 | Red-Teaming, Guardrails, and Blast Radius | attack your own feature and limit what a compromised agent can do |
| 12 | Drift, Regression, and the Improvement Loop | monitor live quality and survive a model deprecation |
Every chapter is built around a specific production failure you learn to diagnose, such as a prompt cache that never hits or an eval suite that quietly rewards longer answers.
The course is listed at eight weeks. That assumes you already code and can give it steady time most days. The stages stick when you build one small project per stage: a script that returns validated JSON, then a question answering tool over your own PDFs, then the same tool with a function call and a small eval set.
If you are starting from zero programming, add the time it takes to get comfortable with a backend first.
Each lesson ends with a short quiz, which unlocks after 90 seconds on the lesson, and you need 70 percent to pass it. The course ends with a final exam of 50 questions in 60 minutes, and you pass with 50 out of 100 marks. You get one timed attempt; if it does not go your way, a single retake opens 30 days later. Pass, and the certificate is issued with a verification code anyone can check.
Be clear about what that certificate says: that you passed our exam. It will not get you hired on its own. A small deployed project with an eval set will do far more for you in an interview. Our post on whether free online certificates are worth anything goes into this honestly.
It suits backend and full stack developers who want to add AI features to real products, final year students who already build things and want a focused next step, and freelancers whose clients keep asking for a chatbot that answers from their own documents. If you mainly want to use AI tools at work rather than build with them, this is the wrong course, and AI Automation and Agents or a no-code route will serve you better.
Ready to start? AI Engineering with LLMs begins with tokens and the shape of a real API call, and it is free from the first lesson to the certificate.
05 questions
No. You need to be able to write and deploy a small backend in Python or JavaScript.
Much less than an ML engineer. Knowing roughly what an embedding is and what cosine similarity measures is enough to start. Calculus and training theory matter if you later move into fine-tuning research or model training.
Either works for the job itself. The course examples are mostly JavaScript, but the ideas carry straight over to Python, so pick the one you already ship code in.
Yes. All 48 lessons, the quizzes, the final exam and the certificate are free. You will need your own access to a model API to run the examples, and providers set their own terms and pricing for that.
A question answering tool over a small set of real documents, with retrieval, a structured output step and a short eval set you can run in one command. Put it online and be ready to explain one failure you found and fixed.
