I installed Claude Code on a Tuesday, mostly to find out whether the hype survived contact with a real repository. Six weeks and roughly 190 commits later, the answer is more interesting than a simple yes or no.
For context: the codebase is a Node and TypeScript monorepo, about 42,000 lines across three packages, with a test suite that takes four minutes to run and fails roughly one time in fifteen for reasons nobody has ever fully chased down. That is not a tidy sandbox. It is the kind of messy, half-documented environment most of us actually work in, and it is where a coding agent either earns its place or quietly gets uninstalled.
What Claude Code actually is, minus the marketing gloss
It is a command-line agent. You type claude inside your project, ask for something in plain English, and it reads files, edits them, runs your tests, and shows you a diff before anything lands. There is no separate IDE window and no chat pane bolted to the side of your editor. It lives where your git commands live.
That single design choice matters more than any feature list. Because it can run shell commands, it can do things a chat window cannot. It installs a dependency, runs the linter, notices its own change broke two tests, and goes back to fix them without you narrating every step.
The CLAUDE.md file carries more weight than the model
The first week was mediocre. The second week, after I wrote a proper CLAUDE.md at the repo root, it got noticeably better. That file is where you tell the agent the things a new contractor would need on day one: which package manager, how to run a single test file, the fact that the payments module uses a deprecated helper on purpose, and that anything touching the billing tables needs a migration in three places.
Skip that step and you get an agent that writes plausible code in the wrong idiom. Do it properly and the output stops looking like a stranger’s pull request. You can also drop in per-directory instruction files, which is how I kept the frontend conventions from bleeding into the API package.
Where it genuinely saved me time
Boring refactors and mechanical edits
Renaming a concept across 60 files, converting a set of callbacks to async/await, adding structured logging to every handler in one module. These tasks are tedious, low-judgement, and easy to verify with a test run. Claude Code is genuinely good at them. A rename that would have eaten an afternoon took about 25 minutes including review.
Reading unfamiliar code
Dropped into a service I had never touched, I asked it to trace how a webhook payload became a database row. It walked the call chain, named the files, and flagged a spot where retries could double-write. That last part was not something I asked for, and it turned out to matter.
Test scaffolding
It writes decent tests when you point it at existing ones as a pattern. Left to its own devices it produces tests that assert very little and pass very easily. Give it two real test files and a specific behaviour to cover, and the hit rate climbs fast.
The parts that wore me down
Confident wrongness is the big one. When it does not know how your system behaves, it does not always say so. It guesses, writes code around the guess, and the guess is buried three files deep. You catch it in review, or you catch it in staging.
It also over-reaches on scope. Ask for a small fix and you may get a small fix plus a helper function you did not request plus a tidy-up of an unrelated file. Restricted file access and a firm sentence in CLAUDE.md about not touching files outside the task cut this down considerably, though not to zero.
Long sessions degrade. Somewhere past the 90-minute mark, the agent starts losing the thread of what it already changed and re-edits things it fixed earlier. I now start fresh sessions per task rather than pushing through, and the quality difference is obvious. Anyone weighing this against a full enterprise rollout will find the same pattern at larger scale, which is why a proper review of Claude Enterprise’s real limitations is worth reading before you commit a team to it.
What it costs once you stop demoing
Claude Code sits on top of a Claude subscription or API billing, and this is where the honest part of the review gets uncomfortable. On a $20 Pro plan you get access with usage limits that a serious coding day will hit. I did, twice, in week one. Bumping to a Max tier at $100 or $200 a month removes most of that friction, but “most” is doing quiet work in that sentence: heavy agentic sessions still burn through allowances faster than chat usage ever did.
API billing is the other option and the least predictable. A single sprawling refactor across a large repo can move real money, because every file read and every command output goes back into the context. If you are costing this out for an organisation rather than yourself, the arithmetic changes shape entirely, and a plain-spoken Claude Enterprise value-for-money breakdown is a better starting point than the pricing page.
For an individual developer, my honest verdict is that $100 a month is defensible if you ship code daily and the agent removes an hour of grunt work per week. It is not defensible if you use it a few times a month.
Permissions and trust: the part you actually control
By default Claude Code asks before running commands. You can allowlist patterns to reduce the interruptions, and you should think hard about which ones. Anything that touches credentials, deploys, or production data deserves a prompt every single time.
The agent reads your files. All of them, if you let it, including the .env sitting in the root. I now keep secrets out of the working directory it sees and run it in a container for anything sensitive. That is not paranoia so much as the same hygiene you would apply to any tool with shell access. The same questions about what a paid Claude tier genuinely protects apply here too, and a grounded Claude Pro security review covers the parts the marketing leaves out.
Where it does not belong
- Architecture decisions. It will happily propose a design. The design will be plausible and not yours.
- Performance work. Without profiling data it optimises by vibes.
- Legacy code with tribal knowledge. If the reason for the weird code is not written down, the agent will helpfully delete it.
- Anything you cannot test. No test, no verification, no confidence.
The pattern is consistent: the more mechanical and verifiable the task, the better the output. A rundown of Claude use cases that actually earn their seat maps closely to what I found on a much smaller scale.
How I would decide, in your position
Set aside a full day and try it on your own codebase, not a tutorial project. Write a real CLAUDE.md first, because testing without one tells you nothing useful. Then pick three tasks: a mechanical refactor, a bug fix with a failing test, and something ambiguous you would normally think about for an hour. Track how long review takes, not just how long generation takes, because review is where the cost hides.
If review time stays under a third of what you saved, keep paying. If you find yourself rewriting its output more often than you accept it, cancel and revisit in six months. Mine is still installed, still on a Max plan, and still gets a fresh session every task. It has not replaced how I think about code. It has removed a decent chunk of the typing, which is roughly what I wanted.