Problem-solving recipes

A step-by-step procedure for every problem type this course teaches — what to do first, what to do next, and how to tell which case you're in.

What are you being asked to do?

What are you actually trying to do? Given a small word-frequency corpus and need the next tokenizer merge -> run byte-pair encoding by hand. Writing a prompt you need to work reliably, not just once by luck -> write a structured prompt. An off-the-shelf model doesn't handle a task reliably and you need to decide what to reach for next -> the adaptation ladder. Shipping an application that reads content you didn't fully control (user input, retrieved documents, tool results) -> harden an LLM application end to end. Built a composed system and need to explain it to someone who wasn't in the room -> write the 11-point architecture document.

Tokens and prompts

Run one round of byte-pair encoding

Use when: you're given a small word-frequency corpus and asked to find the next BPE merge (or to run several merges in sequence)

Goal: the single next symbol pair to merge, and the corpus's new symbol sequences after that merge

Byte-pair encoding by hand

Write a prompt in four parts

Use when: you're writing a prompt for a task you want to work reliably, not just once by luck

Goal: a prompt that states what to do, gives the model everything it needs, and leaves as little as possible to guesswork

Instructions, context, examples, and constraints

Deciding how to adapt a model

Decide how to adapt a language model to a task

Use when: an off-the-shelf model doesn't yet handle a task well, and you need to decide which adaptation technique to reach for next

Goal: the cheapest technique that genuinely satisfies the task's real requirements, climbed no further than necessary

The adaptation ladder as a decision chain

This course's "which technique do I use?" index -- prompting through fine-tuning, climbed no further than necessary.

Security

Harden an LLM application end to end

Use when: you're shipping an application that lets a model read content the team doesn't fully control -- user input, retrieved documents, tool results. You want a concrete, ordered checklist of defenses, not just the general idea

Goal: a stack of independent defenses applied at the right point in the pipeline. No single missed defense should ever be the only thing standing between an attacker and a real result

Audit logging and defense in depth

The capstone

Write an 11-point architecture document

Use when: you've built a composed LLM application and need to explain it to a reader who wasn't in the room while you built it

Goal: a document that explains every real design decision behind the system -- what was chosen, why, and what it doesn't do -- not just what the system does

The capstone brief and the 11-point architecture document