Most engineers pick up Claude Code and use it like a faster autocomplete. Bugs get fixed. PRs get out. It works fine. The actual leverage does not show up until you change how you are using it, and that change is mostly about habits, not prompts.
The teams getting outsized results are not running a different model. They are running the same one with better instincts about when to clear, when to plan, what to put in front of it, and what to leave out.
Think in compute, not in messages
The first thing worth unlearning: Claude Code’s limits are not a chat allowance. They are a rolling compute budget measured in tokens, and the message you type is almost always the smallest piece of what you spend.
When you hit enter, Claude sees six layers: the system prompt (~4K tokens, cached globally), tool definitions (~5-8K tokens, cached globally), your CLAUDE.md (~2K tokens, cached per project), session context from files and outputs (grows over time), conversation history (re-sent every turn), and your actual prompt this turn (small, uncached).
The cost amplifiers: Model choice is the biggest lever. Opus runs 3-4x the cost of Sonnet. Use it deliberately. Peak hours are real: roughly 5-11am Pacific, the budget gets consumed 1.3-1.5x faster. Every connected MCP server adds 4-6K tokens overhead on every turn. Extended thinking can quietly double per-request cost. Long conversations cost more than they look.
Cost by task size: A one-line bug fix runs 5-15K tokens, mostly overhead. A medium feature is 30-80K, where planning upfront pays off. A real migration can blow past 150K. Split those across fresh sessions. The thread you do not clear is the bill you did not expect.
The three modes and the shortcuts worth building into reflex
Claude Code has three input modes, cycled with Shift + Tab.
Auto mode is the default. Claude plans and executes in one motion. Fine for bounded, well-specified tasks.
Plan mode makes Claude write out what it intends to do, which files, what steps, why, then stop. You read the plan, approve, then it codes. The right time to reach for Plan mode is exactly when you catch yourself saying “this is a quick one.” Small changes are where drift hides.
No-tools mode disables reads, edits, and shell. Use it for concept questions or design conversations where you would rather have Claude think out loud than touch anything.
Key slash commands: /init creates CLAUDE.md at the repo root, run once per project. /clear wipes conversation history and resets the token budget without touching files. /compact summarises old turns into a short preface. /cost shows approximate spend for the current session. /help lists commands and is worth re-running every few weeks.
Why /clear is the command people resist most: Clearing feels wasteful. The opposite is true. Cheap sessions are fresh. Expensive sessions are bloated with history nobody needs. The minute you switch features, accept unrelated diffs, or cross 80-100K tokens, just clear it.
CLAUDE.md is not documentation
The common mistake is treating CLAUDE.md like a README. Descriptive sentences tell Claude what is there. They do not tell it what to do or not do. CLAUDE.md should be rules written in the imperative.
Six categories that earn their place: Data access rules (“all DB calls go through repositories, never raw queries in controllers”). Logging conventions including negatives: what to log, what never to log, where PII cannot appear. Error handling: whether you wrap in an AppError type, whether re-throwing raw is forbidden. API contract rules: validation library, where validators sit, standard response shape. Testing: framework, file locations, naming convention, what done means before a PR opens. Deployment: every new env var must update .env.example or the PR gets bounced.
Lines to delete: “Use modern JavaScript” is vague. Replace with “ES2022, no var, async/await only.” “Be careful with deletions” is not a rule. “We should migrate to TypeScript someday” belongs in a tech-debt doc.
A two-line CLAUDE.md written as imperatives outperforms a two-page one written as prose. The fastest audit: read it out loud and list what Claude is forced to do or not do. If you cannot, it is not really a CLAUDE.md yet.
The four failure modes
Hallucination is the loud one. Claude invents an API, function name, or package that does not exist. You find out within seconds because the code throws. Annoying, rarely dangerous.
Drift is when the work wanders. You asked for a payment flow and ended up with a half-rewritten auth module because Claude touched something on its way through. Catch it on the diff review.
Scope creep is drift’s close cousin. Claude does what you asked and then a few things you did not. The diff is twice the size needed, and the extra changes look plausible enough to miss on first read.
Silent omission is the most dangerous and the one most people never name. Claude writes the API endpoint but skips the validator. It writes the test but only the happy path. The code compiles. The tests pass. The PR looks fine. And then a few weeks later someone finds an IDOR or auth bypass that was sitting there the whole time.
The fix for all four is the same: read the diff like a human wrote it. Not the explanation Claude offers in the chat. The actual code. “Apply” is not the default action. It is a choice you make.
Where Claude actually pays for itself: debugging
The flashy demos are always greenfield code generation. The compounding return is in debugging.
The 3-context rule: When you hand Claude a bug, send three things alongside the stack trace. First, the call site: the function where the error actually originates, not just the file the stack points at. Second, the inputs that triggered it: request body, env values, whatever was in play. Third, the recent diffs on that file or module. Git log -p –since=”yesterday” works fine. The cause is almost always in something that just changed.
Without these three, you are asking Claude to guess. With them, you are asking it to reason. The answer quality jumps in a way you can feel.
Pairing with git bisect: Bisect runs binary search through commit history, taking log2(n) tests to localise a regression. 1,024 commits resolves in 10 steps. Claude is good at the judgment call at each step when you give it the symptom and the diff between adjacent commits. A bisect that used to take half a day now takes about twenty minutes.
Cross-service debugging through MCPs: When a bug spans backend, queue, database, and a third-party API, the usual move is five tabs and copy-pasting. With MCP servers wired in for logs, DB, and HTTP, Claude can pull from each surface in one session and correlate signals you would otherwise correlate in your head.
Frequently asked questions
What is Plan mode in Claude Code and when should I use it?
Plan mode is toggled with Shift + Tab. It makes Claude write out its intended approach before writing any code: which files, what steps, why, then stops for approval. Use it for tasks with unclear scope, multiple files, or any time you describe a change as quick. Small changes are where scope creep and drift hide most reliably.
How does CLAUDE.md actually change how Claude Code behaves?
CLAUDE.md is read at the start of every session and treated as standing instructions. Imperative rules are followed throughout the session. Descriptive sentences are treated as background context and largely ignored. The file has outsized impact, but only when written as a rulebook.
Why do long Claude Code sessions produce worse results over time?
Every turn re-processes all prior turns. As session length grows, token cost per turn increases and Claude’s attention gets diluted across an increasingly large history. The fix is /clear between unrelated tasks and whenever you cross roughly 80-100K tokens. Clearing does not touch your files.
What is the most dangerous failure mode in production?
Silent omission. Claude writes the endpoint but skips the validator. The code compiles, the PR passes review, and the security gap ships. The mitigation is reading the diff like a human wrote it.
How does the 3-context rule improve debugging quality?
Raw stack traces give the symptom but not the cause. Adding the call site, the inputs that triggered the failure, and the recent diffs on the relevant module lets Claude reason rather than guess.
The bottom line
Claude Code is not magic. It is a compute-heavy tool that compounds with discipline.
The engineers getting the real productivity gains are not the ones with better prompts. They are the ones who have built habits around the prompt: managing the token budget, keeping CLAUDE.md imperative, reaching for Plan mode on small changes not just big ones, and reading every diff like a human wrote it. The tool is the same one everyone else is using. What compounds is the discipline.
GoTeams runs this playbook across every AI-assisted engineering engagement. The AI Bootcamp translates these habits into practical curriculum for engineers building with AI in production.
Leave a Reply