Start here: how to use the AI Engineer HQ docs
These docs explain what you need to build AI systems that work in production, from your first LLM call to the design of a full inference pipeline. You don't read them from the first page to the last. You pick a problem you want to solve, open the pages that problem needs, build something, and come back when the next part of your build asks for more.
What these docs are
Most AI engineering content online is a list of topics, a tutorial for one tool, or a roadmap that tells you to learn twenty things before you build anything. I wanted one place where every topic I teach in my cohorts is written down properly, so you can jump to the part you need, understand why it exists, and see where it fits in a real system. So these docs are written from the lectures and live sessions I have taken with builders in AI Engineer HQ, Build30 and the 75 day challenge, and from the problems my team and I solve for clients at Dextar. When a topic needs something my sessions didn't cover, I have added it and linked the source, so you can check it yourself.
Think of it as a big book that you don't have to read in order. Each page answers one question or explains one component, and each page links to the pages before and after it in a build.
Who these docs are for
The docs are written for a working software developer who already knows programming and APIs, has started with RAG and agents through tutorials, and maybe has a chatbot running on their laptop, but gets stuck when their own data, real errors and deployment begin. If that is you, the main thing you are missing is not another course. It is the experience of taking one problem from a problem statement to something deployed, and being able to explain every decision you made along the way.
The docs also work for three other readers.
- If you are a student or a complete beginner, start with the Builder foundations section and the first 30 days page, and expect to read a little more theory before your first builds than an experienced developer would.
- If you are moving into AI from another field, like analytics, QA or a domain role, read the page on the different AI roles first, because your existing domain knowledge is the most valuable thing you bring.
- If you lead a team, a product or a company, the Leaders track skips the code and focuses on what to build, what it costs, how to check it works and who should own it.
How the docs are organised
The docs are grouped into sections that follow the order in which the parts of an AI system usually show up in a build.
| Section | What it covers |
|---|---|
| Start here | How to learn, what the role is, how much math you need, your first 30 days |
| Builder foundations | Python, terminal, Git and GitHub, APIs, data formats, Docker, cloud basics |
| LLM fundamentals | Tokens, embeddings, transformers, context windows, sampling |
| Prompt and context engineering | System prompts, structured output, context design, prompt testing |
| Retrieval and RAG | Parsing, chunking, vector databases, hybrid search, reranking, RAG evaluation |
| Agents and tool use | Tool calling, workflows vs agents, memory, MCP, multi-agent systems |
| Model adaptation | When to fine-tune, datasets, LoRA, evaluating a fine-tuned model |
| Evals and reliability | How to check an AI system works and keeps working |
| LLMOps | Deployment, monitoring, tracing, cost and latency |
| AI system design | Inference pipelines, architecture patterns, capacity and cost |
| AI data structures and algorithms | Tensors, KV cache, nearest neighbour search, the data structures inside models |
| Security and governance | Prompt injection, data access, compliance |
| Career and interviews | Portfolio, resume, system design interviews, freelancing |
| Leaders | AI strategy, build vs buy, team design |
You will also find comparison pages (for example, LlamaIndex vs LangChain), teardowns of real systems and a glossary.
How to use these docs
The way I recommend using them is the same way I teach. First you pick a problem you want to solve, then you understand what is required to solve it, and based on that you open only the pages for those components and start building.
For example, if your problem is answering questions from your company's policy PDFs, you need document parsing, chunking, embeddings, a vector database, a prompt that uses the retrieved text, and a way to check whether the answers are correct. That is six or seven pages, not the whole book. You read them while you build, and when something breaks, the failure tells you which page to open next.
There are three tracks you can follow if you want a suggested order instead of starting from your own problem.
- Engineer track: for developers who want to build and deploy AI systems. Start with the roadmap.
- System design track: for engineers who already build and want to design systems that scale and stay reliable. Start with AI system design.
- Leaders track: for people who decide what gets built. Start with Leaders.
What each page gives you
Every page starts with a short answer that you can read in a few seconds. After that, each part of the topic gets its own section, explained at the depth that part needs, with code where code helps and with the reason behind each decision. Many pages end with a section called From the floor, which is what happened when we built or discussed this in a session or for a client, including what didn't work. Every page also tells you the next page to read, so you always know where to go after you finish.
Where these docs come from
I have been working in this field since 2017, first in machine learning and data science and then in AI engineering, and I have been teaching it in live cohorts since 2019. The AI Engineer HQ cohort started as a machine learning engineering program and has been updated every time the field moved, so the docs carry that history, and in some places they will tell you which older practice still matters and which one doesn't. The AI-Engineer-Headquarters repository on GitHub holds the code and the same content in markdown, and these pages are the readable version of it.
How these docs connect to the rest of my work
The docs are free, and you can learn everything here on your own. If you want structure around them, there are two programs that use the same material.
- Build30 is a 30 day challenge on buildership.io where you build one thing every day, with a build manual, interview questions and a daily support call. It is the best place to start if you want consistency.
- AI Engineer HQ is a 6 week live cohort on masterdexter.io where you take real systems from the problem statement to deployment and defend your decisions at the end.
You don't need either of them to use these docs. I mention them only so you know where the content comes from and where to go if you want people to build with.
From the floor
When I started writing the Build30 guides, I took the transcripts of my own lectures and used AI only to format them, because when I let a tool generate everything, the content stopped sounding like a person who had built the thing. These docs follow the same rule. The explanations, the opinions and the stories come from sessions and builds, and AI helped with structure and formatting.
In one AI Engineer HQ kickoff, builders asked for help with VS Code, Google Colab and GitHub before we touched any AI topic, because they had followed tutorials in notebooks but had never set up a project on their own machine. So we added a session on setting up a local project in VS Code, with a proper folder structure and a GitHub repository, before the first build. That is why the docs have a Builder foundations section, and why the first 30 days page starts with setup instead of models.
Whatever your level, the advice is the same. Pick a problem first, because the problem tells you which topics matter right now, and everything else can wait until a later build asks for it.
Related
- AI engineer roadmap 2027
- How to learn AI engineering by building (the PILOT method)
- What does an AI engineer actually do in 2027?
- Your first 30 days in AI engineering