The Claude Code Guide I Give My 600 Students

A Claude Code guide that opens with install commands is answering the wrong question. Claude Code is an agent that lives in your terminal, reads your whole repository, writes files, runs your tests and opens pull requests. Installing it takes two minutes. Getting real work out of it takes about three weeks, and the order you learn it in decides whether you are still using it next month. Here is the order that worked for me and works for the students I mentor: one small task end to end, then a CLAUDE.md file so it stops guessing, then whole slices instead of single functions, then verification, which quietly becomes most of the job. I build and maintain live SaaS products this way, solo.

Start With a Task You Already Know How to Do

Your first session should be boring on purpose. Pick something you could write yourself in twenty minutes: rename a badly named function across the codebase, add a loading state to one screen, write the tests that are missing from one module. You need a task where you can look at the diff and know immediately whether it is right. That is the entire point of the first week. Most of the 600+ students I mentor at nCode start with something ambitious instead, get back a wall of plausible code, and have no way to judge it. Then they decide the tool does not work. The tool works. They removed their own ability to check it.

Read every line it produces that first week, including the boring ones. You are not doing code review, you are learning how this specific agent thinks: where it over-builds, when it invents a helper you already have, which parts of your repo it consistently misreads. That map is worth more than any prompt template you will find online, because it tells you exactly where to aim your attention later, when you stop reading everything.

CLAUDE.md Is the Difference Between a Demo and a Tool

The highest-return hour of your first week is writing a CLAUDE.md file in the root of your repository. It is a plain markdown file the agent reads before every session. Without it you re-explain your stack in every conversation and it keeps reinventing patterns you already have. With it, the agent shows up knowing the house rules. Mine are short and specific, because a long file gets skimmed by humans and agents alike. Five things belong in it:

• The stack in one line, with versions: Next.js App Router, Supabase, Tailwind, TypeScript in strict mode.
• The commands that prove the work is done: the test command, the type check, the lint, the build. Exact names, not descriptions.
• What already exists in the code: the auth helper, the date formatter, the API client. This alone removes half the duplicate code.
• The rules you are tired of repeating: no new dependency without asking, no comments restating what the line already says, server and client code stay separate.
• What is off limits: production data, migrations that drop columns, anything touching billing before a human reads it.

Hand It a Slice, Not a Chore

Week two is where most people stall. They treat the agent like autocomplete: one function, wait, review, next function. In that loop you are the bottleneck and the agent is idle most of the time. What changed my output was handing it a full vertical slice instead: the migration, the API route, the component and the tests, as one task with a clear definition of done. It works because the agent holds context across those files far better than it holds your intent across three separate conversations. Write the definition of done first, in your own words, before you write the prompt. If you cannot say what finished looks like in two sentences, the task is not ready for an agent, and it was never ready for you either.

Verification Is the Real Work Now

When the agent writes most of the code, your job stops being typing and starts being deciding what is true. I do not merge anything I have not watched run. Not tests passing according to a summary, actually running: the page loading, the payment clearing on a test card, the guarantee document rendering in Hebrew with the right name on it. Platforms with 10,000+ paying users and members do not forgive code that merely looks correct. The practical version of this is boring and it works: make the agent run the suite itself and show you the raw output, read the full diff as if a stranger wrote it, and keep one command that proves the feature end to end. If you change one habit from this guide, change this one.

A Hebrew Product Needs One Extra Rule

Most of what I build is Hebrew-first, and these agents were trained on an English-first web. Say nothing and you get ml-4 instead of ms-4, a date that reads backwards, and an input that jumps to the wrong side the moment someone types a Latin character. So the RTL rules live in CLAUDE.md, not in my head: logical properties only, dir on the html element, and every Hebrew string gets read by a person before it ships. Building the rental guarantee flow for Arvuyot Yashir, that one section of the file saved more time than any clever prompt, because the same class of mistake simply stopped coming back.

So, compressed: one small task you can judge, CLAUDE.md on day one, full slices by week two, verification forever. Skip the first step and you will never trust it. Skip the second and you will repeat yourself daily. Skip the last one and you will ship something that looked right in a diff and broke in front of a paying customer. Open your repo today, pick the most annoying small task in it, and read every line that comes back.