Pre-course project: set your goals
Before module 1, name the real system you will work on for this course. Then name the moment it met production and broke, or the moment you can see coming. Everything you build from here hangs off those two answers.
Pick the system, and the scar
This is not busywork. Every lesson, every lab, and all five projects are built against your system. Choosing a real one now is the single most important setup step. You come back to this page in the Shipping It module and measure the distance you moved.
Bring a real problem, not a toy. Someone who brings "the support bot that embarrassed us last quarter" gets far more out of this than someone building a generic demo. The generic demo has no constraints, and constraints are the entire subject.
The four answers
The four answers build on each other, and you check them again at the end of the course.
1. Name the system in one sentence. A real or planned LLM feature you own, or care about. "A support assistant over our help docs." "An agent that files expenses."
2. Describe the moment it broke, or would. The moment an LLM feature met production and fell apart: a cost surprise, a confidently wrong answer, an outage, a leak. Be specific. "It was slow sometimes" is not an answer.
3. Define what "a system that holds" means. In your own words: what would have to be true for you to trust this in front of real users, at real volume?
4. State one thing you want to leave able to do. Your personal goal for this course. We check it in the Shipping It module.
The one-pager
Write half a page. Four headings, one answer each.
| Heading | What goes under it |
|---|---|
| My system | One sentence: what it does, and for whom |
| The break | The moment it met production and failed, or would |
| Holds means | I would trust this in production when ... |
| My goal | By the end of the course I want to be able to ... |
Concrete beats aspirational
| Strong | Weak |
|---|---|
| A real system you can describe, and will keep using all course | A generic demo you will abandon by module 2 |
| A specific failure, with what actually went wrong | "It was slow sometimes", with no detail |
| "Holds" defined in terms you could test | "I want to learn about AI", with nothing measurable |
The difference between the two columns is testability. A weak answer cannot be wrong, which is exactly why it cannot help you.
Bring it to module 1
Half a page is plenty. This becomes the backbone of every project in the course.
Deliverable: the four-line one-pager above.
Not sure yet? Pick the closest real thing you have. You can narrow the scope in module 1. You cannot do the course against nothing.
Recap
- Choose one real system now. Every project in this course applies to it.
- Name a specific failure, not a vague worry. The specificity is what makes the later modules bite.
- Define what "it holds" means in testable terms. That definition becomes your eval plan in the Evals and Observability module.
- Next: module 1, where the first real decision is whether you need an agent at all.