Practice — Claude Code Best Practices: Reliable, Cheap, High-Leverage Sessions (8 questions)

A teammate has been in the same Claude Code session for four hours. They started by asking Claude to add a caching layer to an API endpoint, then — while waiting — asked it an unrelated question about a Terraform module, then went back to the caching task. Now Claude keeps "fixing" the same cache-invalidation bug in slightly different ways each time, and each fix breaks something the previous fix had already handled.

1. Using the context-window mental model, explain mechanistically why this session is behaving this way.
2. What two concrete actions should the teammate take right now, and in what order?
3. What should they have done differently at the two-hour mark to avoid this state entirely?

A junior engineer asks Claude Code: "make the checkout page handle errors better." Claude edits five files, reports that error handling is "more robust now," and the engineer merges it without further review. Two days later, a customer report reveals that a specific payment-decline error now shows a raw stack trace instead of a friendly message.

1. Identify exactly what was missing from this workflow that would have caught the regression before merge.
2. Rewrite the original prompt so that it gives Claude a way to verify its own work, including at least one concrete acceptance criterion.
3. Beyond the prompt, name one process-level safeguard that should have been in place regardless of how the prompt was worded.

You have three tasks queued for a Claude Code session today:

• Task A: rename a poorly-named local variable in one function, in a file you wrote last week.
• Task B: migrate the notification service from polling to webhooks, touching an unknown number of call sites across the codebase.
• Task C: fix a typo in a log message string.

1. For each task, say whether you'd use plan mode, and justify it using the specific signals (not just "it's small" or "it's big").
2. Explain the actual mechanism by which skipping plan mode on Task B could cost more than the time plan mode would have taken.
3. If you started Task B without plan mode and, three files in, discovered a shared retry helper used by two unrelated services, what's the right move at that point?

A contractor is joining your team for two weeks to fix bugs in a Node.js service. They'll use Claude Code daily. Someone on the team suggests: "just add Bash(*) to the allowlist so they're not constantly clicking through prompts — it's only two weeks."

1. Explain concretely what Bash(*) allows that the team probably didn't intend, using the actual matching behavior of permission rules.
2. Propose a narrower permissions block (allow and deny) that removes most of the prompt fatigue for routine bug-fixing work without granting blanket trust.
3. Name one additional layer, beyond settings.json permissions, that would catch a mistake even if the allowlist above were somehow too permissive.

Your team's Claude Code spend for the month is far higher than expected. Looking at /usage across a few engineers' machines, you notice: one engineer runs a single session per day, left open for the entire workday, and asks a handful of questions spread hours apart. Another engineer defaults to Opus for everything, including small one-line fixes, and rarely uses subagents even for large log-reading tasks.

1. For the first engineer, explain the specific mechanism (not just "long sessions cost more") driving their higher-than-expected spend, including what happens after a multi-hour gap between messages.
2. For the second engineer, explain why defaulting to Opus for small tasks doesn't just cost more per token — connect it to the actual savings available.
3. Propose one concrete change for each engineer, and one thing you'd check with /usage//context to confirm the fix worked.

A team lead describes how a feature went wrong: "I asked Claude to 'add rate limiting to the API' in a session that had been open all morning working on unrelated bug fixes. It read a bunch of files, wrote a rate limiter, and said it was done. When we deployed, the limiter reset on every restart because it stored counts in memory, and it also throttled our internal health-check endpoint. We corrected it twice in the same session and the second fix reintroduced the first bug."

1. Identify three distinct best-practice violations in this account, each tied to a different part of this subject (not three instances of the same mistake).
2. For each violation, name the specific practice that would have prevented it.
3. Write the single opening prompt (after fixing the session hygiene issue) that addresses the other two violations at once.

A team lead lists four things they want Claude Code to help with this week:

• Job 1: a one-off, "why does this even work" investigation of an unfamiliar payments module before anyone touches it.
• Job 2: every engineer on the team keeps re-explaining the same multi-step "how we structure a new API endpoint" procedure to Claude in every session that adds one.
• Job 3: a nightly job that re-audits ~40 export paths across the codebase for a specific race-condition pattern, needs to be rerun with different pattern definitions over time, and should keep an adversarial review loop going without anyone watching.
• Job 4: a genuinely ambiguous bug where three different engineers each have a plausible but competing hypothesis, and the team wants them investigated at the same time rather than one after another.

1. For each job, name the orchestration primitive (subagent, skill, agent team, or dynamic workflow) that fits best, and justify it using what actually distinguishes that primitive from the others — not just "it's small" or "it's big."
2. Job 2's procedure could technically be pasted into CLAUDE.md instead of built as a skill. Explain the concrete cost of that choice as the team adds five more procedures like it.
3. If the team lead mistakenly assigned an agent team to Job 1 "to be safe," what would that actually cost them, beyond it being unnecessary?

An engineer wants to leave a headless run going overnight in a large monorepo: claude -p "find and fix every call site still using the deprecated retry helper across packages/api and packages/web, commit each fix", run in auto mode, unattended. They plan to check the results in the morning.

1. Identify three distinct gaps in this plan as described — one about what the run is allowed to touch, one about how it knows it's actually done, and one about the codebase's scale — and explain the concrete failure each gap could cause by morning.
2. Propose a hardened version of the command and setup that closes all three gaps. Be specific about flags, settings, or scoping mechanisms, not just "add safety."
3. The engineer says: "auto mode already reviews every action, so I don't need an allowlist too." Explain concretely why that reasoning is incomplete.