How to Actually Get Real Work Out of Claude Code (Without Watching It Refactor Your Codebase Beautifully in the Wrong Direction)
Seven habits that separate the people shipping PRs with Claude Code from the people wondering why it just rewrote 40 files they never asked it to touch.
Here's what nobody tells you about Claude Code: the model is the best coding agent shipping right now, and most people are still using it like a fancier autocomplete. They open a terminal, type "add Google OAuth to my app," hit enter, and then watch Claude confidently edit 23 files, invent an API signature from a library version that shipped in 2023, and somehow refactor the billing module they specifically didn't want touched.
That's not Claude's fault. That's a workflow problem. Claude Code is agentic. It reads your files, runs commands, makes changes, and works on its own while you watch or grab coffee. That autonomy is the whole point, and it's also why you can't prompt it like ChatGPT and expect a clean PR. You have to build rails. A memory file it reads every session. A plan before it edits. A test it can run to check its own work. Once those rails exist, it stops solving the wrong problem at full speed and starts shipping real features.
These are the seven habits I've settled on after months of daily use across client projects and my own repos. None of them require you to be a Claude Code power user. Most of them are one keystroke or one file. But together, they're the difference between "why did I pay for Max" and "how did I ever ship without this."
1. Write a CLAUDE.md and treat it like the highest-leverage file in your repo
Stop re-typing “use the repository pattern, not Eloquent in controllers” into every session. Put it in a file once and be done with it.
CLAUDE.md gives Claude persistent context about your project. Think of it as a config file that Claude auto-loads into every conversation, so it always knows your project structure, your coding standards, and how you like to work.
Drop the project file in either ./CLAUDE.md or ./.claude/CLAUDE.md, put in the instructions that apply to anyone working on the repo (build and test commands, coding standards, architectural decisions, naming conventions, common workflows), and check it into version control so the whole team gets it.
The fastest way to start is /init. Run it and Claude reads your codebase and generates a starting file with the build commands, test instructions, and conventions it can pick up on its own. If a CLAUDE.md already exists, /init suggests improvements instead of blowing it away. Then edit the result. Delete the obvious stuff. Add what Claude can’t infer: your deploy command, the module that’s off-limits, the fact that you use Pest and not PHPUnit.
Now the part everyone gets wrong: keep it short. Claude Code’s system prompt already carries around 50 individual instructions. Depending on the model, that’s close to a third of the instructions your agent can reliably follow before rules, plugins, skills, or your own messages get added on top. Which means your CLAUDE.md should be as lean as you can make it, ideally only rules that apply everywhere.
LLMs bias toward instructions at the edges of the prompt, and as instruction count climbs, instruction-following degrades across the board. The model doesn’t just start ignoring the newest rules, it starts ignoring all of them.
Translation: a 500-line CLAUDE.md doesn’t make Claude smarter. It makes Claude follow everything worse. Aim for under 200 lines. Some of the best CLAUDE.md files I’ve seen fit on one screen. If you keep piling on rules and the output isn’t getting better, the file is the problem.
2. Never let Claude edit before it plans
This is the single highest-leverage habit in this whole guide, and it’s one keystroke.
Separate research and planning from implementation, or you’ll ship code that solves the wrong problem. Letting Claude jump straight into editing is how you get a confident, beautiful diff pointed at the wrong target. Plan mode splits exploration from execution: Claude analyzes and plans, and it doesn’t touch a file until you sign off.
How you turn it on: press Shift+Tab twice. Plan mode fans out multiple subagents in parallel to explore your codebase from different angles, then comes back with clarifying questions before committing to an approach.
In plan mode, Claude can read, search, list, browse the web, spawn research subagents, and ask you questions. It cannot edit, write, run bash, or use any tool that modifies your project.
Boris Cherny, the guy who built Claude Code, has described his own workflow like this: most sessions start in plan mode with Shift+Tab twice, then he bounces back and forth with Claude until he likes the plan, then flips into auto-accept edits mode where Claude usually one-shots it. A good plan is really important.
That’s the whole trick. Pour your effort into the plan. Read what Claude proposes. Push back on the parts that look wrong. Once you’re actually happy with what it’s about to do, then let it code.
One extra tip most people miss: hit Ctrl+G while a plan is open. It pops the plan into your text editor so you can edit it directly instead of describing changes over chat. Way faster than typing “actually change step three to…“
3. Delegate exploration to subagents so your main context stays clean
The reason a long session goes off the rails isn’t that Claude got dumber. It’s that the context window filled up.
Claude’s context holds your whole conversation. Every message, every file read, every command’s output. That fills up fast, and a single debugging session can burn tens of thousands of tokens. LLM performance drops as context fills, so once the window’s crowded, Claude starts “forgetting” earlier instructions and making more mistakes. Context is the single most important resource to manage.
The fix isn’t lecturing Claude harder. It’s keeping the main window clean by pushing exploration into subagents.
Exploring a big codebase floods your context with file reads. Delegate the exploration and only the findings come back. The subagent reads files in its own context window and hands you back a summary. In practice, that looks like: “use a subagent to investigate how our auth system handles token refresh.” Claude spawns a worker with a fresh window, that worker reads twenty files, and only the two-paragraph findings land back with you.
Tack “use subagents” onto any request where you want Claude to throw more compute at the problem. It offloads the individual tasks so your main agent’s window stays focused.
And when a session is genuinely fried, don’t fight it. Use /clear between unrelated tasks so stale context doesn’t bleed into new work. When the agent has gone down a bad path twice, stop correcting and reset. Clear it, then restart with a sharper prompt that folds in what you learned. A fresh session with a better prompt almost always beats a long session full of failed attempts.
4. Give Claude a test it can run so it grades its own work
The single dumbest thing you can do is trust an agent’s self-report. “I’ve implemented the OAuth flow and all tests pass” means nothing if Claude never ran the tests. Force it to show its work.
Give Claude a feedback loop so it catches its own mistakes. Bake the test commands, linter checks, or expected outputs into the prompt.
Make Claude show evidence instead of just claiming success: the test output, the command it ran and what came back, or a screenshot. Reading evidence is faster than re-running the verification yourself, and it works for sessions you weren’t even watching.
The pattern I use for basically every non-trivial task now looks like this:
Implement the OAuth callback handler per the plan. Then run
npm test -- authand paste the full output. If any test fails, fix and re-run. Do not stop until the suite is green and you’ve pasted the passing output.
That last sentence is the whole game. It forces Claude to close the loop itself instead of handing you back a “looks good to me!” with three red tests underneath.
5. Use subagents for the boring polish jobs you do on every PR
Once you’ve got the basics down, subagents are how you stop doing the same code-review and cleanup jobs by hand.
A few I run regularly: code-simplifier tidies up the code after Claude’s done working, verify-app has detailed end-to-end testing instructions. Think of subagents as automating the most common workflows you run on almost every PR.
The mental model: a subagent is a markdown file that defines a focused worker with its own system prompt and its own toolset. Write it once, invoke it forever.
Tack /simplify onto any prompt after making changes. It fires off parallel agents that review the diff for reuse, quality, efficiency, and CLAUDE.md compliance, all in one pass. That one command alone is worth the setup. You get a fresh model reviewing the changes, not the same one that just wrote them and thinks they’re brilliant.
Rule of thumb: if you do something more than once a day, turn it into a skill. Test-driven development, PR review, security scan, docstring check, all of it. You’ll compound.
6. Run parallel Claudes in worktrees, not on top of each other
If you’re getting fast at this, you’ll naturally want to run more than one Claude at a time. A feature build in one terminal, a bug fix in another. Do not do this on the same branch.
A worktree is a parallel checkout of the same repo, sitting on a different branch in a different directory. Create one with git worktree add ../myproject-bugfix bugfix/login-401, then open a fresh Claude Code session in the new directory. It picks up the same CLAUDE.md and the rest of the harness (all of that is committed to the repo), but the session itself is fresh, with its own context and its own branch.
This pattern matters more for agentic work than it ever did for plain git. Two sessions on the same branch step on each other with stale file reads and overlapping edits.
The workflow: bug comes in while you’re mid-feature, you spin up a worktree, fix the bug in a fresh Claude session, open the PR, delete the worktree, and slide back into your original feature session with all its context intact. It sounds fussy the first time. It’s muscle memory by the fifth.
7. Run a hook when something must happen 100% of the time
CLAUDE.md is advice. Hooks are law. Know which one to reach for.
CLAUDE.md is advisory. Claude follows it maybe 80% of the time. Hooks are deterministic, 100%. If something has to happen every time without exception (formatting, linting, security checks), make it a hook. If it’s guidance Claude should consider, CLAUDE.md is fine.
The canonical example: your formatter. A PostToolUse hook can format Claude’s code. Claude usually generates well-formatted code out of the box, and the hook handles the last 10% so you don’t hit formatting errors in CI later. Set it up once, and every file Claude edits gets Prettier’d (or Black’d, or gofmt’d) before you ever lay eyes on it. Stop asking Claude to “please format the file” in your CLAUDE.md. That’s what a linter is for.
Bigger principle: never send an LLM to do a linter’s job. LLMs are pricey and painfully slow next to traditional linters and formatters, so always reach for the deterministic tool when one exists. Every rule you can enforce with a hook is one fewer instruction eating your context budget in CLAUDE.md, and one fewer thing to nag Claude about in every prompt.
The bonus habit that ties it all together: build rails, then let it run
The pattern under all seven of these is the same. Good Claude Code use isn’t about clever prompts. It’s about the rails.
A memory file the agent reads every session. A plan before it touches disk. Fresh context for exploration. A test it has to pass. A hook for the checks that can’t be optional. A worktree when you fan out.
Do that, and Claude Code stops being an over-eager intern that rewrites your billing module while you’re getting coffee, and starts being the most productive collaborator on your team. Skip it, and you’ll spend more time undoing beautiful, wrong code than you would have spent writing the feature yourself.
Build the rails. Then get out of the way.