Learn Claude Code well enough to ship something real by the weekend

Your first 10 minutes in Claude Code

Open a terminal, go to a project you actually work in, and type claude. That's the whole install-and-launch story once you've got the CLI set up. No dashboard, no browser tab, no new window to manage. You're talking to Claude right where your code already lives.

The first thing worth doing is nothing fancy. Ask it something you already know the answer to, so you can judge how it responds. Try:

> what does this project do, and where's the entry point?

Claude will read your files (a README, a package.json, whatever's there) and answer. Watch how it works. It doesn't guess from the folder name. It opens files, quotes real lines back to you, and tells you where it looked. That habit of grounding answers in your actual code is the thing that makes it useful instead of a fancy autocomplete.

A few things new users trip on in the first session. Claude asks permission before it edits a file or runs a command, so if it seems to pause and wait, it's waiting on you to approve. That's by design and you can loosen it later once you trust it. Also, everything is a conversation. You don't need perfect phrasing. "actually, do it in the utils file instead" works fine as a follow-up.

Good first asks that pay off immediately:

- "explain the auth flow in this repo, start at the login route"

- "there's a bug where the total shows NaN, help me find it"

- "write a short test for the function in cart.js"

One piece of advice that saves people a lot of frustration: start small and specific. "Fix the checkout page" is too big for a first task and you won't know if it did well. "The discount code field doesn't clear after submit, fix that" gives you something you can verify in ten seconds. Build trust with small wins, then hand over bigger jobs. By minute ten you'll have a feel for the rhythm, and that rhythm is most of the skill.

The read-edit-verify loop

This is the single most important habit to internalize, and it's the reason Claude Code produces changes you can actually trust instead of hopeful guesses.

The loop has three beats. Claude reads the relevant code first. Then it makes an edit. Then it verifies the edit did what it claimed. Skip any beat and quality drops off a cliff. The magic isn't that Claude is smart in the abstract, it's that it keeps checking its work against reality.

Here's why reading first matters so much. If you ask "rename getUser to fetchUser everywhere," a tool that edits blindly will miss the call in a test file or break an import. Claude opens the files, finds every reference, and changes them together. You'll often see it grep the codebase before touching anything. That's not it being slow, that's it refusing to guess.

The verify step is where beginners under-invest, so lean into it. After a change, a good prompt is simply:

> run the tests and show me what passed

or for something visual:

> start the dev server and confirm the login page still loads without console errors

When Claude runs the thing and reads the output, one of two good outcomes happens. It works and you both saw proof. Or it broke, Claude sees the stack trace, and fixes it in the same turn without you playing messenger. Compare that to accepting a diff, pushing it, and finding out from a failing CI run twenty minutes later.

A practical way to force the loop: end your requests with the check baked in. Instead of "add input validation to the signup form," say "add input validation to the signup form, then submit an empty form and confirm you see the error messages." Now Claude can't call it done until it's actually done.

One caution. If Claude says a fix works but never ran anything, treat that as unverified. Ask it to prove it. "Did you actually run that?" is a completely fair question, and a good session answers it with real output, not reassurance.

Letting Claude run commands without fear

New users often keep Claude on a tight leash, approving every single command by hand, and then wonder why the whole thing feels tedious. The fix isn't to blindly allow everything. It's to understand what's safe to automate and what genuinely deserves a second look.

By default, Claude asks before running any shell command. That prompt is your safety valve. Read what it wants to run. A command like npm test or git status or ls src/ is read-only or trivially reversible, and you can approve those all day. A command that deletes files, force-pushes, drops a database, or touches production is the kind you actually want to pause on. The permission prompt exists so you can tell those two categories apart at a glance.

Once you notice you're approving the same harmless commands over and over, allowlist them. You can tell Claude to remember that a command is fine, or add it to your project settings so it stops asking. A typical starter allowlist for a JS project might cover:

npm testnpm run lintgit statusgit diff

Now the boring stuff flows and you only get interrupted for things that matter.

The deeper point is about trust calibration, not bravery. You're not being asked to hope for the best. You're being handed a preview of every command before it runs, which is more visibility than you get when a human teammate runs things on their own machine. Watch a few sessions closely, see that Claude explains what it's about to do and why, and your comfort grows honestly.

Two guardrails keep this safe. First, work in a git repo. If a change goes sideways, git diff shows you exactly what happened and you can revert. Claude leans on git heavily for this reason. Second, keep the genuinely dangerous stuff behind a manual approval, always. Deploys, destructive database commands, anything hitting live systems: read those in full before you hit yes, every time. That's not paranoia, that's the one place where a wrong command actually costs you. Everywhere else, let it run.

Adding your first MCP server

Out of the box, Claude Code can read and write files and run commands. MCP servers are how you give it new abilities beyond that: talking to your database, your GitHub, your issue tracker, a browser, whatever. MCP (Model Context Protocol) is just the standard plug that lets Claude connect to those tools. Think of it as adding an app to a phone that already handles calls and texts fine on its own.

A concrete first example that pays off fast is a filesystem or a GitHub server, but let's use GitHub since most people have an account. Adding a server is one command:

claude mcp add github

Depending on the server, you'll be asked for a token or an API key so Claude can authenticate as you. Once it's connected, you can ask things you couldn't before:

> list the open PRs on this repo and summarize what each one changes

Now Claude isn't guessing from local branches, it's pulling the real state from GitHub and reading it back to you.

To see what you've connected, run claude mcp list. That shows every server and whether it's live. If a tool isn't showing up, that list is the first place to check, usually it's an auth issue or the server didn't start.

A couple of things worth knowing early. Each server exposes a set of specific tools, not a vague "do anything" power. A database server might give Claude the ability to run a read query but not drop a table, depending on how it's configured. That scoping is a feature. You decide how much reach each connection has, and you can start read-only and loosen up later.

Don't add ten servers on day one. Each one adds surface area and a bit of noise, and you'll do better learning what one does before stacking more. Pick the tool you reach for most (your database, your project tracker, your cloud provider) and connect just that. Use it for a few real tasks. When you hit a wall where Claude says it can't reach something you need, that's your signal to add the next server. Grow the toolkit to fit the work, not the other way around.