The brief
Build and ship a small, real application, using everything in this course.
Not Recall. Yours.
Choosing well
Small enough to finish. One or two screens. If you cannot describe it in three sentences,
it is too big.
Real enough to use. Something you will actually open next month. That is what makes you
notice the problems that matter.
Containing one genuinely tricky rule. Recall had the scheduling rules. Yours needs
something similar — a calculation, a set of conditions, something with edge cases. Without
it, you will not exercise Modules 4 and 5, which is where most of the value is.
Some that work well: a bill splitter with uneven shares. A train fare calculator. A leave
tracker that handles half days and holidays. A recipe scaler with awkward unit conversions.
A marks-to-grade converter with boundaries and rounding.
Notice that every one has a rule that is easy to get slightly wrong. That is the point.
The checklist
Work through this in order. It is the whole course.
Plan (Module 2)
– [ ] Written plan with goal, limits, examples and done-criteria
– [ ] The tricky rule written as exact numbers, not descriptions
– [ ] A “not in this project” list
– [ ] Tested by giving it to two chats and comparing (Lesson 2.7)
Build (Modules 3 and 4)
– [ ] Git repository, committed before you started
– [ ] Built in slices, each one runnable and checkable
– [ ] A commit per step
– [ ] The tricky rule built alone, with tests, before any screen
Check (Module 5)
– [ ] Tests written from your cases, not the agent’s
– [ ] One command runs type check, lint and tests
– [ ] Checked on a phone-sized screen
– [ ] Sabotage test: break each rule, confirm something catches it
Set up (Module 6)
– [ ] AGENTS.md with commands, layout and earned rules
– [ ] Cold-start test passed: a fresh session followed your rules unprompted
Ship (Module 7)
– [ ] Deployed and reachable on a phone
– [ ] Data survives a restart
– [ ] No secrets in the repository
– [ ] CI running on every push, seen to go red once
How to judge your own work
Ask three questions.
Does it work when someone else uses it? Give it to one person and watch silently. Do not
explain. What they do wrong is your real result.
Do you know which rules are protected? From Lesson 5.7. Not “I have tests” — which
rules, specifically.
Could you hand it over? If someone else took your repository tomorrow, could they run it,
test it, and understand the rules, without asking you anything?
That third question is the real measure of everything in Module 6.
If you get stuck
Every stuck point in this course has an address:
- Do not know what to build → Lesson 2.1, the hidden decisions
- It built the wrong thing → Lesson 2.3, the four parts
- It went wrong and got worse → Lesson 4.6, start again
- Tests pass but it is wrong → Lesson 4.4, your cases not its cases
- It forgot everything → Lesson 6.2, write it down
- It is confidently wrong → Lesson 5.1, ask for evidence
What you have actually learned
Look back at Module 1. You could not write code, or you wrote it by hand. Either way, the
typing was the visible work.
Now: you can describe what you want precisely enough to get it. You can direct something
that builds it. You can tell whether what came back is right, including when it looks right
and is not. You can set up a project so this happens the same way every time. And you know
where to slow down.
None of that is about a product name. All of it survives the next tool.
Season 2
Season 2 goes further: several agents working together, connecting agents to your own
tools and data, building your own agents, checking agent output at scale, and working on
large old codebases.
All of it assumes what you just did. Ship this first.
Finish this
- Build it. Ship it. Send the link to one person.
- Complete the checklist honestly, including boxes you left unticked.
- Write two paragraphs on what surprised you. That is the part you will still remember in a
year.