Claude Code Use Cases: What It's Genuinely Good At

The Claude Code use cases that work share one property: something other than you can tell the agent whether it succeeded. Tests pass, the build compiles, the type checker is quiet, the script exits zero.

Sort by that and the picture is clear:

Tier 1: the agent grades itself

Make the failing test pass. The canonical case. Point it at a red test, let it read the failure, edit, and re-run. The loop is the product.

Fix the type errors. Same shape — a compiler that says no is a perfect grader.

Mechanical refactors across many files. Rename a concept, extract a module, change a signature everywhere it's used. Tedious for a person, verifiable by the build.

Fix the failing CI job. Reproduce locally, iterate until green.

These are where an agent genuinely outperforms doing it yourself, because the work is high-volume and low-judgment and the feedback is instant.

Tier 2: you check it quickly

Backfilling tests. The classic "should do, never does" job. An agent writing tests for existing code is useful precisely because you can run them — and because the bar is coverage that didn't exist before.

Dependency upgrades. Bump, build, read the errors, fix, repeat. Miserable manually, mechanical for an agent.

Framework migrations. Anything with a documented upgrade path and a test suite to prove it landed.

Asking questions about an unfamiliar codebase. "Where is authentication handled?" answered from actual files rather than a guess — Anthropic's common workflows guide leads with exactly this. Verify by opening what it cites, the same discipline as checking a research citation.

Writing the script you keep avoiding. The one-off migration, the data-tidying pass, the report generator.

Notice the pattern in Tiers 1 and 2: most of the value is work that wasn't going to happen otherwise. The speedup on work you were already doing is real but smaller than the "this finally got done" effect.

Tier 3: assistive only

Architecture decisions, API shape, naming, whether a dependency is worth adding. An agent is genuinely useful here as a thinking aid — argue the other side, list what a decision assumes, produce three options you hadn't considered.

It's not useful as the decider, and the confident tone is misleading, because fluency reads as analysis. Use it to widen the option set, never to close it.

Tier 4: keep a human on it

Auth and permission logic, anything touching production data, credential handling, destructive migrations. Not because an agent can't write them, but because the failure is invisible until it isn't, and review is the only control that works. Running commands inside the Bash sandbox limits the blast radius of a bad command, but it does nothing about a plausible-looking change to permission logic.

The practical rule: let the agent prepare, keep the human on the trigger. That's the same discipline that applies across agentic AI use cases generally.

What makes any of these work better

Four things, none of which are model choice:

1. A project instructions file. Your test command, conventions, patterns, and what not to touch — this is what CLAUDE.md and the memory system are for. Ten minutes, and it improves output more than switching tools. This is the highest-return action available and almost nobody does it.
2. Short tasks. Ten steps at 95% each is roughly a coin flip end to end. "Fix this test" beats "refactor the module" every time.
3. A clean working tree. Commit or stash first. Reviewing an agent's diff is easy; reviewing an agent's diff mixed with your own half-finished edits is not.
4. Reading the diffs. Accepting changes you haven't read accumulates code nobody understands, and that debt arrives later.

Where it isn't the right tool

No tests, no types, no build check. You can still use it, and you're now the only grader — which means reviewing everything by hand and losing most of the leverage.

You want completion, not delegation. Inline suggestions while you type are an editor's job. Best AI IDE covers that split.

Genuinely novel work. Quality tracks how much similar code exists publicly. Something nobody has written before gets weaker output, and that's exactly the work worth doing yourself.

For evaluating whether it fits your situation at all, is Claude Code worth it works through the decision properly.

One job sits outside this list: running an AI setup somebody else published. That's mostly an environment problem — dependencies, keys, versions — rather than a coding one. Taku mirrors a working AI setup into a desktop workspace and runs it there rather than asking you to reproduce it. The free app library shows what's available to mirror. Taku is in Beta, and the Mac app is available now.

FAQ

What are the best Claude Code use cases?

Anything with an automatic pass/fail signal — failing tests, type errors, build breaks, and mechanical refactors across many files. After that, test backfill, dependency upgrades, migrations, and codebase questions.

What should I not use Claude Code for?

Architecture and naming decisions (assistive only), and anything irreversible or security-sensitive without human review. Also genuinely novel work, where output quality drops.

Does Claude Code work without tests?

It runs, but you become the only thing checking it. Most of the leverage comes from the agent verifying its own work, so expect a much smaller gain and a bigger review burden.

How do I get better results?

Write a project instructions file with your test command and conventions, keep tasks short, start from a clean working tree, and read every diff.

Is it faster than doing it myself?

On mechanical multi-file work, usually. The larger effect is that tedious work you'd been postponing actually gets done.

How do I continue a previous Claude Code session?

Run claude --continue (or claude -c) to reopen the most recent conversation in the current directory. claude --resume (or claude -r) opens a picker of past sessions, or takes a session ID or name directly, as in claude --resume auth-refactor. Inside a running session, /resume switches conversations. Anthropic's session docs cover naming and branching sessions.

Key points

• Sort use cases by whether something can automatically verify success.
• Tier 1 is failing tests, type errors, build breaks, and mechanical refactors.
• Most value comes from work that wasn't going to happen otherwise.
• Keep architecture calls assistive and irreversible changes behind a human.
• A project instructions file beats switching tools.