How I Actually Use Claude Code Day to Day

The demos show someone typing "build me a SaaS dashboard" and getting an app. That's not what the tool is good at, and chasing that is how people conclude it's overhated or overhyped depending on their mood that week.

Here's what it's actually good at, ranked by how much time it saves me.

1. Understanding code I didn't write

This is the biggest one and nobody talks about it. Dropped into an unfamiliar codebase, my first three questions used to take an afternoon of grepping.

> How does authentication work in this app? Trace it from the login
  request to where the session is checked on a protected route.

It reads the actual files and answers with real paths and line numbers, which I then verify. Ninety seconds instead of ninety minutes. The verification step is not optional — but verifying a specific claim against a specific file is enormously faster than finding the file in the first place.

2. Mechanical refactors across many files

Renaming a concept across 40 files. Converting a component tree from NgModules to standalone. Migrating a deprecated API call. Work that's tedious, low-judgement, and error-prone precisely because it's boring.

The important part is scoping the request narrowly enough to review the diff. "Migrate the whole app" produces a diff nobody reads honestly. "Migrate the components in features/payroll and stop" produces one I can actually check.

3. The first draft of tests

I don't ship AI-written tests unread — a test that asserts the current behaviour is worthless if the current behaviour is the bug. But a first pass that covers the obvious paths, sets up the fixtures, and gets the mocking boilerplate right saves the part of testing I actively dislike, and leaves me to write the edge cases that matter.

4. Debugging with real evidence

The thing that makes a terminal agent different from a chat window is that it can run commands. Paste a stack trace and it can read the file, check git history for when the line changed, run the failing test, and add a log statement to check a hypothesis.

> This test fails only in CI, never locally. Read the test, check the
  CI config, and tell me what differs between the two environments.

That was a timezone difference. It found it in one pass because it could read both the test and the workflow file, which is exactly the kind of cross-file correlation I'm slow at.

What I don't use it for

• Architecture decisions. It'll give you a reasonable-sounding answer to "should we use microservices" without knowing your team size, your ops maturity, or your deadline. It's not that the answer is wrong — it's that it can't know the things that decide it.
• Anything touching money, auth, or personal data without close review. Not because it's careless, but because the cost of being wrong is asymmetric and review is cheap.
• Greenfield code where I don't yet know what I want. If I can't describe it precisely, I'll get something precise that isn't it, and editing that is slower than writing it.

The habits that made the difference

Plan before executing on anything non-trivial

Ask for the plan first, read it, correct the two things that are wrong, then let it run. Reviewing a plan takes thirty seconds. Reviewing a 600-line diff built on a wrong assumption takes twenty minutes and usually ends in a revert.

One task per session

Long sessions that drift across three unrelated tasks produce worse output — context fills with irrelevant history and the model starts pattern-matching on the wrong thing. Finish, clear, start fresh. This is the single easiest habit to adopt and it improves results immediately.

Make it verify its own work

"Run the tests and the linter, and fix what fails" as part of the original request. Otherwise you're the build server, and you'll find the type error after you've context-switched away.

Say what you don't want

Negative constraints are underrated. "Don't add dependencies." "Don't touch the API layer." "Don't add comments explaining what the code obviously does." These prevent the specific things I'd otherwise spend the review deleting.

The honest accounting

It hasn't made me write twice as much code. It's compressed the parts of the job that were never the interesting part — reading unfamiliar code, mechanical migrations, boilerplate, the first draft of tests, remembering the exact ffmpeg flags.

The design work, deciding what to build, and knowing when something is wrong: unchanged. Those were always the job. Everything else was the tax.