Where to Go Next

The architecture is behind you. This closing chapter is about what comes after it — the training stages that turn a predictor into an assistant, the systems built around it, and which of our other courses to open next.

Large Language Models: From Transformers to Frontier Models

We have finally reached the end of this course, so pat yourself on the back if you made it through all of this long, dense text. Writing it in a structured way was a challenge in itself, and, trust me, without an AI assistant this would have been a six-month journey. We have made an honest attempt to keep the course original, and we have tried to cite our sources wherever possible. Most of what you have read came out of a lot of interview experience and our own rigorous research and reading research papers. But the journey does not end here. Now that the architecture is behind you, this chapter points you at what to learn and build next.

First, be clear about what you have built

Everything in this course produces one thing: a very good next-token predictor, trained on an ocean of text. Left exactly there, the model will happily continue any text you give it — rudely, falsely or unhelpfully — because "continue plausibly" is the only instruction it was ever given.

The polite, careful, instruction-following assistant you talk to every day is that same predictor after a second stage of training. We find it useful to think of it this way: the architecture is the engine, and that second stage is the steering. A superb engine with no steering is not a car.

That second stage is post-training, and Module 10 covered its core. What follows places it in the bigger picture and names the parts that sit beyond this course.

Teaching the model to follow instructions

The first step of post-training is supervised fine-tuning: show the model thousands of examples of the behaviour you want, each one a prompt paired with a good answer. Nothing about the architecture changes, and nothing about the objective changes either — it is still predicting the next token. Only the data changes, from raw web text to carefully written demonstrations.

That one change is enough to turn a raw predictor into something that answers your question instead of drifting off into whatever text seemed likely to follow it.

Teaching the model what people actually prefer

Demonstrations take you a long way, but not all the way. It is usually far easier to say which of two answers is better than to sit down and write the perfect one, and that simple observation is what the next stage is built on.

We covered this in Model Alignment: RLHF, which learns a reward model from human rankings and then optimises the model against it, and DPO, which skips the reward model and learns straight from preferred-versus-rejected pairs. Either route pushes the model toward answers people genuinely prefer rather than answers that merely look plausible.

How far this goes beyond what we covered

Preference optimization is a large field, and Module 10 only opened the door to it. Today's reasoning systems push it much further, using large-scale reinforcement learning against rewards a machine can check by itself — did the code run, is the proof valid, is the answer correct. That machinery is beyond the scope of this course, but it is built on exactly the ideas you have just read.

Reasoning models

The newest frontier is teaching a model to reason: to work through a long internal chain of thought before it commits to an answer, and to get steadily better at it through reinforcement learning against rewards that can be checked automatically. This is why some models now visibly "think" for a while before replying.

Here is the part worth holding on to. None of that is a new architecture. It is the same transformer you have spent this course building — the same attention, the same experts, the same cache — with the reasoning behaviour added in post-training. The engine you now understand is exactly the engine those systems run on.

The next course to open: Retrieval-Augmented Generation

If you want one clear next step, this is the one we would pick for you.

A model knows only what it absorbed during training. It has never seen your company's handbook, last quarter's incident reports or anything that happened after its training cut-off — and when it does not know something, it does not stay quiet. It produces a fluent, confident guess. Retrieval-Augmented Generation fixes this by finding the right passages first and putting them in front of the model, so it answers by reading rather than by remembering.

This matters for two reasons. It is the architecture behind most of the AI products being built in the industry today, which makes it the most immediately employable thing you can learn after this course. And it rests entirely on what you already know: embeddings, context windows, attention over that context, and the simple fact that a language model conditions on whatever you put in its prompt.

Our Advanced RAG Masterclass takes you from why retrieval is needed at all through chunking, embeddings, vector search, reranking and evaluation, and on to agents that decide for themselves what to look up. Like this course, it is concepts and diagrams rather than code. A good place to start is RAG, Fine-Tuning or Long Context, which answers the question every engineer eventually has to decide for themselves.

A few other honest suggestions

  • Read a real model's technical report. You now have the vocabulary for it. Pick a recent open model, open its paper, and read the architecture section. You will recognise the pieces, and the notation will finally make sense instead of looking like decoration.
  • Build one block from scratch. Understanding something and being able to build it are not the same thing. Write a small attention layer, a mixture-of-experts router or RoPE in a few dozen lines, and recognition turns into real knowledge.
  • Learn to measure before you learn anything else new. Module 11 covered perplexity, BLEU and ROUGE, and preference ranking. Whatever you build next, you will need to answer "is this actually working?" — and that question is harder than it sounds.
  • Take the failure modes seriously. Module 12 looked at hallucination, jailbreaks and what interpretability can and cannot tell us. These are not edge cases to be patched later; they follow directly from what these models are, and anyone shipping a product has to design around them.
  • Go back when something feels shaky. If any step here felt like it rested on something you half-remembered, our Deep Learning course covers the foundations underneath all of it — gradients, backpropagation, loss functions and optimizers — and Machine Learning Techniques covers what sits under that.

A closing word

The thread running through this entire course has been one almost embarrassingly simple idea: predict the next token, at scale. Everything else we built — attention so that tokens can share information, positional encodings to restore the order attention throws away, cache tricks and sparse experts and low-precision arithmetic — exists to make that one idea scale far enough to become remarkable.

So the architecture is not magic. It is a stack of understandable parts, each one solving a problem you can name, put together with care. You understand that stack now. Everything from here is practice.

Thank you for reading this far. If something in this course was unclear, or wrong, we would genuinely like to know.

EasyPost-training

Why is a pretrained model not yet a usable assistant, and what stage fixes that?

MediumPost-training

How do preference-based methods like RLHF differ from plain instruction tuning?

MediumPost-trainingreasoning

Reasoning models 'think' before answering. How does this relate to the architecture built in this course?

MediumRAG

Why is retrieval the natural next subject after this course, and what does it rest on?