I’ve been using Claude Code since February. Over 7 months in, and I keep seeing the same pattern: developers install MCPs, set up subagents, build automation, then struggle with inconsistent results and context overload.
I learned Claude Code before Plan Mode existed. Before MCPs. “Hey Claude, plan this out first” became muscle memory because there was no other way to work effectively. Now that workflow is a built-in feature.
In my experience, the developers shipping consistently have mastered the loop: clean context, plan, review, approve, iterate. The ones struggling often share a pattern: cognitive overload from MCPs eating their context window.
The Core Loop (What Works for Me)
Claude Code’s power isn’t in automation. It’s in the human-in-the-loop workflow when that loop is tight and efficient.
Start every task with clean context. Let Claude plan in read-only mode before touching files. Review the plan, ask clarifying questions, iterate until you’re confident. Only then approve and let Claude execute. When something goes wrong, document the correct approach in your CLAUDE.md so it doesn’t happen again.
This workflow isn’t a beginner feature you graduate from. It’s the foundation. Making this loop fast matters more than automating it away.
I start every task with clean (or compacted) context. Not sometimes. Every time. This isn’t pedantic, it’s the difference between Claude understanding your request and Claude working with cognitive overload.
Plan Mode Is Not Training Wheels
Claude will make mistakes. Always. The question isn’t whether mistakes happen, it’s when you catch them.
Measure twice, cut once. Plan Mode (Shift+Tab) is the measuring. It surfaces flawed approaches, missed edge cases, communication gaps, and bad architectural calls while they’re still just text. Fix them there, not after Claude has written 500 lines in the wrong direction.
I use plan mode for almost everything now:
- Complex refactors: “I need to migrate our auth system to OAuth2. Create a detailed plan.”
- Unfamiliar codebases: “Analyze how error handling works across this project.”
- Risky changes: “Plan out how to update this database schema without downtime.”
- Learning: “Explain the tradeoffs between approach A and B for this feature.”
Mistakes will still slip through. You’ll miss things in review. Claude will introduce bugs you don’t catch until runtime. That’s fine. The goal isn’t perfection, it’s reducing the cost of iteration.
CLAUDE.md: Teach Once, Apply Forever
Every project gets a CLAUDE.md file. Every preference I find myself repeating goes in my global ~/.claude/CLAUDE.md
. This isn’t documentation for me, it’s training for Claude. Good CLAUDE.md files are short, specific, and opinionated. Bad ones try to document your entire stack (Claude can figure that out by reading your code).
User-level preferences
Put your universal preferences in ~/.claude/CLAUDE.md
:
# Commit Messages
- NO Claude attribution
- NO "Generated with" footers
- Use conventional commits (feat:, fix:, etc.)
- First line under 72 characters
# Code Style
- DO NOT over-engineer
- DO NOT add features I didn't request
- Keep solutions simple and direct
- Prefer boring, readable code
This applies to every project. Architecture philosophy, commit style, code preferences, general working patterns.
Project-level conventions
Put project-specific context in ./CLAUDE.md
at your repo root:
- Framework-specific conventions (React patterns, API structure)
- Project architecture documentation
- Technology stack details
- Deployment processes
- Short coding examples showing your preferred patterns
- Links to PRD markdown files for feature context
Keep it concise. Bullet points, not paragraphs. The time investment is 5 minutes per project. The return is every interaction being shaped by your preferences without repetition.
Multi-tool compatibility
Using other agentic tools? Create AGENTS.md
instead of CLAUDE.md for compatibility. But Claude Code still looks for CLAUDE.md, so symlink it:
ln -s AGENTS.md CLAUDE.md
Then document it at the top of AGENTS.md:
# Note: CLAUDE.md is symlinked to this file for Claude Code compatibility
Stay on the Beaten Path (At First)
Claude Code works best with popular frameworks and standard patterns. Not because it can’t handle esoteric tools, but because:
- More training data: React, Next.js, FastAPI, Django - Claude has seen these patterns thousands of times
- Better error recognition: Stack Overflow is full of solutions Claude can reference
- Community conventions: Standard project structures mean less context needed
I watched a developer struggle for hours trying to get Claude to understand their custom build system. Another developer using vite and pnpm was shipping features. The difference wasn’t skill, it was leverage.
Once you’re comfortable with the core loop, then branch out. But when you’re learning, standard tools let you focus on the workflow instead of fighting context gaps.
Context Engineering Matters More Than You Think
Type /context
in your next Claude Code session and look at what’s loaded. You’ll be surprised how much of your context window is already consumed before you even start coding.
MCPs consume a lot of context. Each one you add is tokens Claude can’t use for understanding your code. A bloated CLAUDE.md file does the same thing. When I see developers struggling with “Claude isn’t understanding my requests,” the first thing I check is their context usage.
As the context window fills up, Sonnet 4.5 starts taking shortcuts. Responses get less thorough. It skips edge cases. The quality degrades in subtle ways that are hard to pin down until you realize the pattern. Keep your context clean to avoid this.
What eats context
- Each MCP server you’ve installed
- Your entire CLAUDE.md (user + project levels)
- Files Claude has read this session
- Conversation history
- Reserved space Claude keeps for compaction
How to stay efficient
- Keep CLAUDE.md concise (bullet points, not paragraphs)
- Use
/clear
to reset context when switching tasks (or/compact
if the recent task is relevant to the next one) - Install MCPs only when you have a specific, repeated need
- Monitor with
/context
periodically
This is why starting simple isn’t just good for learning, it’s technically necessary. Master working within a clean context window before you start filling it with integrations.
The Workflow That Stuck
After over 7 months, here’s what I actually do:
- Define scope - Be specific about what you want. “Add OAuth2 login” not “improve auth”
- Start in plan mode (Shift+Tab) - always, even for “simple” tasks
- Let Claude explore first - “Analyze this codebase” before “Build this feature”
- Ask questions - “What would break if we changed X?” before approving
- Approve and execute - Exit plan mode only when 100% confident, then Claude executes the entire plan
- Review and catch mistakes - Catch what you can in the diff. Some will slip through anyway
- Feed learnings back - Document what went wrong in CLAUDE.md so it doesn’t happen again
With this foundation solid, I can now selectively add MCPs, subagents, slash commands, and automation case by case when I have a specific need. Not because they’re available, but because they solve a real problem in my workflow.
Why This Matters
AI coding tools are getting absurdly capable. The bottleneck isn’t what they can do, it’s how effectively you can direct them. In my experience, mastering the core loop (clear communication, tight feedback, incremental validation) delivers more value than rushing to automate everything.
Plan mode isn’t a safety feature for beginners. It’s a thinking tool for professionals. CLAUDE.md isn’t busy work, it’s leverage. The boring fundamentals are boring because they work.
Start there. Get fast at the core loop. Then, if you still want those MCPs and subagents, add them. You might find the fundamentals get you 90% of the way there.
Pick a real task you’re working on. Start Claude Code in plan mode (claude --permission-mode plan
or Shift+Tab in an active session). Ask Claude to analyze first, propose second, and only exit plan mode when you’re genuinely confident in the approach. Notice how many misunderstandings you catch in planning that would’ve been annoying to fix in code.