How to Get the Most Out of Claude Code: Tips From Real-World Use

I’ve been using Claude Code heavily across AI engineering work: RAG pipelines, .NET MCP servers, content automation, agentic workflows. The way I use it now looks nothing like how I started.

Most write-ups on Claude Code cover the same ground: install it, run a prompt, watch it work. That part genuinely does work. What they don’t cover is how to stop it working against you as your sessions get more complex.

In this blog post I share the things I actually do.  These are grounded in daily use across production codebases.

~

Use Your CLAUDE.md Properly

Every session Claude Code loads your CLAUDE.md. Think of it as the project briefing that runs before every piece of work. Done well, it’s the single biggest quality lever available to you.

A mistake some people make is treating it like a README. It isn’t. It’s a set of standing instructions that need to earn their place on every single turn.

Keep it under 200 lines. Shorter if you can. Every line costs context budget before a word of work has been done. Context rot is real. Research has shown frontier models can drop from 95% accuracy to 60% as input grows. Your CLAUDE.md contributes to that.

Lead with commands. The exact invocations for testing, building, linting, and running your project. This section has the highest return on investment by a wide margin. Don’t write style rules that a linter already enforces deterministically; that’s a waste of instruction slots.

For one production project I work on (a .NET AI developer assistant with a RAG pipeline and vector store backed by Elasticsearch), my CLAUDE.md includes: the IVectorStore abstraction boundaries, which chunking conventions to follow, the exact test runner command, and what not to touch without asking. Nothing else.

Claude starts every session already oriented to the architecture. That matters when you’re working across a corpus of thousands of documents.

~

Plan Mode Is Not Optional on Anything Non-Trivial

Letting Claude jump straight into code produces code that solves the wrong problem. I’ve done this enough times to have stopped doing it.

The workflow that actually works has a clear separation between exploration and execution. Use plan mode (Shift+Tab twice) to let Claude read the codebase and understand what’s there without making any changes. Then ask for a plan. Review it. Edit it directly with Ctrl+G if you need to adjust the direction. Only then switch out of plan mode and let it code.

This isn’t bureaucracy. It’s the difference between Claude building what you described and Claude building what you meant.

A real example: I needed to add semantic caching to a RAG synthesis pipeline to bring down LLM latency. Skipping plan mode here would have been expensive. The caching layer needed to sit at a specific point in the pipeline and respect the existing IVectorStore abstraction.

Two minutes in plan mode reading the relevant files, then a written plan I could review, meant Claude implemented it in the right place first time rather than bolting it on somewhere that looked plausible but broke the abstraction.

Plans also persist across context resets, so you don’t lose planning work when you clear the session.

~

Context Is the Most Important Resource You’re Managing

Most people blame the model when Claude starts making mistakes mid-session. It’s almost always a context problem.

Claude’s context window holds everything: every message, every file read, every command output. Long debugging sessions burn through it fast. As it fills, earlier instructions get buried. The model starts forgetting conventions it was following an hour ago.

I hit this directly while diagnosing why a continuous Azure WebJob was silently aborting mid-crawl with no error in the logs. The investigation involved reading status files, plotting App Service Plan metrics, checking for crash dumps, reviewing the event log.

By the time I’d worked through all of that in a single session, earlier context about what I’d already ruled out was gone. Claude started revisiting paths I’d explicitly closed off. A fresh session with a concise summary of conclusions so far would have been faster.

The practical discipline: /clear between distinct tasks. Not occasionally. Frequently. If you fail the same thing twice in a row, that’s your signal to clear and restart with a better prompt that incorporates what you’ve learned. Don’t push through with a polluted session.

Use /compact with intent when you’re mid-task and can’t afford to lose the thread. You can guide it: /compact Focus on the ingestion pipeline changes or /compact Preserve the chunker bug findings. Add a compact policy to your CLAUDE.md so auto-compression preserves what actually matters across a long session.

~

Hooks Over CLAUDE.md for Anything That Must Always Happen

CLAUDE.md is advisory. Claude follows it most of the time. Hooks are deterministic; they run every time, without exception.

If something must happen on every file write (formatter, linter, security check) make it a hook. Don’t rely on Claude remembering to do it because the instruction is in CLAUDE.md.

The practical setup is a PostToolUse hook in .claude/settings.json that fires your formatter after any edit or write. I run this on every project now. It eliminates an entire category of “Claude forgot to format” issues that accumulate across a session.

Think of it the same way you’d think about deterministic gates in a production ingestion pipeline. If it matters, make it automatic. The principle is identical: you wouldn’t leave corpus deduplication as a guideline someone might follow. You’d enforce it.

~

Build Skills for Work You Do More Than Once a Week

A Claude Skill is a saved, reusable workflow that triggers automatically when the context matches. You define it once, refine it to the standard you want, and Claude applies it consistently without you re-explaining your preferences each time.

The candidates are obvious once you start thinking about it. I have skills for: generating blog post drafts from Claude Code session transcripts, creating PR descriptions, synthesising RAG performance analysis reports, and producing social content drafts formatted for LinkedIn, X, and Bluesky.

All of these used to be ad-hoc prompts I’d rewrite from scratch every time.

The content pipeline one is a good example. I run a weekly publishing workflow where Claude Code harvests session transcripts, structures them into draft blog posts, and pushes them to WordPress via the REST API. That entire sequence is encoded as a skill now. I don’t prompt it manually; I invoke it, review the output, and publish.

Personal skills live in ~/.claude/skills/ and are available across every project. Project-specific skills go in .claude/skills/. The trigger is contextual. Claude recognises when the situation matches and invokes the workflow without you calling it explicitly.

If you’re doing it twice a week with consistent output requirements, it should be a skill.

~

Use Subagents to Keep Contexts Clean

When I’m debugging something complex (a latency issue in a synthesis pipeline, vector corpus drift, an OAuth discovery bug in an MCP server) the worst thing I can do is run exploration and implementation in the same session.

Failed approaches accumulate. Claude starts referencing earlier dead ends. The context gets contaminated with things that didn’t work, and that pulls subsequent attempts in the same direction.

I had a situation diagnosing an OAuth discovery issue when integrating a .NET MCP server with VS 2022 GitHub Copilot Agent Mode. VS 2022 appends a /.well-known/oauth-protected-resource path to the configured URL. If your URL has a query parameter, it constructs a malformed path, gets a 404 back, and silently shows 0/0 tools with no useful error.

The fix, once found, was a middleware intercept in Program.cs. But finding it required reading VS 2022 output logs, cross-referencing the MCP SDK behaviour, and testing several hypotheses. Running all of that in the same session as the actual fix attempt would have been slower and messier than it needed to be.

Exploration in a separate CLI session, then ask Claude to summarise findings into a prompt that you can apply to a new “implementation” session.

~

Ask for Evidence, Not Confirmation

“It should work” is not a useful output. “Here’s the test run” is.

For any task where Claude is implementing or fixing something, prompt it to return evidence: the actual test output, the command it ran, what the command returned. Reviewing evidence is faster than re-running verification yourself, and it holds for sessions you weren’t watching while they ran.

This matters especially for unattended runs. A WebJob crawling thousands of URLs overnight and reporting “completed” means nothing without knowing how many vectors were written, whether deduplication fired correctly, and whether any documents were silently skipped.

I learnt this the hard way when a vector corpus went stale mid-crawl. The job reported no error, search kept returning results, and the problem wasn’t visible until the following morning. “Show me the output, not a summary of the output” is now a standing instruction.

Build the habit of asking: “Show me the test results, not a summary of them.”

~

Register Your MCP Servers Early

If you’re working with MCP servers (and if you’re doing serious AI engineering work in 2026 you probably are) register them at the start and don’t think about it again.

Claude Code supports dynamic tool loading, which means MCP server definitions only load when Claude actually needs them. Registering several doesn’t bloat your startup context. Add your project-specific MCP server, any Elasticsearch tooling, and anything else your stack relies on, so Claude can reach across the whole system without you copy-pasting API responses into context.

One pattern worth mentioning from .NET MCP work: [Description] attributes on your tool methods are not developer documentation. They are the instructions the AI uses to decide when to call the tool and what to pass in.

Vague descriptions produce inconsistent tool invocation. “Searches documentation” is not a description. “Searches the product documentation index and returns a synthesised answer with source references. Use this when the user asks a question about the product or API.” is a description. The difference in invocation reliability is significant.

~

Checkpoint Before Anything Destructive

Esc+Esc (or /rewind) opens a menu of every checkpoint Claude has created. You can restore the code, the conversation, or both.

Before any bulk operation (reindexing, schema migration, large-scale refactor) create a checkpoint. This applies directly to any work involving a vector store. When you’re managing a corpus of thousands of documents across JSON file and Elasticsearch backends, a chunker bug or a corpus clean-up operation that goes wrong is not a five-minute fix.

Having a checkpoint before Claude touches anything related to the ingestion sequence means you can try the aggressive approach and roll back cleanly if it introduces orphaned vectors or silently misses documents.

A concrete example: I was using Claude Code to work through a deduplication fix in a documentation crawler. The crawler had been running long enough that the vector store had accumulated zombie entries: documents that existed in the index but had no corresponding source, and orphans where the source had changed but the old vector was never cleaned up.

Claude’s proposed fix involved a clean-up pass across the entire corpus before re-crawling. Without a checkpoint, running that clean-up was an all-or-nothing bet. With one in place, I could let it run, verify the index state after, and roll back the code if the logic had missed an edge case, without having to reason about what state the corpus was in before we started.

The clean-up ran. It missed a category of orphans on the first pass. We rolled back, adjusted the logic, and ran it again. That cycle took twenty minutes. Without the checkpoint it would have been a manual corpus audit.

One caveat: checkpoints track file edits, not the effects of bash commands. Anything that modifies external state (Elasticsearch indices, database records, deployed infrastructure) isn’t captured. For those, your checkpoint is a backup and a confirmed rollback plan outside Claude Code entirely.

~

The Through-Line

The developers getting the most out of Claude Code are the ones who’ve stopped treating it as a smart autocomplete and started treating it as an agentic environment that rewards the same systems thinking you’d apply anywhere else.

A well-structured CLAUDE.md. Deterministic hooks for what must always happen. Skills for repeating workflows. Clean contexts. Evidence over assertions.

The model keeps improving. The structure around it is what separates consistent outputs from inconsistent ones.

~

Enjoy what you’ve read, have questions about this content, or would like to see another topic covered?

You can schedule a call using my Calendly link to discuss consulting and development services.

~

Courses

Check my AI courses. From developers to decision makers, these have you covered:

• Developing an Artificial Intelligence Strategy for Your Organization
• Aligning Generative AI with Business Cases
• Vector Databases & Embeddings for Developers

~