Claude Code

What It Is

Claude Code is an agentic coding tool that reads your codebase, edits files, runs commands, and integrates with your dev tooling. Instead of you copying snippets into a chat box, it operates an agentic loop directly in your project: it gathers context, takes an action, and verifies the result, repeating until the task is done. That loop is powered by a model plus a set of built-in tools — file read/edit/create, glob and regex search, shell and git execution, web search and fetch, and code intelligence like type errors, definitions, and references.

The concrete thing you will touch in this loop is the terminal CLI. You run claude inside a project directory and drive it through a real change. The same engine also runs in VS Code and JetBrains, a desktop app, the web at claude.ai/code, Slack, and CI/CD — and because every surface shares the same configuration (CLAUDE.md, settings, MCP servers), the workflow muscle you build in the terminal transfers everywhere else.

Why It Matters

You evaluate tools before you adopt them, so the question is not "can it autocomplete" but "can it run a controlled, verifiable change against real code without becoming a liability." Claude Code is built around exactly that posture: permission modes gate what it can do, plan mode lets it explore and propose without editing source, and every file edit is checkpointed so a bad change is one keystroke from reverted. That is the part worth testing in 40 minutes.

It also lands directly on the workflows you already care about. The non-interactive mode (claude -p with JSON output and scoped tool permissions) turns the agent into a scriptable step for CI, pre-commit hooks, and fan-out jobs over many files. MCP servers connect it to databases, issue trackers, and other systems, and subagents run research in their own context and report back. This first pass is about feeling whether the core loop is trustworthy enough to be worth wiring into any of that.

Guided First Play

By the end of this play you will have run one full Explore → Plan → Implement → Verify cycle on real code, watched the agent close the loop against a check it can read itself, and reverted a change with a checkpoint. That is enough evidence to judge whether the tool earns a place in your workflow.

Get into a session

Install the native CLI, then start it inside a project. On macOS or Linux either of these works; the curl install auto-updates in the background, the Homebrew cask does not.

# Install (pick one)
curl -fsSL https://claude.ai/install.sh | bash
# or: brew install --cask claude-code

# Use a small, real project. If you don't have one handy:
mkdir scout-claude-code && cd scout-claude-code && git init

# Start an interactive session (first run opens a browser login)
claude

The first run prompts a browser login; you can re-auth later with /login. Access requires a Claude subscription (Pro, Max, Team, or Enterprise), a Claude Console account with prepaid API credits, or a supported cloud provider. Once you are at the prompt, type /help to see session commands and / to list available commands and skills.

Explore and plan, read-only

Press Shift+Tab until the indicator shows Plan mode. In this mode the agent can read and reason but will not edit source, which makes it the safe way to point it at unfamiliar code. Ask for understanding first, then a plan.

Explore this project and summarize how it's structured and what it does.
Then propose a detailed, step-by-step plan to add a small feature:
<one concrete change, e.g. "a function that validates an email string, with tests">.
List the files you'd touch and how you'd verify it. Don't edit anything yet.

What just changed: the agent gathered context (reading files, searching) and produced a plan without modifying anything. This is the highest-value habit for multi-file or uncertain changes — you review the approach before any code moves. For a one-line diff you would skip plan mode; here it is the point. If the plan looks reasonable, you have already learned that it can navigate real code.

Implement against a check it can read

Now the focused variation that separates a demo from real use: give the agent a check that returns pass or fail, and make running it part of the same request. Cycle out of plan mode (Shift+Tab back to Default or Auto-accept edits) and ask it to implement and prove the result.

Implement the plan. Then run the tests and show me the output.
If anything fails, fix it and re-run until the suite passes.
Show the exact command you ran and its result — don't just tell me it passed.

Why this matters: a model asserting "done" is cheap; a model that runs a test suite, build, or linter and pastes the pass/fail output is giving you evidence. A check it can read — a test exit code, a fixture diff, a screenshot comparison — is the single highest-leverage thing you can hand it, because it lets the agent iterate toward a real target instead of toward your approval. This is also the seam where it plugs into CI later.

Verify, then undo

Confirm the result yourself, then test the safety net. Every file edit is checkpointed before the change, independent of git.

• Read the test output the agent showed and re-run the check in your own shell to confirm it is real, not narrated.
• Press Esc Esc (or use /rewind) to revert the edits from a checkpoint, and notice that this is separate from git history.
• Run /context to see how much of the context window the session consumed; run /clear before you start any unrelated task.

You now have direct evidence on four things that decide adoption: whether it understood your code, whether the plan was sound, whether it can verify its own work against a real check, and whether reverting is genuinely low-risk.

Your Next Move

Did that one loop feel trustworthy enough to keep using — or did it stumble on your real code? Pick the outcome that matches what you saw.

Go Deeper would spend two hours on the workflow mechanics that make it reliable at scale: a pruned CLAUDE.md via /init, context management with /compact and subagents, allowlisting commands in settings, and enforcing checks with hooks and /code-review. Project would point that toward something concrete for your work — for example a claude -p step in CI or a fan-out script that runs the agent across many files non-interactively.

Sources

This loop is grounded in the official Claude Code documentation — the overview, the quickstart (install, login, and session commands), how it works (the agentic loop, tools, models, permission modes, and checkpoints), and the best-practices guide (the Explore-Plan-Implement-Verify workflow and giving the agent a verifiable check). Full links are attached as provenance. The live CLI may evolve; if a command or mode indicator differs from what you see, trust the in-session /help and the quickstart fallback above.