Claude Code Best Practices From Real Production Use

[Operator’s read] I run Claude Code every working day across two businesses — a consulting brand and Pickleland, a pickleball facility in Pflugerville, TX — for everything from this blog’s publishing pipeline to code review on production Workers. This isn’t an intro to what Claude Code is. It’s the habits I’ve kept after months of actually running it, and the ones I dropped because they cost me more than they saved.

Table of contents

Open Table of contents

• Write CLAUDE.md as rules, not documentation
• What I delegate to a subagent versus keep in my own thread
• Context management is the daily discipline, not a one-time setup
• What I’ve learned not to let it do on its own
• Verify before you ship — Claude’s “done” is a claim, not a fact
• The operator’s bottom line
• FAQ
  • What should actually go in a CLAUDE.md file?
  • How do you decide when to trust Claude Code’s output without re-checking it?
  • Do you let Claude Code commit and push on its own?
  • What’s the single habit that’s saved you the most time?

Write CLAUDE.md as rules, not documentation

The first version of every CLAUDE.md I’ve written was too long, and every one of them got shorter over time, never longer. The mistake is treating it like a wiki page — background, philosophy, “why we do things this way.” Claude reads the whole file on every session whether the current task needs it or not, so every paragraph that isn’t an instruction is a paragraph competing for attention with the paragraphs that are.

What survives the edit is narrower: hard rules, ideally ones a test enforces so they can’t quietly regress, plus pointers to longer docs for the cases that actually need the detail. “Titles are under 60 characters” earns a line. The history of why that limit exists earns a link to a doc, not a paragraph in the file Claude re-reads every session.

The second thing I’ve added, and the one I didn’t expect to matter as much as it does: a short list of settled facts, written down once, with an explicit instruction not to re-investigate them. Early on, Claude Code would re-diagnose the same false alarm every few sessions — a flaky check, a known quirk in a build step — and burn a chunk of context re-deriving a conclusion I’d already reached. One line stating the verified fact and telling the agent to move on instead of re-opening the investigation cut that dead time close to zero. The rule I use: if you’ve explained the same “actually, that’s expected” twice, it belongs in CLAUDE.md as a fact, not as something you retype in chat a third time.

What I delegate to a subagent versus keep in my own thread

I’ve written the full decision framework for skills versus slash commands versus subagents separately, so I won’t re-run it here. What’s worth adding is the operator-level filter I actually apply before spawning one: can I state what “done” looks like in one sentence, and would I actually read the intermediate steps if they stayed in my main thread?

If the answer to both is no — the task is bounded and I only want the result — it’s a subagent. Translating this post into 12 languages is the clean example: each translation is independently checkable, the fan-out is exactly why the content pipeline runs a subagent per locale, and I’d never want 12 languages of intermediate back-and-forth cluttering the thread where I’m still deciding whether the English post is right.

If the task needs me to see the reasoning as it happens — a schema change where the third decision depends on what the second one turned up — it stays in my main thread. The failure mode I’ve actually hit is spawning a subagent for that kind of task anyway, getting back a clean summary, and then asking “wait, what did you actually find” three times because the summary dropped the one detail that mattered. When that happens twice on the same kind of task, I stop delegating it.

Context management is the daily discipline, not a one-time setup

The CLAUDE.md is the part people write once and forget. The context window is the part I manage every session, and it’s the one that actually determines whether the output is good.

• Read before you let it edit. Claude Code will happily propose a change against a file it hasn’t seen the full current state of. I make it read the file first, every time, even when I’m confident I know what’s in it — I’ve been wrong about “confident” often enough that this is no longer optional.
• Don’t let one session do two unrelated jobs. A thread that debugged a deploy issue for an hour and then pivots to writing marketing copy is dragging an hour of irrelevant tool output into every subsequent response. I start a fresh session instead of asking Claude to “forget the deploy stuff” — that instruction doesn’t remove the tokens, it just asks the model to ignore them, which it does imperfectly.
• Plan before you let it run. For anything with more than two or three steps, I ask for the plan first and read it before approving execution. Reading a five-line plan takes fifteen seconds. Discovering step three was wrong after step five already ran costs the rest of the afternoon.
• Big pastes are a cost, not a convenience. Dropping an entire log file or a full API response into the conversation when three lines of it are relevant burns context on the other 97%. I grep first and paste the match.

This is the same principle behind context engineering for AI agents generally — Claude Code just makes the cost visible sooner, because you’re the one watching the context fill up in real time instead of debugging it after the fact in a Worker log.

What I’ve learned not to let it do on its own

Every irreversible action — commit, push, publish, send, spend — sits behind an explicit approval step I execute myself, never one Claude Code decides to take because it judged the task complete. This is the same human-in-the-loop pattern I use everywhere else agents touch real consequences, and Claude Code is not an exception just because it’s running on my own machine instead of in the cloud.

The other thing I stopped doing: granting broad standing permission for destructive commands. rm -rf, force-push, skipping test hooks — none of these get a blanket yes. Each one gets asked for, every time, in context, because the one time I pre-approved something broad “to save time” was the one time the task drifted into scope I hadn’t actually reviewed. The five seconds a permission prompt costs is cheap insurance against the alternative.

Verify before you ship — Claude’s “done” is a claim, not a fact

This is the habit that’s paid for itself the most, and it’s the least glamorous one: I don’t trust a completion report. I run the actual check.

Claude Code will tell you a build passed, a test suite is green, a link resolves. Sometimes that report is generated from real output. Sometimes it’s a confident summary of a command that partially ran, or a check that returned early with nothing useful in it. The two look identical in the chat transcript. The only way to tell them apart is to look at the real output yourself — the same discipline behind the eval harness I use to ship agents: a task isn’t scored done because the agent says so, it’s done when the defined check actually passes.

In practice that means: run the build command and read its output, not Claude’s paraphrase of it. Open the file it says it edited. Click the link it says resolves. For content specifically, I re-read the draft adversarially against the rules I know are enforced — length limits, banned patterns, broken internal links — rather than trusting that Claude applied them correctly the first time, because it usually did and occasionally didn’t, and the cost of the occasional miss shipping to a live site is higher than the ninety seconds the re-read takes.

The operator’s bottom line

None of this is about trusting Claude Code less over time — it’s about being specific with where the trust actually needs to earn out. Short, enforceable CLAUDE.md files over long documentation. Subagents for bounded, checkable work, your own thread for anything where the reasoning matters as much as the result. Fresh context instead of a dragged-out session. Approval gates on anything you can’t undo. And a real check, read yourself, before anything you’ve delegated goes live. That’s the whole list, and it’s the one I actually run.

FAQ

What should actually go in a CLAUDE.md file?

Rules the agent needs to follow on every session, stated as instructions — not background on why the codebase looks the way it does. If a rule is enforced by a test, say so and let the test be the source of truth. Longer context belongs in a doc the CLAUDE.md links to, read only when the task actually touches that area, not re-loaded on every session by default.

How do you decide when to trust Claude Code’s output without re-checking it?

I don’t decide to skip the check — I decide how expensive the check is. A build command is nearly free to run yourself, so I always run it. A full adversarial re-read of a long document takes longer, so I reserve it for anything shipping to a live audience. The one thing I never skip is anything irreversible: publishing, committing, spending money.

Do you let Claude Code commit and push on its own?

No. Every commit and push is something I execute myself, after I’ve looked at the diff. Claude Code proposes the change; I’m the approval gate on anything that leaves draft state, the same rule I apply to every other agent I run.

What’s the single habit that’s saved you the most time?

Treating a completion report as a claim, not a fact, and running the real check myself. It sounds like it would slow things down. In practice it’s the opposite — catching a bad “done” in thirty seconds is faster than catching it in production three days later.

---

Related: Claude skills vs. slash commands vs. subagents · The agent stack I use to run 30+ production agents · Human-in-the-loop AI agents: when to build an approval gate · How to use Claude scheduled tasks

Want to run Claude Code like this in your own business? My AI Agents for Beginners course covers the build fundamentals this playbook assumes. The cowork program is where I teach the operating habits in a structured group. If you’d rather have the setup done for you, book a 30-minute session.