What Is Claude Code Actually Good For? A Task-by-Task Verdict

Most of what is written about Claude Code falls into two camps. One says it replaces engineers. The other says it is autocomplete with delusions of grandeur. Both are written by people who used it for an afternoon.

The useful version of this article is not a verdict. It is a map of which tasks it handles well, which it handles badly, and — the part almost nobody writes down — how to tell the difference before you spend two hours discovering it. That is what I have tried to build here.

TopTut has no commercial relationship with Anthropic and earns nothing from this post. Where I give an opinion I have marked it as one.

What Claude Code actually is

It is an agentic coding tool that runs in your terminal, in your repository, with access to your files and your shell. That last part is the whole difference. A chat window can suggest a change. An agent can make the change, run the test suite, read the failure, and try again.

It is not an IDE plugin that completes the line you are typing, and it is not a chatbot you paste snippets into. The mental model that fits best is a contractor with repository access and a command line, which is also the mental model that tells you where the risks are.

Tool type	What it sees	What it can change	Where it fits
Autocomplete (inline)	The current file, some context	The line you are writing	Typing speed
Chat assistant	What you paste	Nothing. You copy back	Explaining, drafting snippets
Agentic coding tool	The whole repository, plus command output	Files, dependencies, git state	Multi-file tasks that have a definition of done

What it is genuinely good at

There is a pattern connecting everything in this list: the task has a verifiable definition of done, and the context needed to do it already exists in the repository.

• Debugging from a stack trace. Paste the error, let it read the relevant files, trace the call path and propose a fix. This is the single highest-value use and the one I would recommend anyone start with. The error defines success precisely, which is exactly the condition under which agents perform well.
• Writing tests for existing code. The behaviour is already specified by the implementation. It reads the function, writes cases, runs them, fixes what fails. Tedious work that benefits enormously from something that does not get bored on case eleven.
• Mechanical refactors across many files. Renaming a concept, changing a function signature everywhere it is called, extracting a module. The kind of change that is conceptually trivial and takes a human ninety minutes of careful find-and-replace.
• Answering questions about an unfamiliar codebase. “Where does authentication actually happen?” “What calls this endpoint?” “Why is there a second config loader?” Genuinely excellent, and badly underrated. For anyone who has just joined a project, this alone justifies the tool.
• Version and framework migrations. Upgrading a dependency with breaking changes, moving from one test runner to another. Well-documented patterns, mechanical application, immediate verification.
• Scripts and glue code. One-off data transformations, build scripts, CI configuration. Code that needs to work once and does not need to be beautiful.

What it is bad at

Same pattern, inverted. Where success is a matter of judgement rather than verification, results get unreliable, and the failure is rarely obvious.

• Greenfield architecture. Ask it to design a system from nothing and you get something that works and that you will regret. It optimises for producing a running result, not for the decisions you will live with in eighteen months.
• Anything requiring taste. API ergonomics, naming that will still make sense to someone else, knowing when a clever abstraction is worse than three lines of duplication. It has read a great deal of code and has no opinion about which of it was good.
• Large unsupervised runs. The longer it goes without a check, the further a small early misunderstanding propagates. A wrong assumption at step two becomes eleven files of wrong at step twenty, all internally consistent, all wrong.
• Work depending on context it cannot see. Your production data shape, an undocumented downstream consumer, a business rule that lives in someone’s head. It will confidently fill the gap with something plausible.
• Security-sensitive code, unreviewed. It writes functioning auth, payment handling and file uploads that routinely miss a check. Working and safe are different properties, and only one of them is verified by the tests passing.
• Saying no. It will attempt anything you ask. There is no “this is a bad idea, here is why”. You are the only source of that judgement in the loop.

A task-by-task verdict

Task	Verdict	Why	Supervision needed
Fix a bug from a stack trace	Strong	Success is precisely defined	Low. Read the diff
Write tests for existing code	Strong	Behaviour already specified	Low. Check the assertions mean something
Explain an unfamiliar codebase	Strong	Pure comprehension, no side effects	None
Mechanical multi-file refactor	Strong	Verifiable, tedious, well-bounded	Low, if tests exist
Dependency or framework migration	Good	Documented patterns, immediate feedback	Medium. Watch for silent behaviour change
Add a feature to an existing system	Mixed	Depends entirely on how well you specified it	High
Performance optimisation	Mixed	Good at obvious wins, poor at knowing what matters	High. Measure first, always
Design a new system	Weak	Optimises for running, not for living with	Do not delegate this
Security-critical implementation	Weak	Working and safe are different properties	Full review, every line
Anything with no test and no spec	Weak	No definition of done means no feedback loop	Write the spec first

The test that predicts success before you start

Before delegating anything, ask one question: how would I know if this was done correctly?

If the answer is “the test passes”, “the error stops”, “the types check”, or “the output matches this file”, delegate it. The agent has a signal to iterate against and will grind until it is satisfied.

If the answer is “it feels right”, “the team agrees it is the correct approach”, or “it still makes sense in a year”, do not delegate it. There is no signal, so the agent stops when it has produced something rather than when it has produced something good — and those two moments look identical in the terminal.

How to get better results

1. Give it the definition of done in the prompt. Not “fix the login bug” but “users with expired sessions get a 401 rather than a 500; there is a test covering it; the existing session tests still pass”. Specificity is the single biggest lever available to you.
2. Work in small commits. One bounded task, review, commit, next. Long unreviewed runs are where the expensive failures live, and a clean git history is how you undo one cheaply.
3. Keep a project instructions file. Conventions, architecture notes, what not to touch. Written once, it removes the same correction from every future session.
4. Let it read before it writes. Asking it to explain how something currently works, before asking it to change that thing, measurably improves the change. It also gives you a cheap check on whether it has understood.
5. Review the diff, not the explanation. The summary is always coherent. The diff is what actually happened, and they are not always the same story.
6. Start a new session when it gets lost. Once a conversation has accumulated a wrong assumption, arguing with it costs more than restarting with a better prompt.

Weak prompt, predictable disappointment:

  "Add caching to the API"

Strong prompt, because success is checkable:

  "Add response caching to GET /api/products in src/routes/products.ts.
   Use the existing Redis client in src/lib/redis.ts.
   TTL 300 seconds. Cache key must include the locale query param.
   Invalidate on any write to the products table.
   Add tests covering: cache hit, cache miss, and invalidation.
   Do not change the response shape."

The second prompt takes ninety seconds to write and saves an hour. It also forces you to decide the things the agent would otherwise decide badly on your behalf, which is most of the value.

Cost, and the thing people get wrong about it

Claude Code is available through Anthropic’s subscription plans and via API billing, with usage limits that vary by tier. Because pricing and limits change, check Anthropic’s own pricing page rather than any third-party summary, this one included.

The conceptual error I see repeatedly is comparing the subscription to a software licence. It behaves more like metered compute: a session that reads forty files and runs the test suite eight times costs meaningfully more than one that answers a question. Two people on identical plans can have entirely different experiences of whether it is expensive, based purely on how they work.

Practical consequence: scoping tasks tightly is not only better for quality, it is also what keeps usage sane. Vague prompts are expensive twice.

Who should not bother

An honest section, because the enthusiasm around these tools skips it.

• If you cannot review the output. This is the big one. An agent that writes code you cannot evaluate is not a productivity tool, it is a liability generator with good manners. Learning to read the diff is the prerequisite, not an optional extra.
• If your work is mostly small and local. Editing one file you know well is faster by hand. The agent overhead only pays off across multiple files or unfamiliar territory.
• If you are allergic to the terminal. It lives there. There are GUI-shaped alternatives if that matters to you.
• If your codebase has no tests. You can still use it, but you have removed the feedback loop that makes it reliable. Fix that first and the tool gets better for free.

My verdict

It is a real tool with a real and specific shape, and most disappointment with it comes from using it outside that shape. Delegate bounded, checkable work in code that already exists and it is genuinely excellent. Delegate judgement and you will get something that runs and that you would not have chosen.

The framing I keep coming back to: it is a fast junior who never gets bored and never pushes back. That tells you exactly how to use it. You would not hand a junior your system design or your payment flow unreviewed. You absolutely would hand them the test suite, the migration and the refactor — and you would be delighted with how quickly they came back.

If you are looking at it for work that is not strictly coding, that turns out to be a bigger category than it sounds and is covered in Claude Code for non-developers. For the broader category of agent tools, see the best AI agent platforms compared and agentic AI explained.

Frequently asked questions