Introduction

If you’ve used Claude Code even a few times, you already know it’s powerful. But there’s a big gap between getting okay results and getting consistently great results. The difference usually isn’t the tool — it’s the workflow.

Over the past several months I’ve refined how I work with Claude Code, and I’ve landed on a process that reliably produces high-quality, well-tested code with minimal back-and-forth. It boils down to four things: plan thoroughly, use the right tools, validate with tests, and close out your session cleanly. None of it is complicated, but doing all four consistently has been a force multiplier for my productivity.

Here’s exactly how I do it.

1. Start Every Session in Plan Mode

This is the single biggest thing that improved my results. Whether I’m kicking off a greenfield project or diving back into an existing codebase, I always start in plan mode.

Plan mode tells Claude to stop and think before writing any code. Instead of jumping straight into implementation, it gathers context, asks questions, and builds a mental model of what you actually need. The more information you front-load here, the better everything downstream will be.

Here’s what I typically include in a planning prompt:

• Codebase orientation — I ask Claude to study and understand the code I’m working in. I’ll point it to specific files, reference line numbers, and link to relevant documentation or even my issue tracker.
• Tooling and conventions — I spell out what libraries, languages, frameworks, and design philosophies the project follows. If I want a functional style over OOP, I say so here.
• Detailed goals and requirements — The clearer you are about what “done” looks like, the less back-and-forth you’ll need later. Be specific.
• Scope boundaries — Just as important as telling Claude what to do is telling it what not to do. I’ll call out files it shouldn’t touch, classes that need to stay as-is, or areas that are explicitly out of scope.
• Tests up front — This one’s easy to forget, but I always include test writing as part of the initial plan. I tell Claude what testing framework to use, what level of coverage I expect, and whether I want unit tests, integration tests, or both. Baking tests into the plan means they’re written alongside the implementation rather than bolted on as an afterthought. It also gives Claude a clearer understanding of expected behavior, which tends to produce better code overall.
• Recent context — If I’m continuing work on an existing project, I’ll ask Claude to review the last few commits and diffs on the repo. This gives it a strong sense of momentum and direction.
• The interview — This is key. At the end of my planning prompt, I ask Claude to ask me any and all clarifying questions before moving forward. Think of it like a mini requirements interview. It often surfaces edge cases or ambiguities I hadn’t considered.

The upfront investment in planning pays for itself many times over. You’ll get more accurate implementations, fewer rewrites, and a much smoother development flow.

2. Lean on the Built-In Tools

Claude Code ships with some genuinely useful tools that a lot of people seem to overlook. Two in particular have become staples in my workflow:

Dev Browser

If you’re building web apps, Dev Browser is a game-changer. It gives Claude a dedicated browser instance connected directly to your app’s DevTools — meaning it can access the DOM, take screenshots, read console output, and even measure performance metrics.

No more copying and pasting error messages between your terminal and your chat. Claude can see what’s happening in the browser for itself, diagnose issues in context, and suggest fixes with the full picture in front of it. It turns debugging from a tedious back-and-forth into something much closer to pair programming.

Cartographer

Cartographer reads through your codebase and builds a structural map of it. This might not sound flashy, but it’s incredibly practical — especially across multiple sessions.

Once Claude has mapped your project, it can navigate and reference your code much more quickly without having to re-read everything from scratch. This means faster responses, better context awareness, and fewer tokens burned on orientation. If you’re working on a large or complex codebase, Cartographer is well worth enabling early.

3. Run the Tests

Once Claude has finished writing the implementation and the accompanying tests, don’t just eyeball it and move on — have Claude actually run the test suite.

This is where the planning from step one pays off. Because you defined testing expectations early, Claude has already written tests that reflect your requirements. Now you’re closing the loop by verifying everything passes. If something fails, Claude can see the output directly, understand what went wrong, and fix it on the spot — often in a single follow-up.

It’s a simple step, but it catches issues before they ever make it into your codebase. Think of it as your automated sanity check before wrapping up a session.

4. Close Out the Session Cleanly

This is the step most people skip entirely, and it’s one of the most valuable. Before you end a session, put Claude to work on the housekeeping:

• Update CLAUDE.md — This is Claude Code’s memory file. Ask Claude to write down anything relevant for future sessions: architectural decisions made, conventions followed, gotchas encountered, or context about what was built and why. The next time you (or a teammate) start a session on this project, Claude will pick up right where you left off instead of starting from scratch. Over time, this file becomes an incredibly rich project knowledge base.
• Update your README — If the work you’ve done changes how the project is set up, run, or used, have Claude update the README to reflect that. Documentation that stays in sync with the code is rare and valuable — and it costs you almost nothing to maintain it this way.
• Write your commit messages — Claude has full context on what changed and why. Let it draft your commit messages. They’ll be detailed, accurate, and consistent — and you’ll never have to stare at a blank commit message input again.

These small habits compound over time. Your project stays well-documented, your git history stays meaningful, and every future session starts with better context than the last.

Conclusion

The pattern is straightforward: plan, build, verify, document. None of these steps are groundbreaking on their own, but strung together they create a workflow that’s reliable and repeatable.

The biggest shift for me was realizing that Claude Code rewards preparation. The more context and structure you give it up front, the less time you spend correcting course later. Plan mode, good tooling, test-driven validation, and clean session hygiene have turned Claude Code from a useful assistant into something that genuinely feels like a senior teammate.

If you’re only doing one thing differently after reading this, make it plan mode. Everything else flows from there.

• ai
• Claude
• development