How to learn Claude Code
in a fortnight.
Most people learn Claude Code by pointing it at a fresh project and asking it to build something. That is the slowest route available. The order below is faster, and it costs you less usage on the way.
Nobody gets good at this by writing better prompts. You get good at it by scoping work tightly enough that the answer is checkable, and by reading what comes back closely enough to catch what is wrong with it. The fortnight below builds the second skill first, because the first one is worth very little without it.
Start on a repo you already know
A greenfield project is the worst training ground, because you cannot tell correct output from plausible output. On code you maintain, a wrong abstraction is obvious in about ten seconds. On code you have never read, you accept it, and the only thing you have learned is that the tool is quick. Pick a repo with a test suite and at least one module you have personally debugged late at night, and point it at that module first.
Change nothing for the first three days
Ask what breaks if you delete a function you already know is load-bearing. Ask it to explain the one module everybody on the team avoids. You are checking its answers against things you already know, and the wrong answers are the useful ones, because they show you the shape of what it misses. Read-only is also the cheapest place to be wrong: nothing merges, nothing needs reverting.
Put your constraints in CLAUDE.md on day four
Claude Code reads a file called CLAUDE.md at the root of your repo at the start of every session, and `/init` will draft one by reading your project. Anthropic’s guidance is to keep it under 200 lines, because longer files consume context and reduce how reliably the instructions get followed. Put in the exact test command, the directories that are off limits, and the conventions a new starter would get wrong. Leave out a description of what your product does. The habit that keeps the file honest: the second time you correct the same thing, that correction becomes a line in it. Getting that file right for a specific codebase is most of what a Claude Code coaching session covers.
Know where your usage goes before you hit the wall
Usage limits are shared across Claude and Claude Code, they reset on a rolling five-hour window, and paid plans carry weekly limits on top (accurate in March 2026, and Anthropic revises these, so check before you build a schedule around them). Beginners burn the allowance faster, because practice means retrying. Run your learning sessions at the start of a window rather than after a heavy afternoon of chat.
Week two: hand over the loop, then read every diff
Let it run the test suite and fix its own failures. That means deciding once what it may run unattended: the test command yes, the formatter yes, anything that writes to a remote no. Set those permissions at the start of the week, because approving actions one at a time is how you end up rubber-stamping by Wednesday. Read every diff anyway. All of them. Your reviewing habit decides how far you can safely let it run in month two.
Progress is not how fast you feel. In July 2025 METR ran a randomised controlled trial with experienced open-source developers working on their own real repositories, the same setup recommended in step one. They were measured 19% slower with AI assistance, and afterwards still believed they had been around 20% faster. Nobody in that trial was bad at their job. They were judging the work by how it felt. You are ready to move faster when you can reject the tool’s output and say precisely why.
Things people
usually ask.
Two weeks of regular use gets most developers to the point where they can scope a task properly and review the result honestly. Speed arrives after that. The people who stay slow usually skipped the read-only phase and never built a feel for where the tool is weak.
You need to be able to read a diff and say why it is wrong. That is the real gate. If you do not code day to day but want to understand what your team could do with it, Claude Code for non-developers is a better starting point.
Yes, if someone has already made the mistakes for you. Most of the two weeks goes on finding where the tool is weak on your particular codebase, and that is the part a specialist compresses into a session. The read-only phase still earns its place; the trial and error around it does not.