How I Use Claude Code Every Day
I've been using Claude Code as my primary development tool for months now. I joke that my job is essentially managing Claude Codes, but it's not far from the truth.
Understanding Code with Claude
Claude Code helps me write code and acts as a reasoning partner for understanding complex systems. When working in unfamiliar code, I start by asking Claude Code to explain what the code does and how it works, including diagrams where helpful.
As I get a better understanding of the code, I have Claude trace specific scenarios through the codebase: "What happens if this config option is set but the feature flag is disabled?" It walks through the state transitions, surfaces edge cases I wouldn't have thought to check, and I end up with a behavior matrix I can turn into tests.
Git Worktrees for Parallel Work
This is the workflow change I'd recommend to anyone. Instead of constantly stashing and switching branches, I use git worktrees, so each branch lives in its own directory. Claude Code operates in whichever worktree I point it at.
The real value comes with stacked PRs. I work in chains of dependent PRs, a bug fix, then a feature built on top of it, then gating logic on top of that. When an earlier PR merges, I rebase the downstream ones.
Some specific patterns I use daily:
Conflict resolution. Conflicts are inevitable with rebasing stacked PRs. I tell Claude exactly how to resolve them: "Keep my changes for the test files, accept theirs for the generated files." It handles the conflicts without me re-reading every single one.
Branch verification. Before Claude Code does anything significant, I check what branch we’re working in. In a multi-worktree setup, this has saved me more than once from changes ending up in the wrong place. I have the branch name as part of my terminal prompt for easy reference.
ITerm tabs: Use them! I have a tab for each active Claude Code session. I use a column layout so I can quickly scan what I’m working on and which session needs my attention.
My iTerm setup with tabs for each active claude code session
MCPs are your friend: I use the datadog mcp to query logs, the Slack mcp to ping me in Slack when Claude Code needs my attention, the Playwright mcp to test front end changes, and more.
Skills: Claude.mds are good but skills are a game-changer when it comes to processes you repeat often. I have a skill that hunts for bugs in my code, one that cleans up stale local branches and worktrees, the code review plugin, and my new favorite frontend design skill. I appreciate being able to spin up nice looking UIs with minimal effort.
Claude: When in doubt ask Claude! Claude knows how to use Claude Code and what tools and skills it has available. It has the history of the session. If you have way too many active sessions and forget which is which, just ask Claude!
Claude code on the web/ in Slack: When I'm on the go and remember something I need implemented or someone reports a bug in Slack, I kick off a remote Claude Code session from either Slack or the web to implement my random idea or fix the bug and create the PR from the web UI.
Write, Test, Review, Iterate
My development loop with Claude Code is:
Write. I describe what I want with specifics, not "fix this" but "This function should add disabled items to the blocklist, but it's silently dropping them instead. Please fix." The more precise the problem statement, the fewer iterations needed. Steer Claude and reject its proposed edits if they are incorrect. You're still the engineer in charge. Claude is really good, but in many cases you have more context than it does.
Test. I start by asking what tests already exist and what they cover. Then I describe the behavior I want to verify and let Claude write the test. For complex code, that usually means a matrix of inputs and expected outcomes. I describe the expectations and Claude generates the full test suite.
Review. I have Claude self-review before pushing. I prompt "Use the code review skill on the code in this branch." It then invokes my code review skill and catches nil handling gaps, comment/code mismatches, test assertion contradictions, regressions etc. Once it’s addressed all issues, I review the code.
Iterate. I make updates to the skills and docs as needed, so Claude can do better the next time. More often than not, I make these updates by telling Claude to reflect on what we did and update the skills/ docs accordingly.
The models are improving fast enough that my workflow from three months ago already feels dated. What used to require careful hand-holding now just works. With Opus 4.5 & 4.6 I've been delegating larger chunks of work to Claude Code and letting it autonomously drive the full development cycle. Stay curious, keep experimenting, and be ready to let go of more than feels comfortable.