You already use these systems. Understand how they are built.

You have built something that works. Users are happy, the model responses are good, and then the invoice arrives. Or worse: your application grinds to a halt at 9 in the morning on a Monday with a wall of HTTP 429 errors and no obvious explanation. Both problems have the same root cause: most developers learn enough about large language model APIs to get a prototype running, and then discover the billing and throttling mechanics only when something breaks in production. This lesson untangles those mechanics. Rate limits and spend quotas are different things, controlled by different levers, and they are routinely confused at considerable cost. Token pricing has a structure that rewards deliberate prompt design, and a toolkit of techniques (caching, batching, and model routing) can meaningfully reduce what you pay without degrading what your users experience. By the end you will be able to read a provider's pricing page with confidence, diagnose throttling errors correctly, and make informed decisions about when to call a frontier model and when a smaller one will do.

You have a large language model and it is not doing what you need. The output is in the wrong tone, the format keeps drifting, or the model simply does not know enough about your domain to be useful. The temptation, especially after reading vendor documentation, is to reach immediately for fine-tuning: feed the model your data, retrain it on your use case, and get reliable results. That instinct is often wrong, and acting on it prematurely is an expensive mistake. Fine-tuning and prompting are not interchangeable tools that sit on the same shelf. They operate at fundamentally different levels of the model's architecture, solve different categories of problem, and carry very different costs, so choosing between them is one of the most consequential technical decisions a practitioner makes. As of 2026, frontier instruction-tuned models respond well to structured, detailed prompts, and many tasks that required fine-tuning in earlier generations are now solvable with prompting alone. At the same time, there are situations where no amount of careful prompting will get you where you need to go, and recognising those early saves significant time and money. This lesson gives you a clear mental model for making that call.

Most people who work with large language models reach the same realisation after a run of frustrating results: what you put into a model shapes what comes out in ways that are neither arbitrary nor magical. Prompt engineering is the discipline of understanding those relationships well enough to exploit them deliberately. The phrase attracts some scepticism, often dismissed as a temporary workaround until models become smart enough to understand plain instructions. That view misunderstands what is happening. Prompting is structured communication with a probabilistic system that predicts the most likely continuation of your input, not the coaxing of a reluctant machine into compliance. Every word you write shifts that probability distribution. This lesson treats prompt engineering as the applied discipline it is. You will learn why prompts work the way they do, master the core patterns experienced practitioners reach for, understand how to structure prompts for production systems rather than one-off experiments, and recognise the security and failure risks that can derail real deployments. You will also get a framework for iterating on prompts systematically, because good prompting is a craft practised over many iterations, not a secret unlocked by a single trick. By the end, you will have a principled toolkit rather than a bag of incantations.

If you have spent any time deploying a large language model in a real product, you have almost certainly wrestled with a system prompt, even if you did not call it that. It is the instruction layer that sits above every conversation, shaping how the model behaves before a user types a single word. Think of it as the briefing you give a contractor before they start work: the user's messages are the day-to-day tasks, while the system prompt is the employment contract, the house style guide, and the list of things they are not allowed to do, all rolled into one. Get it right and the model feels coherent, purposeful, and safe. Get it wrong and you will spend weeks chasing inconsistent outputs and confused users. System prompts are where product decisions become model behaviour: defining persona, constraining scope, setting tone, and establishing guardrails. They are also where many practitioners make avoidable mistakes, over-specifying in ways the model ignores, under-specifying in ways the model fills unpredictably, or writing instructions that contradict each other under pressure. This lesson covers the essentials: what a system prompt actually is at a technical level, what belongs in one, and how to write instructions that hold up in production rather than just in your test suite.

You have crafted a careful prompt, but two runs of the same request produce very different results. One response is crisp and on-target, the next meanders. Or perhaps you need deterministic output for a classification task but keep getting variation you cannot account for. The culprit, more often than not, is not the prompt. It is the generation parameters you are using, or not using deliberately. Large language models do not produce text the way a calculator produces a number. At each step the model outputs a probability distribution across tens of thousands of possible next tokens, the basic units of text, and generation parameters determine how it samples from that distribution. Change the parameters and you change the character of the output entirely, without touching a single word of your prompt. This lesson demystifies the parameters practitioners meet most: temperature, top-p and top-k, repetition and frequency penalties, and max tokens.

If you have built or studied a retrieval-augmented generation system, you have almost certainly encountered a vector database. If you have not, you will. As of 2026, vector databases sit at the heart of most production AI retrieval pipelines, and understanding what they actually do, as opposed to what the marketing suggests, is becoming a core competency for AI practitioners. The term is frequently misunderstood, and that misunderstanding leads to poor architecture decisions: practitioners sometimes treat vector databases as AI in their own right, assume they can replace a relational database, or expect them to compensate for weak embeddings. None of these is true. Think of it this way: every piece of content you feed into an embedding model becomes a point on a vast, high-dimensional map, and similar content clusters together. A vector database is the specialised infrastructure that lets you ask, in milliseconds, "what is nearest to this point?" This lesson covers what a vector database actually stores, how it retrieves data geometrically rather than by keyword, why the approximate nature of its search is a feature rather than a bug, and where vector databases fit in a production stack and where they do not.