Pick a depth. Each prompt opens in your AI pre-loaded with the lesson. Click a row to preview the prompt.
The most common failure mode is not building the wrong thing, it is never stopping. Every project in this course has a stated finish line, and the finish line is deliberately a demonstrable behaviour rather than a feature list: a killed process resumes, a pull request that degrades quality fails CI, a provider can be broken live while traffic keeps flowing. Behaviour-shaped finish lines are testable by a stranger, which is exactly what you need when the stranger is deciding whether to interview you. Feature-shaped finish lines ('add caching, add auth, add a UI') have no end.
Write your finish line as something a reviewer could verify in under five minutes without reading your code. If verifying it requires them to trust you, it is not a finish line.
# done_when.md — one per project, written before Phase 1
## Project 1 — Knowledge-graph RAG
DONE WHEN: a FastAPI endpoint answers a question with citations that
resolve to real chunk ids, AND the README opens with an accuracy table
broken out by hop count against a vector-only baseline.
NOT done when: "the graph is built" (unmeasured)
NOT done when: "it works on my examples" (unfalsifiable)
## How a stranger verifies it in 5 minutes
1. Reads the table at the top of the README. (30s)
2. Watches the 90-second demo video. (90s)
3. Hits the deployed endpoint with their own question. (60s)
4. Clicks one citation and lands on the source text. (30s)
# If step 3 requires them to run docker-compose and seed a database,
# most reviewers stop at step 2. Deploy it somewhere, even cheaply.python3 main.py