Claude Code doesn’t look like much at first. You install a command-line tool, type claude in a project directory, and get a prompt that behaves like a shell. No sidebar, no onboarding tour, no diff panel with a friendly green button. Then it reads your repository, proposes a change across five files, runs your test suite, and repairs the two tests it broke. The terminal stops feeling like a step backwards.
I’ve spent a few months running it across three very different codebases: a TypeScript monorepo with strict CI, a Python service with threadbare test coverage, and a static site nobody on the team wanted to touch. Here’s what the feature set actually delivers, and where it quietly glosses over the friction.
What Claude Code actually is
Anthropic’s agentic coding tool runs wherever your code already lives. Most people use the terminal version; there are also extensions for VS Code and the JetBrains IDEs, plus a browser-based option for repos you don’t have cloned locally.
Under the hood it’s a Claude model with tools bolted on: file reads, file edits, glob and grep search, shell execution, git. The model chooses which tools to call and in what order, then keeps going until the task looks finished. That single architectural decision explains most of the behaviour that follows, both the impressive parts and the annoying ones.
The features that earn their keep
Repository-wide edits instead of file-at-a-time suggestions
The first time you ask it to rename a function and watch it grep for call sites, edit 34 files, update the tests, and adjust two documentation pages, the difference from inline autocomplete becomes obvious. It reads your test files to infer conventions before writing new ones. It opens your package manifest before adding a dependency. That investigative loop is the product.
A permission model you can tighten without killing your flow
By default it asks before running shell commands and before writing to files, and approving is a single keystroke. You can add allowlists to a project settings file for the safe stuff, your test runner, git status, git diff, a linter, so routine turns stop prompting. The –dangerously-skip-permissions flag exists for sandboxed containers. Treat it with the seriousness the name implies, because it genuinely does what it says.
CLAUDE.md, the memory file that kills repeat corrections
Running /init generates a starter file describing your build commands, test runner, and style rules. That file loads into context every session, so you stop re-explaining that the project uses pnpm and not npm, or that migrations must be reversible. Add a line every time you correct the same mistake twice and watch the corrections disappear. Small feature, disproportionate payoff.
MCP servers turn it into a connected agent
The Model Context Protocol is the extensibility story, and it’s the one most reviews undersell. Point a server at your Postgres instance and it can inspect the actual schema before drafting a migration. Wire one to Playwright and it can drive a browser to verify a UI fix. Sentry, Jira, GitHub, internal APIs, each is a short config block. This is where a terminal tool starts to feel like infrastructure.
Hooks and subagents
Hooks fire shell commands on events. A formatter that runs after every file edit, a linter that blocks a commit, a script that logs every tool call for audit purposes. These are deterministic guardrails rather than polite requests the model might forget by turn forty. Subagents live as markdown files in a .claude/agents directory, each with its own prompt, tool access, and model. A reviewer subagent that can read but never write is a genuinely useful pattern; so is a test-writer that only sees the relevant package.
If you’re setting it up for the first time, these are worth doing in week one:
- Write CLAUDE.md properly. Build command, test command, lint command, three or four style rules. Fifteen minutes of writing saves hours of prompting.
- Add a PostToolUse hook that runs your formatter on any edited file, so diffs stay clean.
- Allowlist your test runner. Nothing kills momentum faster than approving npm test nine times in a row.
- Create one read-only subagent for review passes. A second opinion from a smaller context window catches things the main session has already rationalised.
- Try headless mode on something low-stakes, like a weekly dependency bump, before trusting it with anything that matters.
Headless mode and pipeline work
Running claude -p “prompt” –output-format json gives you scriptable, non-interactive output. Combined with a GitHub Action, that covers chores most teams never get around to automating: rotating stale dependency versions, triaging error logs into issues, or summarising what changed in a large branch before review. It’s unglamorous and it saves real hours.
Where it gets in its own way
Long sessions degrade. Three hours in, it starts re-reading files it already understood and proposing fixes for code it half-remembers. The /compact and /clear commands exist for a reason, and disciplined developers use them more often than they’d like.
It also over-reaches. Ask for a null check and you may get a defensive refactor of the whole module, complete with a helper function you never wanted. Reviewing diffs is not optional, and the habit of typing git diff before accepting is the single most valuable thing you’ll build in the first week.
Occasionally it states something about your codebase with total confidence and no grounding, usually about a file it never opened. It’s easy to catch if you’re reading, expensive if you’re not. Aggregated Claude AI user reviews land on remarkably similar praise and the same handful of gripes, which suggests these aren’t quirks of my setup.
The cost question that surfaces around week two
Agentic work burns tokens because every turn re-sends context. A heavy day of multi-file refactoring can chew through a lot, and the $20 Pro tier has usage limits that enthusiastic use hits faster than expected. The $100 and $200 Max tiers exist precisely for people who live in the tool, and pay-as-you-go API billing is the third option with its own arithmetic. Our detailed breakdown of Claude Code pricing runs the numbers properly, and it’s worth reading before you commit to a tier.
For a grounded sense of what sustained use looks like in practice, three months of measured Claude Pro usage on a $60 budget is a more honest signal than any benchmark.
Solo tool, or team infrastructure?
Claude Code shines for individual developers who already review their own diffs. Teams get more value from the shared parts, a committed CLAUDE.md, hook scripts, a review subagent, than from the raw model, and that only works with standardised permissions and some governance. Whether the per-seat maths holds against Cursor, Copilot, or a cheap Max seat depends entirely on how your people work; the $25-per-seat comparison digs into the parts vendor decks smooth over.
A one-week test that beats any demo
Demos flatter this category of tool. A week of real work doesn’t. Here’s a sequence that produces a genuine verdict.
Day one: run /init, then spend twenty minutes rewriting CLAUDE.md by hand. Note how many prompts it takes before the output matches your style.
Day two: hand it a bug with a reproducible test case and watch how it explores. Does it find the actual cause or patch the symptom?
Day three: give it a small legacy refactor with existing test coverage. This is where repository-wide reasoning either pays off or produces a sprawling diff you’ll spend an hour untangling.
Day four: connect one MCP server. If you have a database, use that, because schema-aware migrations are the strongest single argument for the tool.
Day five: count what you spent and how much of your own time you got back. That ratio, not the feature list, is the only number that decides whether the subscription survives next month.