How to Use Claude Code: A Working Setup, Not a Feature Tour
How to use Claude Code productively: the CLAUDE.md file that decides output quality, plan mode, permissions, and the review discipline that keeps agent-written code maintainable.
The first hour with an agentic coding tool goes one of two ways. Either it edits four files you did not expect and you turn it off, or it does something genuinely useful and you spend the next week wondering why the results are so inconsistent.
Both outcomes have the same cause: the agent is working without the context a new colleague would get on day one. It cannot see your conventions, your deploy path, or the three things that will break production. This guide is about supplying that, because it is the difference between a novelty and a tool you keep.
Start with the project file
Claude Code reads a CLAUDE.md at the root of your repository on every session. This single file does more for output quality than any prompting technique.
Write it as onboarding notes for a competent developer who has never seen the codebase. Short, specific, and about things that are not inferable from the code.
| Include | Skip |
|---|---|
| Build, test and deploy commands | Anything the agent can read from package.json |
| Conventions that are not obvious from the code | Restating your framework's documented defaults |
| Architecture decisions and why | A file-by-file directory listing |
| Things that will break production if touched | Aspirational style rules nobody follows |
Concretely: "run npm run check before committing, it runs types and lint together", "never edit dist/, it is generated", "the payments module is legacy, changes need a review from the finance team". That kind of thing.
The test of a good CLAUDE.md is whether a competent stranger could ship a small change without asking anyone. If they could, the agent can too.
Plan before it edits
For anything beyond a one-line fix, ask for the approach before the code. Reviewing a plan takes a minute; reviewing a wrong implementation across six files takes an afternoon and you will miss something.
The pattern that works: describe the outcome, ask for a plan, correct the plan, then let it run. Most bad sessions are a bad plan that nobody looked at.
Permissions, deliberately
The agent asks before actions that change things. The temptation is to approve everything to stop the interruptions, which removes the only checkpoint you have.
A workable middle ground:
| Action | Setting |
|---|---|
| Reading files, searching, running tests | Allow freely |
| Editing files in the repo | Allow, because you review the diff |
git commit |
Allow once you trust the message quality |
git push, deploys, migrations, anything destructive |
Always ask |
The distinction that matters is reversibility. A bad edit is a git checkout. A bad push or a dropped table is a much longer afternoon.
Read the diff
This is the discipline that separates useful output from accumulating debt. The code will compile. The tests may pass, particularly if the agent also wrote them. Neither tells you the logic is right.
Read for the things that look fine and are not: an error swallowed in a catch, a condition inverted, a retry that hides a failure it should surface, a test asserting the behaviour that was implemented rather than the behaviour you wanted.
If the diff is too large to read carefully, that is the signal the task was too large. Ask for it in pieces.
Tools
Claude Code is a terminal tool, so it composes with what you already run: git, your test runner, your linter. Point it at your existing npm run check rather than inventing a new workflow.
For where it sits against the wider category, see our comparisons of the best AI coding assistants, AI for code review and vibe coding tools if you want the prompt-to-app end of the market instead.
Pitfalls
Letting one session run for hours. Context degrades and so does output. Finish a task, commit, start fresh.
Asking for a feature instead of a change. "Add authentication" produces something unusable. "Add a login route that checks the session cookie against the existing users table, matching how the admin route already does it" produces something reviewable.
Never updating CLAUDE.md. If you correct the same thing twice, that correction belongs in the file. Otherwise you will correct it forever.
Trusting tests the agent wrote without reading them. A test that asserts current behaviour passes and proves nothing.
What these tools actually cost
We price every tool we review, so this is measured rather than estimated. Across 429 tools, 293 publish a price and 33% offer a free tier. Among developer tools, the median entry plan is $24.50 a month, which runs above the $24 median across every category we price.
The spread matters more than the median. Half of the developer tools sit between $10 and $49, and the range runs from $2.49 to $299. A quoted "starting at" price near the bottom of that range usually means per-seat add-ons land on top of it.
| Price point | Developer tools | All tools |
|---|---|---|
| Cheapest paid plan | $2.49 | $1 |
| Lower quartile | $10 | $10 |
| Median | $24.50 | $24 |
| Upper quartile | $49 | $49 |
| Most expensive | $299 | $990 |
| Tools measured | 18 | 293 |
FAQ
What is Claude Code?
It is Anthropic's agentic coding tool that runs in your terminal and works directly on your repository: reading files, editing them, running commands and tests, and committing. The difference from a chat window is that it acts on the real codebase rather than returning a snippet you paste, which is what makes both the speed and the review discipline matter.
How is it different from an editor extension?
Editor assistants are strongest at completion and local edits inside the file you are looking at. A terminal agent works across the whole repository and can run your toolchain, so it suits multi-file changes, refactors and anything that needs the tests run. Many developers use both, for genuinely different jobs.
Do I still need to review the code?
Yes, and it is the whole discipline. Generated code compiles and looks finished, which is precisely why it slips through. Read every line of the diff, particularly error handling and anything touching auth, payments or data deletion. If the diff is too big to read, the task was too big.
How do I stop it making changes I did not ask for?
Two things. Ask for a plan before implementation on anything non-trivial, and keep the permission prompts on for irreversible actions like pushing, deploying or migrating. Scope also helps more than instructions: one clear change per session, committed before you start the next.
Devshot: the daily dev & AI brief
Free daily newsletter, read in 5 minutes.
Subscribe free