I've been using Claude Code for about three months now, and it's fundamentally changed how I write software. Not in the "wow AI is magic" way that people tweet about. In the "I actually ship faster and the code is better" way. If you're new to the concept, I wrote about what agentic coding actually means and why it matters.

Here's my exact setup, why I chose it, and the workflow patterns that have stuck.

Why the Terminal

I tried Cursor. I tried Copilot. I tried every IDE integration out there. They all felt like they were fighting me. The autocomplete would trigger when I didn't want it. The inline suggestions would break my flow. The chat panels took up screen real estate I needed for actual code.

Claude Code runs in the terminal. It reads your files, understands your project structure, and makes edits directly. No GUI overhead. No context switching between a chat window and your editor. You describe what you want, it reads the relevant files, proposes changes, and applies them. You review in your normal git diff workflow.

My Configuration

The first thing I did was create a CLAUDE.md file in every project root. This is the system prompt that persists across sessions. Here's the skeleton I use:

# Project Context
Tech stack, key patterns, directory structure.

# Rules
- Always write tests for new functions
- Use the existing error handling pattern in src/errors/
- Never modify migration files directly

# Style
- Prefer named exports
- Use TypeScript strict mode conventions
- Keep functions under 40 lines

The CLAUDE.md file is the single most important thing you can do. Without it, Claude starts every conversation cold. With it, Claude already knows your stack, your conventions, and your preferences. I've seen it reduce correction loops by about 70%. I go deeper into what makes a good config file in my Claude Code config breakdown.

The Workflow That Stuck

My typical flow looks like this:

  1. Open terminal in the project directory
  2. Run claude to start a session
  3. Describe the task in plain English, referencing specific files if I know them
  4. Review the proposed changes in my editor's git diff view
  5. Accept, reject, or ask for modifications
  6. Commit when satisfied

The key insight: treat Claude Code like a junior developer who is extremely fast but needs clear instructions. If you say "fix the bug," you'll get mediocre results. If you say "the /api/users endpoint returns 500 when the email field is missing, add validation in src/routes/users.ts that returns a 400 with a descriptive error message," you'll get exactly what you want.

Multi-File Edits: Where It Shines

The real power isn't single-file changes. It's when you need to touch 5-10 files for one feature. Adding a new API endpoint means updating the route, the controller, the service, the types, the tests, and the documentation. Claude Code handles all of these in a single pass.

Last week I asked it to add rate limiting to twelve endpoints. It updated each route file, added the middleware configuration, created the Redis connection helper, wrote the tests, and updated the README. Took about 90 seconds. That would have been an hour of mechanical work.

What Doesn't Work

I want to be honest about the limitations.

Architecture decisions. Claude Code is not good at deciding whether you should use a queue or a webhook. It'll implement whatever you tell it to, but the high-level design thinking is still on you.

Large context windows don't mean infinite context. If your project has 200 files, Claude Code can't hold all of them in memory at once. You need to point it at the right files. The better your project is organized, the better Claude Code works.

Novel libraries. If you're using a library that shipped after the training cutoff, Claude will hallucinate APIs. I keep a docs/ folder with key API references for newer dependencies and tell Claude to read those first.

Tips That Took Me Weeks to Learn

Use the /compact command when your conversation gets long. It summarizes the context and frees up the window for new work without losing important state.

Start specific, then broaden. Don't say "refactor this module." Say "rename the getUserData function to fetchUserProfile and update all call sites." Then follow up with the next specific change.

Let it read before it writes. Start requests with "Read src/services/ and then..." This forces Claude to load the actual code before proposing changes, which dramatically reduces hallucination.

Three months in, I can't imagine going back to writing every line myself. The terminal-first approach means Claude Code fits into my existing workflow rather than replacing it. That's why it stuck when nothing else did.