Claude for Developers: What It's Actually Good For

Codebase archaeology

"Explain how auth works in this repo" against a codebase Claude has never seen is the closest thing to magic in the current toolchain. Onboarding to unfamiliar code — new job, inherited service, open-source dependency — compresses from days to hours.

Debugging with a tireless partner

Claude holds the whole stack trace, the code, and six hypotheses in mind simultaneously, at hour three when your working memory is gone. Used with discipline (hypotheses before fixes), it's the best rubber duck ever built.

The tests you weren't going to write

Boundary cases, error paths, the concurrency scenario you know matters but keep deferring. Test generation is Claude's highest benefit-to-risk task: worst case you review and delete; best case it finds the bug before production does.

Review before the review

A Claude pass over your diff catches the embarrassing stuff before a human sees it — and an adversarial-review prompt catches real failure modes. Your colleagues' review time gets spent on design, where it belongs.

The migrations nobody wants

Framework upgrades, API deprecations, converting test suites, typing legacy modules: high-volume, pattern-based, boring. Exactly the work delegation was invented for — and in Claude Code, it runs the tests to prove each step held.

Morning: the feature

Open Claude Code in the repo. Describe the feature with constraints and ask for a plan before code. Critique the plan (or run plan mode), then let it implement while you review the diffs it proposes. It runs the test suite itself and fixes what breaks.

Midday: the interrupt

Production bug. Paste the stack trace and symptoms; ask for ranked hypotheses with the cheapest diagnostic for each — not a fix. Confirm the hypothesis with the diagnostic it suggested, then let it write the fix plus the regression test that would have caught it.

Afternoon: the PR

Before requesting review: an adversarial pass ("review as the 3am maintainer"), then have Claude draft the PR description with the risky part flagged for reviewers. Your human reviewers see a diff that's already survived one skeptic.

Codebase orientation

I just inherited this codebase. Orient me:
1. Map the main modules and what each owns — where does a request enter and exit?
2. Which parts look load-bearing and under-tested? (I must not break these casually.)
3. What conventions does this code follow that I should imitate?
4. What would you refactor first, and what should be left alone despite being ugly?

Design-first feature

I need to build: [feature]
Constraints: [stack, patterns this repo uses, what you can't change]

Before writing ANY code: propose the design — files touched, data flow, edge cases you'll handle, and the one decision you're least sure about. I'll approve or push back, then we implement.

The failing test

This test fails and I don't know why:
[test + failure output]

List the possible causes ranked by likelihood, with the fastest check for each. Don't propose a fix until we've confirmed a cause — I'll run the checks and report back.