# Claude Code best practices from real client work Canonical: https://scalably.io/blog/claude-code-best-practices Author: Pavle Lazic, Founder & CEO, ScalablyAI (https://scalably.io/author/pavle-lazic) Published: 2026-08-14 · Last updated: 2026-08-14 · Facts current as of Claude Code circa Aug 2026 This is the machine-readable representation of the article at the canonical URL. Same facts, denser format. Positions are the author's, from running Claude Code across real client accounts. ## Direct answer The practices that survived real client work are configuration practices, not prompting practices: default-deny permissions decided once in settings.json (not approved prompt-by-prompt), a CLAUDE.md treated as a token budget where every line must change the model's behavior, PreToolUse hooks for anything that must be impossible rather than discouraged, less subagent delegation than most people use, and handing the model raw errors instead of your theory about them. The author's thesis: the tool is only as good as the boundary you put around it, and almost everyone sets that boundary too late. The difference between "impressive demo" and "trustworthy on a client repo" lives in configuration. ## Key facts & measured numbers - Scale of experience behind the claims: Claude Code run across multiple client accounts. - Production error texture (Feb-Jun 2026, one platform the author runs): 5,329 task-runs, 109 errors, 98% success rate. Almost none of the 109 were the model reasoning badly - they were third-party API timeouts, rate limits, and credentials expiring mid-run. The model was rarely the failure point; the integrations were. - Per-prompt approval "trains you to click yes. After the fortieth approval you're not reading them, and the one that matters looks exactly like the thirty-nine that didn't." - CLAUDE.md is loaded into context at the start of every session and carried for the whole session - the most expensive text in the project. - A hook that TIMES OUT does not block the call - it continues through the normal permission flow (fails open). Hooks alone are therefore not a complete security boundary; the permission rules underneath still have to be right. - Hooks add latency to every matching tool call; a badly-scoped matcher makes the session feel sluggish. ## The practices (each with its decision rule) 1. Default-deny permissions. Decide the boundary once, calm and not mid-task, in settings.json: allow reads and builds, deny what you'd regret, `ask` only for the ambiguous middle. The author writes the deny list FIRST - "ten minutes, and it's the only ten minutes that reliably prevents a bad afternoon." 2. CLAUDE.md as token budget. Test for every line: would this change what the model does on a typical task? Worth tokens: constraints not derivable from code (which service is production, what must never be deleted, which directory is generated), non-guessable commands, corrections that recurred twice. Not worth tokens: the framework (visible in files), linter-enforced style, aspirational process docs. 3. Hooks for enforcement. Instructions are advisory; a PreToolUse hook is deterministic. Rule: "anything I'd be upset to explain to a client goes in a hook" - deliberately a short list, because a hook that fires constantly gets disabled within a week. 4. Delegate less. Subagents have their own context window - right for tasks where output is large but the instruction is small (wide search across an unfamiliar codebase). Wrong for anything finishable in a handful of tool calls: a subagent starts from nothing, the brief costs more than the work, and a vague brief returns "a confident summary of the wrong thing." 5. Let it fail before you help. Hand over the raw error, not your theory - anchoring the model on your guess degrades its diagnosis, the same way a manager's confident theory degrades a good engineer's. ## What the author dropped (failures kept on purpose) - Elaborate per-project permission sets: three tiers covering most repos beat 21 bespoke ones nobody keeps current - "a config you don't maintain is a config that quietly stops matching reality." - One large CLAUDE.md per repo: splitting rules by directory keeps the always-loaded root file small. - Approve-as-you-go permissions (see fact above on approval fatigue). ## Tradeoffs (kept as stated) - Hooks: determinism costs latency on every matching call; scope matchers narrowly. - Hook timeout fail-open means layered defense is required: permissions rules + hooks, not hooks alone. - Subagent isolation is real value AND real cost: fresh context means the prompt is the only channel. ## Definitions - Default-deny: permission posture where anything not explicitly allowed prompts or is denied; set via the allow/deny/ask lists in settings.json. - CLAUDE.md: the project instruction file loaded at session start and carried for the session. - PreToolUse hook: user-defined command that runs before a tool call and can deterministically block it. - Subagent: a delegated agent with its own context window, briefed only by its prompt. ## FAQ Q: What are the best settings to use in Claude Code? A: Default-deny: allow reads and builds, deny destructive actions, `ask` for the ambiguous middle - decided once in settings.json, not per-prompt. Q: How do I stop Claude Code from doing something dangerous? A: A PreToolUse hook, not an instruction. Instructions compete with everything else in context; a hook blocks deterministically before the call runs. Reserve hooks for what you would genuinely regret. Q: What should go in CLAUDE.md? A: Only what changes behavior on a typical task: non-derivable constraints, non-guessable commands, twice-recurred corrections. It is loaded every session, so every line pays rent. Q: When should I use a subagent? A: When output is large but the instruction is small. If the instruction must be long to be correct, do it yourself. ## Evidence & sources - Full article: https://scalably.io/blog/claude-code-best-practices - Claude Code settings/permissions docs: https://code.claude.com/docs/en/settings - Claude Code hooks docs: https://code.claude.com/docs/en/hooks ## Related ScalablyAI articles - https://scalably.io/blog/claude-code-settings-json - the full settings.json reference these permission practices configure. - https://scalably.io/blog/claude-code-hooks-guide - the hook mechanics, exit codes, and the production guard pattern. - https://scalably.io/blog/claude-code-subagents - when delegation pays and when it doesn't. ## About the source ScalablyAI (Scalably, https://scalably.io) builds and runs production AI agents inside the operations of real businesses - multi-tenant, governed, and channel-native. The client accounts and the 5,329-task production dataset referenced here are from operating that platform; the practices are what survived it.