About this course
An independent, English-language introduction to Claude Code, written to be worked through rather than read.
How it is built
Where it matters, a module exists twice: once for the Claude desktop app and once for the terminal. That is not padding. The two tracks lead to genuinely different habits — the desktop app shows you diffs in colour and asks permission with buttons, while the terminal prints a unified diff and waits for a single keystroke — and mixing the two sets of instructions is how people get lost.
Both tracks build the same project and hit the same checkpoints, which are marked as git tags. That means you can switch tracks at any module boundary, and it means an exercise can tell you exactly what state to start from.
The switch at the top of each lesson is the spine of the site. It changes the instructions, and it changes the accent colour of the whole page, so a glance tells you which track you are on.
Every module has the same frame
So you can tell, before you start and after you finish, whether it worked:
- What you will be able to do — the one thing the module is for.
- You need — software, accounts and files that must already exist.
- Starting state — where the project should be, and how to get back there.
- You have finished when — observable results, not "you understand X".
- If it goes wrong — the three failures that actually happen.
- On your own — a variation with no instructions.
Who it is for
- People with no programming background who want to build small, real things
- Hobbyist programmers who want to work faster than they type
- Freelancers and small teams looking for leverage on routine work
- Anyone curious about what assisted development actually feels like day to day
What it is not
It is not official. It is not affiliated with Anthropic, not endorsed by them, and not a substitute for the documentation, which is where you should go when something behaves differently from what you read here.
It is also not a programming course. You will read HTML, CSS and JavaScript, and module 0 gives you enough to follow along, but the subject here is the tool and the review habits around it.
Claude Code moves quickly. Interface details drift, and anything described here as a menu item or a keyboard shortcut is the first thing likely to age. Where a shortcut is named, the lesson also tells you where to check the current one in the app. The workflow underneath — ask, review, approve, test, commit — has been stable throughout, and is the part worth internalising.
Scope
Nineteen modules, numbered 0 to 18. Eight are written twice, once per track, because the desktop app and the terminal genuinely lead to different habits there. Nine cover things that are the same either way — a file on disk, a settings key, a command that exists in both — and writing those twice would be padding rather than teaching. Those nine are marked Both tracks in the module list and say so at the top of the page, so a terminal reader can tell the difference between "there is no terminal version" and "this is the terminal version".
Two modules are single-track on purpose. Connectors is about the desktop app's own interface; configuring MCP by hand is the terminal counterpart of it. Read whichever matches the track you are on, and the other one when you are curious.
Which interface
The two tracks are the desktop app and the terminal. There is a third common way in — the VS Code extension, and the same extension in VS Code forks such as Cursor — and it is close enough to the desktop track to follow it directly: a panel, diffs you review, permission prompts you click, and the same slash commands. Module 1 has the install steps and the handful of places the wording differs.
What this edition adds
This is a revised edition of the course. One thing was added that the original did not have: a checkpoints page carrying the project at the end of module 2 and the end of module 3, an already-broken copy for the debugging module, and the two hook scripts from module 10 — kept on the checkpoints page, where a member can take one at any point in the course.
The reason is a specific failure this course could otherwise not recover from. Every module names its starting state as a tag, and modules 9 and 12 read those tags. That is good structure right up to the moment a learner's project drifts, at which point the course has nowhere to put them except back at module 2. The archives are the way back, and they carry no git history on purpose: the four commands that give them one are on the page, because typing them is the habit the course is trying to build.
Smaller additions: a typed filter on the module list, a print stylesheet that drops the navigation and keeps the lesson, and a section in module 7 on the order permission decisions are actually evaluated in — hooks, then deny, then the mode, then allow, then you — with the file precedence that explains most rules that look right and do nothing.
What was deliberately not changed: the module order, the two-track structure, the exercises, and the practice of writing the guarantee you can actually make. Adding a rescue path is not the same as removing the work, and a downloaded blog teaches nobody anything.
Sourcing and dates
The technical modules were written against the official documentation rather than from memory, because plausible-sounding detail is exactly how confident errors get made. Each technical claim that could drift links to the documentation page it was checked against, and the footer carries the date of that check.
What has not been done, and should be before you rely on this with a group: a timed run-through by beginners on both macOS and Windows, and a screen-reader pass. The interface descriptions here are written from the documentation, not from annotated screenshots.