Most guides to AI coding tools teach you to type prompts. That is the wrong unit of work. The people getting the most out of Claude Code have stopped thinking of it as an assistant that completes their lines and started thinking of it as a team of engineering agents they manage. Your job shifts from writing code to something a good technical lead already knows how to do: state the intent clearly, set the constraints, split the work, and review what comes back.
That reframing is not marketing. It is the design. Anthropic builds Claude Code to be deliberately low-level and unopinionated — close to the raw model, few guardrails, composable with everything else you already use. The tool does not impose a workflow; it gives you primitives and expects you to assemble the workflow that fits. That is why it runs in a terminal, an IDE, a desktop app, a browser, and a phone, all on the same underlying engine — your instructions, settings, and connected tools follow you across all of them.
This guide runs from zero to hero in two parts. Part one takes you from nothing to a live, shipped project without installing anything — start from GitHub in the cloud, plan the work, deploy it, and do the whole loop from a phone if you want. Part two is the advanced course for people who write code for a living: the handful of features that actually separate a novice from someone running a fleet of agents. We are biased throughout toward the small number of moves that return the most — the twenty percent that does eighty percent of the work.
The mental model: you are the lead, not the typist
Hold one picture in your head for the rest of this guide. A capable senior agent takes your task, plans it, and does the work. When the task is big, it does not try to hold everything in one head — it delegates. A lead agent breaks the work into parts, hands each part to a teammate agent that works in its own isolated context, and merges the results back together. Some of those agents run in parallel. Some run while you are asleep. You sit above the whole thing, specifying and reviewing.
Everything below is either a way to give that team better instructions, a way to add a specialist to the team, or a way to let the team run without you in the room. Keep asking one question: am I doing work a well-briefed agent could do, or am I doing the briefing and the reviewing? The second is the job.
Part one — zero to hero, no setup required
You do not need a terminal, a local checkout, or a development environment to start. You need a GitHub account and a Claude subscription. Everything in part one can be done from a browser or the Claude mobile app — which is the point: you can build on the go.
Start from GitHub, in the cloud. Claude Code on the web runs at claude.ai/code on Anthropic-managed infrastructure. You connect your GitHub account, pick a repository, and describe a task in plain language. Claude clones the repo into an isolated cloud environment, does the work, and opens a pull request for you to review. Nothing runs on your machine. This is currently a research preview available to Pro, Max, and Team users, and to Enterprise users with the right seats. The web quickstart walks through connecting GitHub and submitting a first task; the cloud environment guide covers how repositories, network access, and setup scripts are configured.
Sessions are not tied to a device. A session you kick off in the browser keeps
running if you close the tab, and you can watch and steer it from the Claude iOS app. Start a task
at your desk, approve a step from your phone on the train, and pull the same session down into your
terminal later with claude --teleport once you are back at a keyboard. This is the
build-on-the-go loop: the work lives in the cloud, and you check in on it from wherever you are.
Plan before you build. The single highest-leverage habit for a beginner is to make Claude plan first. In plan mode, Claude explores the codebase and proposes what it intends to do without editing anything. You read the plan, correct the parts it got wrong, and only then let it execute. This is where you catch a misunderstanding before it becomes twenty files of wrong code. Treat the plan as the cheap place to be wrong. Describe the outcome you want, not the implementation — "add a contact form that emails submissions to us and blocks spam," not a list of functions — and let the plan surface the decisions you actually need to make.
Ship it live. Once the code is in a GitHub repository, getting it on the internet is mostly a matter of picking a host and connecting the repo once. The advice here is short on purpose: pick one and stop shopping.
For most sites and apps, a Git-driven host is the no-brainer. Platforms like Vercel, Netlify, and Cloudflare Pages connect to your GitHub repo and redeploy automatically on every push — you never touch a server. They suit static sites and front-end frameworks and have generous free tiers. If your project is a full back-end service — an API, a worker, something with a database — Railway and Fly.io follow the same push-to-deploy pattern for containers and long-running processes. If you want the simplest possible thing for a static site or a set of docs, GitHub Pages publishes straight from the repo you are already in.
All of these can also be driven from the command line (vercel, netlify deploy,
flyctl deploy) or from GitHub Actions, which matters later when you want an agent to
deploy for you. For now, the beginner move is the Git integration: connect the repo, and shipping
becomes "merge the pull request." Ask Claude to set up the deployment configuration and the Action
as part of the same task that builds the feature.
Or just run it locally. If you are only trying to see something work on your own
machine, you rarely need a hosting platform at all. A static page needs nothing more than
python -m http.server or npx http-server in the project folder. A
framework project has a dev server built in — npm run dev and open the URL it prints.
Claude can start these for you and check the result. Local first, deploy when it is worth sharing.
The simple toolkit for this stage. You can go a very long way with five moves and nothing else: describe tasks in plain language, always plan before executing, review the pull request instead of reading every line, approve steps from your phone, and let a Git-connected host handle deployment. That is the whole beginner loop. None of it requires you to write code. If you stop reading here, you can still build and ship real things.
Part two — the advanced course: running the team
Everything above treats Claude as one capable agent. The rest of the value comes from turning it into a team you have configured deliberately — and from letting that team run without you. Anthropic's own framing is that the differentiators are not flashy product features but a small set of powerful, general primitives: the context you give the agent, the specialists you add, the external tools you connect, the automation you wire in, and the ability to run many agents at once. We will take them in order of leverage.
1. Context is the highest-leverage lever there is. The most important thing you
will write is not code — it is the instructions. A CLAUDE.md file at the root of your
repository is read at the start of every session and quietly shapes everything the agent does:
your conventions, architecture decisions, the libraries you prefer, the commands to build and test,
the checks to run before committing. A tight, specific CLAUDE.md is the difference
between an agent that guesses and one that already knows how your project works. Keep it short and
concrete — "use two-space indentation, run npm test before every commit, never edit
files under vendor/" beats a page of vague aspiration, because a shorter file is
followed more reliably and costs less of the context window. You can scope instructions at the user
level (all your projects), the project level (shared with your team through Git), and the local
level (personal, ignored by Git). Claude also builds its own
memory as it works, carrying learnings like
build commands and debugging insights across sessions. Invest here before anywhere else; it pays
back on every task that follows.
2. Package your repeatable work as skills. The workflows you run again and again —
reviewing a pull request, cutting a release, auditing dependencies — should not be re-typed each
time. Skills let you package a repeatable
workflow behind a name you invoke as a slash command, such as /review-pr or
/deploy-staging, and share it with your team through the repository. A skill is a small
instruction file that Claude loads on demand, so it keeps your standing context lean while still
giving you one-word access to your best-honed procedures. Every recurring task you turn into a skill
is a piece of judgment you only have to encode once.
3. Add specialists, and run them in parallel — the team, made real. This is the section that pays off the framing. A subagent is a specialist you delegate to: a researcher, a code reviewer, a debugger. It runs in its own context window, with its own tools and permissions, and returns only a summary to the main session. Two things make this powerful. First, isolation: the noisy work — reading the whole codebase, sifting logs, exploring dead ends — happens in the subagent and never clutters your main conversation, which keeps the lead agent sharp over long sessions. Second, specialisation plus constraint: a review agent that can only read is safer and more focused than one general agent trying to do everything. Give each agent a narrow job and the minimum tools to do it, and reliability goes up.
From there it becomes genuine parallelism. A lead agent can spawn several subagents that work on different parts of a task at the same time, then merge the results — twenty files refactored at once instead of one after another. When you want to run several full sessions side by side and watch them from one screen, background agents let you do exactly that: independent agents, each in its own branch, all visible at a glance, any one of which you can drop into for hands-on work. This is what "managing a team" stops being a metaphor and starts being your actual screen.
4. Connect your tools with MCP. An agent is only as capable as the things it can reach. The Model Context Protocol is an open standard for connecting Claude to external systems — your database, your issue tracker, your design files, your error monitoring, a browser it can drive. Add an MCP server once and its capabilities become tools the agent can use: query Postgres directly, read and update tickets in Jira, pull context from Slack, drive a real browser with Playwright, look up an exception in Sentry. The MCP quickstart connects your first server end to end. Two notes worth internalising: MCP is a standard, not a plugin store, so you can point Claude at your own internal tooling the same way you point it at a public server; and each server you connect consumes some of the context budget, so add the ones that earn their place rather than every server you can find.
5. Make behaviour deterministic with hooks. Some things should happen every time,
not when the model remembers to. Hooks run your
own shell commands at fixed points in the agent's lifecycle — before or after a tool runs, when a
session starts, after a file is edited. Use them to auto-format after every edit, run the linter
before a commit, block an action you never want taken, or notify a channel when a long job
finishes. Where CLAUDE.md is guidance the model follows, a hook is a rule the system
enforces. The combination — good instructions plus a few hard guardrails — is how you get output
you can trust without watching every keystroke.
6. Let the team run without you: loops, routines, and headless mode. The endgame is
work that happens while you are doing something else. There are three tiers.
/loop repeats a prompt
within a running session for quick polling — useful for "keep checking until the build is green."
Routines run on Anthropic-managed
infrastructure on a schedule or a trigger, so they keep running even when your computer is off —
review pull requests every morning, analyse overnight CI failures, audit dependencies weekly, or
fire on a GitHub event. You create them from the web, the desktop app, or by running
/schedule in the CLI. And headless mode —
claude -p — lets you run Claude
non-interactively inside any script or pipeline, which is how it composes with the rest of your
toolchain:
tail -200 app.log | claude -p "Slack me if you see any anomalies"
That one line captures the philosophy: Claude Code follows the Unix tradition, so it pipes, scripts, and chains like any other command-line tool. The same mechanism powers automated code review and issue triage through GitHub Actions or GitLab CI.
7. Build your own agents with the SDK. When a workflow outgrows the CLI, the Claude Agent SDK gives you the same agentic loop and the same tools — reading, editing, running commands, subagents, MCP, hooks — as a library you program in Python or TypeScript. This is how a one-off prompt becomes a durable product: a bug-fix bot wired into your CI, a code reviewer that runs on every pull request, an internal agent embedded in your own application, with full control over orchestration, tool access, and permissions. The CLI is for doing the work; the SDK is for productising it.
Steal these
Enough theory. Here are four artifacts you can paste into a repository today, each one a concrete version of a lever above. They are deliberately small — the point is the shape, not the length. Adapt the specifics to your stack.
A project CLAUDE.md — the context every session reads. Lives at
your repository root.
CLAUDE.md
# Project: acme-web
## Stack
- Next.js (App Router) + TypeScript + Tailwind. Postgres via Prisma.
## Conventions
- Two-space indent. Named exports only, no default exports.
- Server components by default; add "use client" only when you need it.
- Prefer editing an existing component over creating a new one.
## Commands
- Install: npm ci
- Dev: npm run dev
- Test: npm test # run before every commit
- Lint + format: npm run lint && npm run format
## Guardrails
- Never hand-edit anything under db/migrations/.
- Never commit secrets. Config comes from .env (see .env.example).A read-only reviewer subagent — a specialist you delegate to,
scoped to the minimum tools. Lives at .claude/agents/reviewer.md.
.claude/agents/reviewer.md
---
name: reviewer
description: Reviews a diff for correctness and security. Read-only.
tools: Read, Grep, Glob
model: sonnet
---
You are a senior reviewer. Given a diff, surface only real defects:
correctness bugs, security holes, missing error handling. Skip style.
Return findings most-severe first, each with file:line and a one-line fix.
If you find nothing, say so — never invent issues.A hook that formats every file the moment it is edited — a
rule the system enforces, not guidance the model may forget. Lives in
.claude/settings.json.
.claude/settings.json
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{ "type": "command", "command": "npm run format --silent" }
]
}
]
}
}A routine — an agent that runs on a schedule while your
computer is off. Create it from the web, the desktop app, or /schedule.
Routine — weekday PR triage · 08:00
Every weekday at 08:00, for each open pull request:
- summarise what changed and flag anything risky,
- run the test suite and post failures as review comments,
- label the ones that are ready to merge.
Do not merge anything yourself.And the one-liner that captures the whole philosophy — Claude Code piping like any other command-line tool:
Headless, in a pipe
tail -200 app.log | claude -p "Slack me if you see any anomalies"What actually makes it different
Strip away the feature list and the differentiators Anthropic keeps returning to are consistent. Claude Code is unopinionated and close to the raw model — it hands you primitives instead of a prescribed workflow, and trusts you to compose something better than any default it could ship. It is terminal-native and composable, so it lives inside the toolchain you already have rather than a walled-off app. It is model-forward: the bet is that the general model keeps getting more capable, so the tool stays thin and lets that capability through instead of wrapping it in product features that would only get in the way. And the leverage comes from context and orchestration — the instructions you write and the team of agents you run — far more than from any single clever prompt. The tool is intentionally simple so that you can be sophisticated.
Biggest bang for your buck
If you do only five things, do these, in this order:
One. Work in the cloud from GitHub and always plan before you execute. This alone gets you shipping without a local setup and catches most mistakes while they are still cheap.
Two. Write a tight, specific CLAUDE.md. It is the highest return on
the least effort in the entire tool, and it compounds across every session.
Three. Use subagents and run them in parallel. The moment you stop working one task at a time is the moment "managing a team" becomes literal.
Four. Add one MCP server and one hook. Connect the tool your work actually depends on, and enforce the one rule you never want broken. Two small additions, outsized effect.
Five. Automate one recurring job with a routine. Pick the task you do every week and hand it to an agent that runs while your computer is off.
The through-line is the same one we return to often: AI has collapsed the cost of execution. What it has not collapsed is judgment — knowing what to build, what to constrain, what to check, and what to ignore. Claude Code rewards the people who bring that judgment and delegate the rest. Stop typing the work. Start running the team.