Claude Code Tutorial: From Zero to First Build

Claude Code has been my daily driver for a long time now. It maintains this website, writes most of my Laravel code, runs my SEO tooling, and powers the agent work I ship for clients. So this is not a tutorial written from a weekend of testing. It is the path I would hand a colleague on day one, and it is built around the one thing most tutorials get wrong: the skill you are learning is not prompting. It is writing down how your project works so an agent can follow it. Install takes five minutes. The setup that makes Claude Code actually useful takes an afternoon, and I will show you exactly what mine looks like.

Installing and your first session

You need Node.js 18 or later. Then:

npm install -g @anthropic-ai/claude-code

Open a terminal in a project folder (an existing project is better than an empty one, for reasons that will become obvious) and run:

claude

You will authenticate with your Anthropic account, and then you are in a REPL sitting inside your codebase. Ask it something real about your own project first, not a toy prompt:

Where is user authentication handled in this codebase, and what would
I need to touch to add a "remember me" option?

Watch what it does. It greps, it reads files, it builds a picture, then it answers with file paths. That loop, search then read then act then verify, is the whole product. Everything else in this tutorial is about steering that loop.

The mental model: you hired a fast contractor with no context

The single most useful frame I have found after months of daily use: Claude Code behaves like a very fast, very capable contractor who joined your team this morning. Fast and capable is the model's job. "Joined this morning" is your problem to fix, and you fix it the same way you would for a human: an onboarding doc.

That doc is CLAUDE.md. Run /init inside your project and Claude Code will generate a starter one by reading your codebase. Then edit it, because the generated version knows your file layout but not your scars.

Here is the kind of thing that is in the real CLAUDE.md for this website:

• composer test runs static analysis, not PHPUnit. Use php artisan test. (A human would trip on this once; without the note, the agent trips on it every session.)
• Always eager load relationships to prevent N+1 queries.
• Use PHPUnit, never Pest. Use Form Request classes, not inline validation.
• Check sibling files for existing patterns before implementing anything new.

None of that is prompting technique. It is project knowledge, and writing it down once fixes every future session. When Claude Code does something wrong, my first question is never "how do I prompt better," it is "which convention did I fail to write down." My global config adds cross-project rules too, like "follow plan, implement, verify" and "never commit secrets," which apply to every repo on my machine.

Plan mode: the feature beginners skip and experts live in

Press Shift+Tab in a session and you cycle into plan mode. In plan mode, Claude Code reads and researches but does not edit anything until you approve a written plan.

For anything beyond a one-line fix, I start in plan mode. The plan is where you catch the misunderstanding early: wrong file, wrong approach, an abstraction you do not want. Rejecting a plan costs seconds. Reverting a confident, wrong, twelve-file change costs your afternoon and some trust.

The progression I see in everyone who sticks with the tool goes roughly: chat with it, then let it edit, then plan first, then delegate whole features, then run custom slash commands and skills, then wire it into automation. You do not need the later stages this week. You do need plan mode today.

The verify loop is what separates demos from shipped code

The demos you have seen ("working game in four minutes") are real, but they end where real work begins: proving the change is correct. My rule, written into my own config as a hard requirement, is that verification is mandatory. Concretely, on this Laravel project every change ends with:

vendor/bin/pint          # formatting
php artisan test         # the relevant tests

And I do not run those by hand. The repo has a git pre-commit hook that runs the formatter on staged PHP files and blocks the commit if it fails. Claude Code hits that wall, reads the error, fixes the formatting, and commits cleanly, without me in the loop. That is the pattern to steal regardless of your stack: make your quality gates executable, and the agent will hold itself to them. Tell it how to verify ("run npm test, then load the page and check the console") and it will actually do it; leave verification implicit and you will ship whatever compiled.

Your first real project, step by step

Here is the sequence I would run in week one, on a project you actually care about:

1. Session 1, read-only. Ask architecture questions. Ask it to explain the weirdest file in the repo. You are calibrating how well it understands your code, and you cannot break anything.
2. Session 2, /init and edit. Generate CLAUDE.md, then add your build command, test command, and three conventions you care about. This is the highest-leverage 30 minutes in this entire tutorial.
3. Session 3, a small real fix in plan mode. Pick a genuine bug. Approve the plan, let it work, make it verify.
4. Session 4, a feature with tests. Ask for the test first if that is your style. Reject the plan at least once so you learn how cheap course-correcting is.
5. Later: extend it. When you notice yourself giving the same instructions repeatedly, that is a skill waiting to be written. I keep 35 of them for my own workflows, and what I learned building those is its own post. My honest advice for beginners is also in there: do not install a pile of community add-ons on day one. My current plugin and skill stack came from deleting more than I kept.

What to expect versus what the demos show

Some honest calibration from daily use:

• It is genuinely better on codebases with conventions. A tidy Laravel or Next.js app with tests gives it rails. A snowflake codebase with no tests gives it nothing to check against, and quality drops accordingly.
• It will occasionally be confidently wrong. The mitigation is structural, not hopeful: plan mode, tests, small commits you can revert.
• Context is finite. Long sessions drift. When a session starts feeling muddy, finish the current task, then start fresh. CLAUDE.md is what makes fresh sessions cheap, because the onboarding is already written.
• Permissions are a feature. Early on, keep the approval prompts for file edits and commands. Loosen them per-project as trust builds, not globally on day one.

Once the basics feel boring, the same harness scales a long way up: I have used it to build a security scanner agent for OWASP audits, and the Claude Agent SDK is literally this tool packaged as a library for building your own agents. That is the point of learning the fundamentals properly: they are the same fundamentals all the way up.

Where to go from here

Your next hour is better spent writing your project's CLAUDE.md than reading another tutorial, mine included. After that, the ordered path — first session, plan mode, skills, agent workflows — runs as a course track in my AI School, built from the same setup this site runs on rather than from demo projects. Bring a real codebase to it; that is where the tool earns its keep.