Start here

Track 01 — Curious

You are not behind. The entire field is about three years into being publicly usable, and most of the people talking confidently about it are also improvising. Your goal here is not to learn how AI works internally. It's to build accurate intuitions about what it does, what it can't do, and why it fails in the specific ways it does.

What to do, in order

1. Use one, deliberately, for a week. Pick one real task you do often and do it with an assistant instead. Reading about this is much less useful than ten minutes of contact. Which one, and what to judge it on: how to choose an assistant.
2. Learn the three failure modes. Knowing these three makes you dramatically harder to mislead, and there is a page here on each:
   • Confident wrongness → Hallucination
   • Silent staleness → Training cutoff
   • Losing the thread in long conversations → Context windows
3. Then, one structured course. Not before the above. Courses land much better once you have something to attach them to.

Two more written for exactly this track, whenever you want them: What AI is actually bad at, which is the long version of the three failure modes above, and the glossary for the words people use as though you already know them.

Track 02 — Practical

This is the underserved middle, and probably where you are. You use these tools most days. You are not going to become a machine-learning engineer and you don't need to. But you're also past the tips-and-tricks stage, and you've noticed that the difference between a bad result and a good one is usually something about how you asked that nobody has explained.

The published material forks badly here: one side is lists of prompt tips, the other is how to build a language model from nothing. Neither answers the actual question, which is how do I get reliably good work out of this thing, and how do I know when to distrust it?

What actually moves the needle

Start with Getting better results, which is this track's page: the handful of habits that reliably improve an answer, why each one works, and which popular advice isn't supported. Then, in order:

1. Understand context. Nearly every mysterious failure in long sessions traces back to how context works. This is the highest-leverage concept on the whole site. → Context windows
2. Learn to give reference material, not just instructions. The single biggest quality jump for most people is pasting in the actual document, example, or data instead of describing it.
3. Learn what the model cannot know. Training cutoffs, no access to your files unless you give it them, no memory between sessions unless the product adds it. Most “the AI lied to me” stories are one of these three. → Training cutoff, and Hallucination for what happens when it fills the gap anyway
4. Know when a slower answer is the better one. Some models can be told to work through a problem before replying. It helps on genuinely multi-step work and does nothing on most other tasks, and the reasoning you can read is not always the reason for the answer. → Thinking and reasoning
5. Then, and only then, tooling. Which assistant, which integrations, which automations.

Track 03 — Builder

You want a model inside something you're making. The good news is that the barrier here has collapsed: an API call is an HTTP request, and you can have something working in an afternoon. The bad news is that the gap between “working demo” and “thing I'd let a customer use” is almost entirely made of concerns nobody warns you about.

The order that saves you time

1. Make one raw API call by hand. Before any framework. Understand the request and response shape yourself, or you will be debugging an abstraction over a thing you don't know.
2. Read the pricing model before you build. Cost scales with tokens, output costs multiples of input, and caching changes the maths enormously. → Model facts
3. Tool use, then retrieval, then agents. In that order. Agents are the interesting part and the last part; most people attempt them third and get lost. → Tool use, then RAG and retrieval, then Agents
4. Assume it will fail and design for it. Rate limits, refusals, truncated output, malformed responses. This is the actual difference between a demo and a product. → Designing for the ways it fails

One more, further out than most people expect: fine-tuning is where builders often reach first and should reach last, because it teaches a model how to behave rather than what is true. If the problem is "it doesn't know about my business," the answer is almost always retrieval.