Parth, a seasoned tech writer, wields the keyboard (or pen) with finesse to unravel the intricacies of both Windows and Mac operating systems. He has covered evergreen content on mobile devices and computers for multiple publications over the last six years. You can find his work on AndroidPolice, GuidingTech and TechWiser. Whether it’s demystifying system updates, deciphering error codes, or exploring hidden features, Parth’s prose guides readers through the binary maze. When not immersed in tech jargon, you’ll find him sipping chai, pondering the next software review, and occasionally indulging in a friendly debate about mechanical keyboards.
I have been using Claude Code since its launch, and over time, it has become an essential part of my development workflow. However, it took me months to realize that I was barely scratching the surface. Some of Claude Code’s effective tricks were hiding in plain sight, while others came from experimenting with different workflows.
After spending countless hours with Claude Code, I have picked up a handful of productivity tricks that make a difference.
Keep CLAUDE.md short
A shorter file delivers better results
One mistake I made early on was treating CLAUDE.md like a dumping ground for every project detail. I would stuff it with lengthy instructions, coding preferences, explanations, and even information that Claude Code could easily figure out by examining the codebase. Over time, I realized that a shorter, more focused file works much better.
For example, when working on my editorial dashboard project, I don’t need to explain every component or describe the entire folder structure. Instead, I keep a few essential instructions, such as reusing existing components, avoiding unnecessary dependencies, following established naming conventions, and running relevant tests after making changes.
That’s enough to give Claude Code a clear direction without overwhelming it with unnecessary context. I also keep detailed documentation in separate Markdown files and reference them when needed.
My rule is simple now: if an instruction isn’t relevant to most sessions, it probably doesn’t belong in the main CLAUDE.md file. This keeps the context focused and makes the file easier to maintain as my projects evolve.
Plan mode saves me from unnecessary mistakes
Think first, write the code later
One of the biggest lessons I have learned from using Claude Code is that jumping straight into coding isn’t always the smartest approach. Earlier, I would describe a feature, let Claude make changes, and then spend extra time fixing things it misunderstood. That’s when Plan mode has made a real difference.
Now, whenever I am working on a complex feature or modifying an existing project, I switch to Plan Mode using Shift + Tab. Claude Code examines the codebase, understands the existing structure, and lays out a step-by-step implementation plan without modifying my files.
For example, when I wanted to add a Kanban board to my editorial dashboard, I first asked Claude to analyze the existing task management system and suggest an approach. It helped me identify which components needed changes, how the new board would fit into the existing layout, and what could potentially break.
I could review the plan, suggest adjustments, and approve the approach before Claude wrote a single line of code. It adds an extra step initially, but saves me from unnecessary revisions.
You don’t need the highest model for every task
Save your expensive tokens for complexity
Another mistake I made early on was sticking with the most powerful Claude model for almost every task. Whether I was fixing a minor CSS issue, updating documentation, or building an entire feature, I would often use Opus blindly twice. It worked well, but I was burning through my usage allowance unnecessarily.
Now I am much more selective. For everyday coding, debugging, and implementing straightforward features, I usually stick with Sonnet. If I need to rename variables, make small edits, or handle simple repetitive tasks, Haiku is often sufficient.
I reserve Opus for complex architectural decisions, challenging bugs, and major refactoring projects where its deeper reasoning actually makes a difference.
Switching between models is straightforward with the /model command. I can even start planning with Opus and switch to Sonnet for implementation.
This doesn’t necessarily reduce the raw number of tokens consumed, but it lowers the cost of processing them and helps me stretch my available usage. It’s a simple adjustment that has made my Claude Code workflow much more economical.
Custom skills removed my repetitive prompts
Turn repetitive instructions into reusable shortcuts
I used to waste a major chunk of time typing the same instructions into Claude Code. That’s when I discovered Custom Skills, and they have become one of my favorite productivity features.
The idea is simple. I can create a reusable set of instructions in a SKILL.md file and invoke it whenever needed.
For example, while working on my editorial dashboard, I frequently ask Claude to review recent changes, look for potential bugs, check code formatting, and run relevant tests. Instead of explaining these requirements repeatedly, I created /review-changes Skill with all the necessary instructions.
Now, I simply type /review-changes, and Claude follows my predefined checklist.
Lessons from countless hours with Claude
After using Claude Code since launch day, I have realized that getting the most out of it isn’t just about writing better prompts or picking the smartest AI model. You need to build a workflow that saves time, reduces unnecessary effort, and makes the entire development process smoother.
The best part is that none of these tricks require advanced coding knowledge. If you are still using Claude Code mainly to generate and debug code, give these techniques a try.