Why this level matters
In deterministic software, the same input always gives the same output. A rule such as "if the sender is on the VIP list, mark the email Urgent" behaves the same way every time, and a test either passes or fails.
A feature built on a large language model (LLM) does not work like that. Through this course you will manage one running feature: an AI email triage assistant. It reads incoming support emails, gives each one a category (Billing, Bug, Account, Other), sets a priority, and drafts a one-line summary for the agent. Before you write specs or evals, you need a clear picture of what changes once an LLM is part of the product.
Difference 1: The output varies
An LLM produces its answer by sampling from probabilities. If you send the same email twice, you can get two summaries that are worded differently, and on a borderline email you can get two different categories.
- Turning down randomness settings does not fully solve this. OpenAI's own documentation says that its
seedparameter is "best effort" and that determinism "isn't guaranteed". - Some providers now limit these settings. On Anthropic's Claude 4.7 and later models, the API rejects a non-default
temperature.
What you do: Stop asking whether the output is identical every time. Ask whether it is acceptable every time.
Difference 2: Quality comes in degrees
A rule-based feature either works or is broken. An LLM feature is right most of the time, and its quality sits on a scale:
- A summary can be accurate but too long.
- A category can be defensible but not the one a human would choose.
- A priority can be wrong on only 1 email in 50, and that one email can be a customer threatening to leave.
What you do: Describe quality as rates and severities. For example, "what share of emails get the right category, and how bad are the misses?" Do not describe it as a single pass/fail.
Difference 3: You depend on a model provider
Your feature runs on a model that someone else builds, updates and eventually retires.
- Providers publish deprecation schedules. Anthropic, for example, labels each model Active, Legacy, Deprecated or Retired. It commits to at least 60 days' notice before retiring a publicly released model, and requests to a retired model fail.
- OpenAI keeps a public deprecations page with shutdown dates for older model snapshots and APIs.
- A replacement model can be better overall and still worse on your task.
What you do: Treat the model as a dependency that has a lifecycle. Record which model the feature uses and who watches for deprecation notices.
Difference 4: Testing needs examples, not just test cases
A unit test checks one exact expected value. For the triage assistant you cannot list every possible email, and many emails have more than one acceptable answer. Teams judge an LLM feature by running it over a set of representative examples and scoring the results. Later levels show how to build these eval sets.
What you do: Start collecting real (anonymised) emails now, including messy ones.
Difference 5: Failures are less predictable
Rule-based bugs can usually be reproduced and traced to a line of code. LLM failures can be confident and plausible, which makes them hard to spot. For example, the model might write a fluent summary that states a refund amount the email never mentioned. Unusual inputs can also change its behaviour: an email written in another language, or one containing text such as "ignore your instructions".
What you do: Assume some failures will reach users. Plan how a person can see them, correct them and report them.
Task: Map what is probabilistic and what is deterministic
Most AI features combine the two kinds of component. Follow these steps for the triage assistant:
- List each step the feature performs, from the email arriving to the agent seeing the result.
- Label each step. Mark it Probabilistic if an LLM makes the decision. Mark it Deterministic if code or a fixed rule makes it.
- Note the risk of each probabilistic step: what a wrong output looks like.
| Step | Type | Risk if wrong |
|---|---|---|
| Fetch email from inbox | Deterministic | Low |
| Strip signatures and attachments | Deterministic | Low |
| Assign category | Probabilistic | Wrong queue, delay |
| Assign priority | Probabilistic | Urgent issue missed |
| Write summary | Probabilistic | Agent misled |
| Route to queue based on category | Deterministic (but fed by LLM output) | Inherits LLM error |
| Show "AI-generated" label | Deterministic | Low |
Note the routing row. A deterministic step that acts on LLM output inherits the LLM's uncertainty.
Task: Write a one-page stakeholder brief
Your first artefact is a one-page brief for engineering, support, design and legal. Use this structure:
- What the feature does. Two sentences, in plain language.
- What is different. The five differences above, each tied to the triage assistant.
- Component map. Your probabilistic and deterministic table.
- What this means for each team. For example, support should expect occasional miscategorised tickets, and engineering should log the model version.
- Open questions. For example, "How wrong is too wrong for priority?" (You will answer this in later levels.)
Keep it to one page. The brief is meant to set expectations, not to serve as a full spec.
Key takeaways
- LLM outputs vary. The same input can give different results, and setting a seed does not guarantee identical outputs.
- Quality is a matter of degree, so measure rates and severity instead of a single pass/fail.
- The model is an outside dependency that providers update and retire on their own schedule.
- AI features are judged by running them over sets of examples, not only by exact-match tests.
- Most features mix probabilistic and deterministic steps. Deterministic steps that act on LLM output inherit its errors.
- Your artefact: a one-page brief that maps these differences onto the triage assistant.