Start here

Which one are you?

1. Have you used an AI chatbot for real work? If no, you're Curious.
2. Do you want to write code that calls a model? If yes, you're Builder.
3. Otherwise you're Practical, which is where most people are and where the internet serves you worst.

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.
2. Learn the three failure modes. Confident wrongness, silent staleness, and losing the thread in long conversations. Knowing these three makes you dramatically harder to mislead.
3. Then, one structured course. Not before the above. Courses land much better once you have something to attach them to.

When you can explain why a model might invent a citation → move to Practical.

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 prompt-engineering listicles, the other is “train a transformer from scratch.” 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

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.
4. Then, and only then, tooling. Which assistant, which integrations, which automations.

If you find yourself wanting to automate a workflow rather than run it → move to Builder.

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.
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.

Concepts you'll need either way → Concepts