How I Actually Use Claude Code (And What Took Me Too Long to Figure Out)
By Roman Knox · March 2026 · ~7 min read
Most people install Claude Code, open a terminal, type something like "hey, fix this bug", and then feel mildly underwhelmed. I was one of those people for longer than I'd like to admit.
The tool is genuinely powerful. But there's a gap between "it works" and "it actually changes how I code" — and that gap is almost entirely about how you use it, not what it can do.
This isn't a getting-started guide. The official docs handle that fine. This is what I wish someone had told me after the installation was done.
Getting Set Up Properly (The Part Most Tutorials Skip)
Installation is one line on macOS, Linux, or WSL:
curl -fsSL https://claude.ai/install.sh | bash
You need a paid Anthropic plan — Pro, Max, Teams, or Enterprise. The free tier doesn't include Claude Code. That's worth knowing upfront rather than debugging for twenty minutes wondering why auth keeps failing.
The first time you run claude in your terminal, a browser window opens for OAuth. If it doesn't open, press c to copy the URL and paste it manually. After that, credentials are saved and you won't think about auth again.
Now, the part most tutorials skip entirely: .claudeignore.
This file works exactly like .gitignore and sits in your project root. It tells Claude which files to never see. If you don't have one, Claude can and will read your .env files, your secrets.json, your API keys. That's not a hypothetical — it just happens as part of normal context loading.
Add one before you start working. At minimum:
.env*
secrets.json
*.pem
node_modules/
dist/
*.log
Claude Code also respects your .gitignore by default, which helps. But the explicit .claudeignore is how you draw the hard lines.
The Four-Step Workflow That Actually Works
For anything beyond a quick one-liner, I use a four-step loop: Explore → Plan → Implement → Verify. And the key is that the first two steps happen in a mode most people don't even know exists.
Plan Mode. You start a session with:
claude --permission-mode plan
In this mode, Claude can read your codebase and reason about it, but it can't write or change anything. It will ask clarifying questions, explore your file structure, trace dependencies. The output is a plan — a list of files it wants to touch, what it intends to do to each one, what tests it'll run, and what "done" looks like.
This sounds like a small thing. It isn't. Before I started using Plan Mode, Claude would dive straight into making changes, and I'd review them after the fact. Now I review the intent before a single character is written. The number of times I've caught the wrong assumption at that stage — and avoided a whole chain of bad edits — is genuinely significant.
Once the plan looks right, I switch to a normal session and execute it incrementally. Small, logical pieces. Not "implement the whole feature" in one shot.
After implementation, I run the tests. And I ask Claude to verify its own work — "did you actually do what the plan said?" This step feels redundant until the one time it catches something.
CLAUDE.md: Give Your Project a Brain
Here's the single highest-leverage thing you can do in any project: create a CLAUDE.md file in your root directory.
Claude reads this automatically at the start of every session. Think of it as a system prompt for your codebase — a place to encode everything a new team member would need to know before touching the code. Naming conventions, branch format, testing strategy, build commands, the stuff that usually lives in someone's head or gets lost in a wiki nobody reads.
A minimal one looks like this:
You are Claude working on [project-name].
Follow the conventions in references/style-guide.md.
Branch naming: feature/<short-desc>
Default to tests-first, minimal diffs, and clear commit messages.
If you're unsure about scope, ask one clarifying question before proceeding.
That last line — "ask one clarifying question" — is one I added after a few frustrating sessions where Claude made sweeping assumptions. Now it asks. Problem mostly solved.
The more specific your CLAUDE.md, the less you repeat yourself across sessions. I've started treating it like a living document that I update whenever Claude does something I didn't expect.
Git Superpowers
This is where I probably get the most consistent daily value. Claude Code integrates cleanly with the command line, which means you can pipe things directly into it.
Commit messages. I used to write them in a hurry and they were bad. Now I use this shell function:
function gcm() {
git diff --staged | claude -p "Write a Conventional Commit message for these changes.
Format: <type>(<scope>): <subject>
Types: feat, fix, docs, style, refactor, test, chore.
Infer scope from file paths."
}
I run gcm, get a properly formatted message, copy it, done. Takes five seconds. And my git history is finally readable.
Same idea for PR reviews — before I open a PR, I'll run:
git diff main | claude -p "Summarize these changes and flag anything that looks risky."
It catches things. Not everything, but enough that it's become part of my pre-push habit.
The -p flag (or --print) is what makes this work — it runs Claude in non-interactive mode, outputs the result to stdout, and exits. Perfect for scripts.
Keeping Costs Sane
This section matters a lot more if you're on a Pay-as-you-go plan than a flat subscription. But even on Pro, the habit of matching model to task is worth building.
The hierarchy is simple: Haiku for fast, cheap, simple operations. Sonnet for most day-to-day coding. Opus for genuinely complex, multi-step architectural reasoning. You can switch mid-session with /model.
The commands I actually use regularly:
/clear — starts a fresh session. Use this when you switch to an unrelated task. Sending stale context costs tokens for no reason.
/compact — compresses a long conversation's history. Useful when a session has been running for a while and you want to continue without dumping it.
/stats — shows usage within your daily limit (subscription plans). /cost is the API-key equivalent.
One thing I didn't know for a while: Claude Code automatically caches prompts. If you're sending similar requests repeatedly — say, the same system context with different follow-up questions — cache hits cost about 10% of a normal request. That adds up to meaningful savings over a day of heavy use.
When Things Go Wrong
The first command to run when something feels off is:
claude doctor
It runs a full system check — auth status, network connectivity, config validity — and surfaces most common issues immediately. I've started running it reflexively when a session behaves unexpectedly, before I spend time debugging anything else.
For deeper problems, add --debug or --verbose to your CLI command and redirect the output to a file. If you're using the VS Code extension and something looks wrong there, the Extension Host logs (from the Command Palette → "Show Extension Logs") are where the useful diagnostics live.
Honestly, I don't hit real problems very often. But when I do, claude doctor + the logs gets me to an answer faster than anything else I've tried.
One Thing I'm Still Figuring Out
I haven't fully nailed the parallel agent stuff — spinning up multiple isolated subagents for concurrent tasks. The docs describe it well, and I can see why it would be useful for large-scale analysis across many files. I've tried it twice, it kind of worked, and I haven't made it a habit yet. That might just be me.
But the core workflow — Plan Mode, CLAUDE.md, piping into Git, keeping context clean — that part I'd recommend to anyone who's been using the tool for a while and still feels like they're leaving something on the table.
You probably are. But less so after reading this.
What does your Claude Code setup look like?
I'm especially curious whether anyone has a CLAUDE.md they're particularly happy with — it feels like one of those things where the details matter a lot and examples are rare. Drop a comment or find me on the usual channels.
