This course is for developers who just finished a bootcamp and want to learn how to ship real products using AI as a collaborator — not as autocomplete. Over four weeks you will build something, deploy it publicly on Cloudflare, and be able to defend every architectural decision in it.
The course is opinionated. AI coding tools make it easy to produce code you don't understand. We will not do that. You'll leave able to work fast and explain what you built, because both are part of passing. The course runs online over Google Meet; sessions are recorded.
By the end of this course a graduate should be able to sit next to a stakeholder, turn a problem into a working public URL inside a week, and explain every choice along the way.
This is a pass/fail course. There are no grades and no quizzes. To pass, you need all four of the following:
README.md.README.md.The week 4 live demo is part of the course experience, not a pass gate. The instructor will ask questions about your architecture and data model; you're expected to understand those at the architectural level. File-by-file omniscience is not required.
Send this list one week before session one. Solving install problems on the fly will eat week 1.
nvm).claude --version.npm install -g wrangler, then wrangler login.The central risk of AI-assisted development is shipping code you couldn't defend. Five mechanisms push against that, applied throughout the course.
Before every logical commit, you invoke the rubber-duck-quiz skill. Claude asks you four kinds of questions about the diff (what / why / what-if / teach-it-back). Gaps get noted. Claude can draft the commit message and run git commit — that's encouraged — but the quiz is the gate: you must understand the change well enough to defend it before it lands.
--dangerously-skip-permissions and other auto-accept modes are forbidden until week 3. You read every diff. Starting week 3 you can use scoped autonomy for well-tested subtasks, but you still review at the turn boundary.
Twice during the course (weeks 2 and 4), Claude generates a Mermaid diagram of your app. Your job is to find what's wrong or missing and commit the corrected diagram to docs/architecture.md. The instructor surfaces a few interesting corrections at the next session. The act of finding Claude's mistakes proves understanding more reliably than building does.
Because the course is remote, peer learning happens through short videos rather than synchronous pairs. You'll record two ≤5 min explainer videos over the course — a PRD video after week 1 and an architecture walkthrough after week 3 — and commit them to your repo's README.md. The cohort is encouraged to review peers' videos between sessions; the instructor highlights standout ones at the start of class. How many peer videos you watch depends on cohort size — watching some is the floor.
You screen-share your deployed app and walk through your repo. The instructor asks questions about your architecture and data model — it's a conversation, not an interrogation, and it's not a pass gate. Knowing this is coming from week 1 still changes how you code, because you want the conversation to go well.
Across all four weeks the instructor builds one small app live — the Community Events Board — so students see the full arc from zero to deployed.
The brief: A public website for a fictional small town that lists upcoming community events. Any resident can see the list. Approved admins can add events through a simple form. Events have a title, description, date, category, and optionally an image. There's a read-only JSON API so the local newspaper could pull the feed.
It's boring on purpose. The point is that it touches every major piece without getting in its own way:
| Feature | Cloudflare product | Introduced in |
|---|---|---|
| Public event list (static + data) | Pages + Workers | Week 1 |
| Event storage | D1 | Week 1 |
| Admin add-event form, validation | Workers + Vitest | Week 2 |
| Image upload for event photos | R2 | Week 3 |
| Auto-categorize event from description | Workers AI | Week 3 |
| Per-event live attendee counter | Durable Objects | Week 3 (light touch) |
| Scheduled cleanup of past events | Workers scheduled handler | Week 4 |
Student projects don't have to use this same stack — the product-picker skill helps them choose for their own PRD. The demo project is a reference, not a template.
Every student starts with the same skeleton. The skeleton embeds the pedagogy — it doesn't just scaffold code, it scaffolds how you work.
CLAUDE.md — project context, tech stack slot, TDD expectations, "teach-back mode" rulesREADME.md — template with slots for the deployed URL, the PRD video, and the demo videodocs/PRD.md — the PRD template Claude fills out with youdocs/DESIGN.md — the design brief template the design-brief skill fills out with you (defaults: React + Headless UI + Tailwind)docs/BUILDPLAN.md — the phased build plan the build-plan skill fills out, slicing the project into context-window-sized phases.claude/settings.example.json — hooks config (Stop hook = default; PostToolUse = strict mode).claude/skills/:| Skill | Use it when |
|---|---|
pm-interview | You need to turn an idea into a PRD |
design-brief | Before you write UI — pick mood, components, tokens, a11y |
build-plan | Before coding — slice the project into phases that fit one session each |
rubber-duck-quiz | Before every meaningful commit |
explain-this-code | You don't understand what Claude wrote |
architecture-diagram | Generating + critiquing Mermaid for your app |
cloudflare-product-picker | Picking the right CF product for a need |
Hooks let Claude Code run your commands automatically at lifecycle events. We use a Stop hook by default: when Claude finishes a turn, it runs npm test. Claude sees failures in the next turn and keeps working. This enforces TDD without per-edit noise. A stricter PostToolUse hook (runs after every edit) is provided as an optional upgrade.
Goal: Every student ships a "hello world" to a public Cloudflare URL, leaves class with a working Claude Code setup, and has a PRD conversation started.
--dangerously-skip-permissions until week 3" rule and why.claude CLI tour: starting a session, where context comes from, the attention budget concept.CLAUDE.md: what to put in it, what not to put in it. Live-edit the demo project's CLAUDE.md.explain-this-code on a snippet.shift+tab). The permissions prompt. Reading diffs. Accept / reject./commit, /test) as quality-of-life.llms-full.txt pattern: why we point Claude at it, and how (https://developers.cloudflare.com/llms-full.txt).npm create cloudflare@latest → pick Hono on Workers → wrangler deploy → public URL in under 10 minutes.Everyone runs the same flow the instructor just did:
wrangler login.npm create cloudflare@latest my-first-worker.wrangler deploy. Share the public URL in the chat.Instructor circulates. Typical blockers: Node version, Wrangler auth, billing email confirmation. Have a checklist printed out.
pm-interview skill. Live-demo a 5-minute excerpt of Claude interviewing the instructor about a fake idea.design-brief skill: not run in class, but it's the natural next step once the PRD's must-haves are stable. It's part of week 1 homework. Defaults are React + Headless UI + Tailwind.build-plan: also homework. Once PRD + DESIGN are stable, it slices the project into 3–6 phases sized to fit one Claude Code session each. Frame it as token-economy work — every minute spent on a good build plan saves an hour of context-thrashing later.docs/PRD.md filled in, at least through sections 1–5.design-brief skill once your PRD's must-haves are stable. Commit docs/DESIGN.md. Defaults are React + Headless UI + Tailwind — capture any deviation and the reason.create-cloudflare. Push it to a public Git repo. Deploy something — anything — to a public URL and link it from README.md.build-plan skill after bootstrapping. Commit docs/BUILDPLAN.md with 3–6 phases, each naming the doc sections and files Claude should load to execute it. The plan will drift — that's fine; you'll re-run the skill between weeks.README.md. Drop the link in the cohort channel — peers will be watching them before week 2.Goal: Students leave running the full agentic loop — plan → propose → diff → test → commit — on their own project, with tests running automatically via a Stop hook.
Instructor highlights 2–3 standout PRD videos posted between sessions and opens a brief discussion. Anyone who watched a peer's video shares one sharp question about that peer's "out of scope" section. Volunteers describe what changed in their own PRD after watching peers' videos.
BUILDPLAN.md is for the whole project — the two compose.BUILDPLAN.md phase to drive what gets loaded — only the docs and files that phase names. /clear at every phase boundary./review command that makes Claude critique its own last change.@cloudflare/vitest-pool-workers setup. Show how tests run against the real Workers runtime..claude/settings.json). Demo: add a feature to the events board TDD-style. Claude's Stop hook runs the tests after each turn; Claude fixes a failure before the instructor intervenes.PostToolUse mode for students who want strict TDD.On your own project:
docs/BUILDPLAN.md. Work the next phase, not whatever's most fun. Load only the docs and files that phase names — start with /clear.docs/DESIGN.md first. Plan and code should honor the components, tokens, and a11y floor captured there. If the brief is missing a decision the feature needs, update the brief before coding.rubber-duck-quiz before committing.git commit — the rubber-duck-quiz is the gate, not the message itself.Instructor circulates. Watch for students auto-accepting diffs — call it out gently.
architecture-diagram. Claude produces a Mermaid diagram from their current code.docs/architecture.md.docs/BUILDPLAN.md.docs/architecture.md with a Mermaid diagram you've personally audited against the code.build-plan if reality has diverged from the plan. Append to the decision log; don't rewrite from scratch.Goal: Students justify adding at least one new Cloudflare product to their project, and begin using scoped autonomy (--dangerously-skip-permissions with an allowlist) for well-tested subtasks.
cloudflare-product-picker skill. Walk through three example needs from student PRDs and pick products live./permissions workflow.On your own project:
cloudflare-product-picker. Have Claude walk you through the decision.Use the time to draft and record your ≤5 min architecture walkthrough video: screen share over your repo, narrate the major components, the data model, and the one decision you'd most want a reviewer to push back on.
Instructor drops into breakout rooms to listen in and coach. Commit the link to README.md and post it in the cohort channel — peers will watch before week 4.
End-of-class share: one volunteer plays a 30-second clip of their video and describes the part they're least sure about.
Goal: Every student demos a publicly-deployed project, answers unscripted questions about their code, and leaves with a realistic plan for continuing past the course.
wrangler secret put vs .dev.vars. Never commit either.wrangler tail, rollback, a 5-minute incident drill).Students finalize deploys, fix last bugs, polish the README and the walkthrough video. Instructor circulates aggressively — last chance for unblocking. Students who finish early help others.
Target ~3 minutes per student with a cohort of 12. Each student screen-shares and:
No slides. No pre-written demo script. The live demo is a conversation, not a pass gate — pass criteria (attendance, public repo, deployed Cloudflare URL, the two videos linked from README) should already be satisfied by now. If a student struggles on a question, coach them through it — it's still a teaching moment.
The closing five minutes: ideas for continuing. Turning a project into a side business. Reaching out to the stakeholder with an invoice. Joining open-source Cloudflare projects. Teaching what you learned to a friend. The course ends; the work doesn't.