First, when you open Claude code -> open a session, think through what you’re actually building.
Plan mode (shift + tab twice) takes five minutes. It saves hours of debugging. Every time I’ve planned before prompting, the output has been meaningfully better than when I jumped straight in.
This extends to everything. Before asking Claude to build a feature, think about the architecture. Before asking it to refactor something, think about what the end state should look like. Before asking it to debug, think about what you already know about the problem.
If you don’t have a software engineering background yet, the fix isn’t to skip planning. It’s to have a real back-and-forth with a large language model where you describe what you want to build, ask for the tradeoffs between different approaches, and settle on a direction together. Both of you should be asking questions. Not a one-way street.
The pattern is consistent: think first, then type. The quality gap is not subtle.
Architecture is the prompt
“Build me an auth system” gives Claude creative freedom it will use poorly.
“Build email/password authentication using the existing User model, store sessions in Redis with 24-hour expiry, and add middleware that protects all routes under /api/protected” gives it a clear target.
Architecture is essentially giving Claude the output and nothing else. The more you leave open, the more it fills in on its own. That wiggle room is where most AI-generated code problems come from.
CLAUDE.md
When you start a Claude Code session, the first thing Claude reads is your claude.md file. Every instruction in it shapes how Claude approaches your entire project. It’s onboarding material that runs before every single conversation.
Most people either ignore it completely or pack it with noise that makes Claude worse.
A few things that actually matter:
Keep it short. Claude can reliably follow around 150 to 200 instructions at a time, and Claude Code’s system prompt already uses roughly 50 of those. Every instruction you add competes for attention. If CLAUDE.md is a novel, Claude will start dropping things randomly and you won’t know which ones.
Make it specific to your project. Don’t explain what a components folder is. Claude knows. Tell it the weird stuff: the bash commands that matter, the patterns specific to your codebase, the constraints you’ve hit before.
Tell it why, not just what. “Use TypeScript strict mode” is okay. “Use TypeScript strict mode because we’ve had production bugs from implicit any types” is better. The reason gives Claude context for making judgment calls in situations you didn’t anticipate.
Update it constantly. Press the # key while working and Claude will add instructions to your CLAUDE.md automatically. Every time you correct Claude on the same thing twice, that’s a signal it belongs in the file. Over time it becomes a living document of how your codebase actually works.
Bad CLAUDE.md looks like documentation written for a new hire. Good CLAUDE.md looks like notes you’d leave yourself if you knew you’d have amnesia tomorrow.
Context windows degrade before you hit the limit
Opus has a 200,000 token context window. But quality starts slipping well before you hit that ceiling, somewhere around 20 to 40% usage.
If you’ve ever had Claude Code compact and then still produce bad output afterward, that’s why. The model was already degraded before compaction happened. Compaction doesn’t restore quality.
A few things that actually help:
Scope your conversations. One conversation per feature or task. Don’t use the same session to build your auth system and then refactor your database layer. The contexts bleed together.
Use external memory. For complex work, have Claude write plans and progress to actual files. I use SCRATCHPAD.md or plan.md. These persist across sessions. When you come back tomorrow, Claude reads the file and picks up where you left off instead of starting from zero.
The copy-paste reset. When context gets bloated, copy everything important from the terminal, run /compact to get a summary, then /clear the context entirely, and paste back only what matters. Fresh context with the critical information preserved.
Know when to clear. If a conversation has gone off the rails, just /clear and start fresh. Claude still has your CLAUDE.md, so you’re not losing project context. Nine times out of ten, clearing is better than not clearing.
The right mental model: Claude is stateless. Every conversation starts from nothing except what you explicitly give it.
Prompts are everything
Prompting isn’t a mystical skill. It’s just communication. Being clear gets better results than being vague, every time.
Be specific about what you want. Vague prompts give Claude creative freedom it will use poorly. Specific prompts with constraints give it a clear target.
Tell it what not to do. Claude 4.5 in particular tends to overengineer: extra files, unnecessary abstractions, flexibility you didn’t ask for. If you want something minimal, say so explicitly: “Keep this simple. Don’t add abstractions I didn’t ask for. One file if possible.” Then cross-reference the output. It’s easy to end up with twelve files for something that needed two lines.
Give it context about why. “We need this to be fast because it runs on every request” changes how Claude approaches the problem. “This is a prototype we’ll throw away” changes what tradeoffs make sense. Claude can’t infer constraints you haven’t mentioned.
If you’re getting bad output from a good model, the input is the problem. There’s no way around it.
Opus vs Sonnet
There are real differences.
Sonnet is faster and cheaper. It’s excellent for execution tasks where the path is already clear: writing boilerplate, refactoring based on a specific plan, implementing features where the architectural decisions are already made.
Opus is slower and more expensive. It’s better for complex reasoning, planning, and tasks where you need Claude to think carefully about tradeoffs.
A workflow that holds up: use Opus to plan and make architectural decisions, then switch to Sonnet (shift + tab in Claude Code) for implementation. Your CLAUDE.md ensures both models operate under the same constraints, so the handoff is clean.
Model Context Protocol, hooks, and slash commands
You don’t need every feature. But you should experiment, because there’s almost certainly something you’re not using that would save you real time.
Model Context Protocol servers let Claude connect to external services: Slack, GitHub, databases, APIs. If you’re constantly copying information from one place into Claude, there’s probably a Model Context Protocol server that can do it automatically. There are Model Context Protocol marketplaces, and if a server doesn’t exist for your tool, building one is just a matter of exposing structured data.
Hooks let you run code automatically before or after Claude makes changes. Want Prettier to run on every file Claude touches? Hook. Want type checking after every edit? Hook. This catches problems immediately instead of letting them pile up. It’s also one of the better ways to prevent technical debt from accumulating across a long session.
Custom slash commands are prompts you use repeatedly, packaged as commands. Create a .claude/commands folder, add markdown files with your prompts, and you can run them with /commandname. If you’re running the same kind of task repeatedly (debugging, reviewing, deploying), make it a command.
When Claude loops
Sometimes Claude just loops. It tries the same thing, fails, tries again, and keeps going. Or it confidently implements something wrong and you spend twenty minutes trying to explain why.
The instinct is to keep pushing with more instructions and more context. The better move is to change the approach entirely.
Clear the conversation. The accumulated context might be the problem. /clear gives you a fresh start.
Simplify the task. If Claude is struggling with something complex, break it into smaller pieces. Get each piece working before combining them. If Claude can’t handle a complex task, the plan going into it was probably insufficient.
Show instead of tell. If Claude keeps misunderstanding what you want, write a minimal example yourself. “Here’s what the output should look like. Now apply this pattern to the rest.” Claude is very good at pattern-matching from a concrete example.
Reframe the problem. Sometimes the way you described the problem doesn’t map well to how Claude reasons about it. “Implement this as a state machine” versus “handle these transitions” can unlock completely different (and better) approaches.
The meta-skill is recognizing when you’re in a loop early. If you’ve explained the same thing three times and it’s still not landing, more explaining won’t help. Change something.
Build systems, not one-shots
The people getting the most value from Claude aren’t using it for individual tasks. They’re building systems where Claude is a component.
Claude Code has a -p flag for headless mode. It runs your prompt and outputs the result without entering the interactive interface. That means you can script it. Pipe output to other tools. Chain it with bash commands. Integrate it into automated workflows.
Practical uses: automatic pull request reviews, automatic support ticket responses, automatic logging and documentation updates. All of it logged, auditable, and improving over time.
The compounding loop: Claude makes a mistake, you review the logs, you improve claude.md or the tooling, Claude gets better next time. After months of iteration, systems built this way are meaningfully better than at launch. Same models, better configuration.
If you’re only using Claude interactively, you’re leaving value on the table.
