How I Actually Use Claude Code

Most engineers use AI coding tools wrong. They ask a question, get an answer, and copy-paste it. That’s autocomplete with extra steps.

Claude Code is a terminal agent. It reads your codebase, runs commands, edits files, and iterates — without you babysitting every step. The shift is from answering questions to delegating work.

Here’s how I actually use it.

Give it the full context

The biggest mistake is being too narrow. “Write a function that does X” produces generic output. “Look at how we handle authentication in src/middleware/auth.ts and add rate limiting that follows the same patterns” produces something that fits.

Claude Code reads files. Let it. Before starting any task I make sure the relevant files are open or I tell it explicitly where to look.

Use it for the boring-but-precise work

The highest-leverage use case for me isn’t generating new features — it’s the work that’s tedious but must be exact:

• Migrating a database schema and updating every type that touches it
• Refactoring a component that’s used in 30 places to accept a new prop
• Writing tests for an existing function, covering edge cases I’d likely skip
• Adding error handling to every API route consistently

These tasks are annoying enough that I’d rush them. Claude Code doesn’t rush.

Review everything

I don’t auto-accept diffs. I read them. Not because I don’t trust the output — but because I learn the codebase better this way and catch assumptions the model made that don’t fit the context.

The edit loop is fast. Request → review → approve or reject → continue. That rhythm is faster than writing the code myself while still keeping me in control of what ships.

Keep sessions focused

Claude Code works best with a clear, bounded task. “Refactor the auth module” is too big. “Add a refresh token rotation to the existing auth module, following the pattern in src/auth/session.ts” is right-sized.

When a session drifts — when I’m three subtasks deep and the original goal is fuzzy — I start a new session. Context pollution is real. Fresh session, clear task.

Use it for code review

At the end of a working session, I’ll paste in a diff or describe a change and ask: “What could go wrong here? What edge cases aren’t handled? What would a senior engineer push back on?”

It’s a good sanity check before opening a PR. It’s caught real issues.

What it doesn’t replace

Architecture decisions. It’ll suggest patterns, but deciding what the right abstraction is — that’s still mine. Code review from teammates. It finds bugs, not business context. Judgment about tradeoffs that require knowing the team, the timeline, and the constraints.

The engineers who get the most out of these tools treat them as capable colleagues — not oracles, not autocomplete. Delegate the right work, review everything, stay in the loop.

It’s not magic. It’s just faster.