How We Use Claude Code on Client Projects: Rules, Setup and Where It Helps

Why clients ask about it

In the 30 days to 13 October 2026, Claude Code was named in 9 of the job posts our business development team logged, against 7 for Docker and 4 for GraphQL. Clients ask two opposite questions: "do your engineers use AI tools?" (they want the speed) and "will our code end up training someone's model?" (they want the safety). Both are fair. This post is the answer we give, written down so clients can hold us to it.

Rule 1: the client decides, in writing

We do not run AI coding tools on a client's code unless the statement of work or a written note says we may. Some clients want it on everything; some exclude specific repositories (payments, a regulated data store); a few say no. Whatever the answer, it applies to every engineer on the account and we record it in the project's onboarding notes.

Rule 2: commercial terms only, and know the data path

• Our engineers use Claude Code through company Team or API accounts under Anthropic's commercial terms, never personal consumer accounts. Anthropic's documentation states that it does not train generative models on code or prompts sent to Claude Code under commercial terms unless the customer opts in; standard retention for commercial accounts is 30 days (checked 13 October 2026).
• Where a client needs data to stay in its own cloud, Claude Code can run against Claude models on Amazon Bedrock or Google Vertex AI under the client's account, the same pattern we used for the AI features of GovDoc AI on Bedrock.
• Zero Data Retention exists for qualified Enterprise accounts and is enabled per organisation by Anthropic; if a client needs it, we confirm it is in place before work starts rather than assuming.

Rule 3: every repository gets a CLAUDE.md

Claude Code reads CLAUDE.md files at the start of each session: from the project root, from parent and subdirectories as it works there, and from the user's and the organisation's own files. We treat the project file as onboarding notes for any new engineer, human or not: build and test commands, the architecture in a dozen lines, naming and folder conventions, which files are generated, and the rules that must never be broken. This website is built the same way; its CLAUDE.md says where company facts and prices live, that prices must come from one pricing module, and that every new page goes through an SEO checklist before commit. Anthropic's documentation is clear that CLAUDE.md is context, not enforcement, which is why rules that matter also live in hooks and CI.

Rule 4: permissions and hooks do the enforcing

Rule 5: review AI code like a junior's code

AI-written code is reviewed to the same standard as any pull request, with extra attention to the failure modes we see most often: plausible-looking code that calls an API that does not exist, tests that assert the implementation rather than the behaviour, error handling that swallows exceptions, and changes far outside the task. The engineer who opened the pull request owns it; "the AI wrote it" is not an answer in review. We sometimes add an automated AI review pass on pull requests as a second reader, never as the only one.

Where it saves real time

• Codebase takeovers: mapping an unfamiliar repository, tracing a request from route to database, listing every place a table is written. It shortens the first week of a codebase takeover.
• Tests around legacy code: writing characterisation tests that pin current behaviour before we refactor it, which is the slow, necessary part of legacy modernization.
• Mechanical changes across many files: framework upgrades, renaming a concept, moving JavaScript to strict TypeScript file by file, replacing a deprecated SDK.
• Glue and boilerplate: API clients from an OpenAPI spec, admin CRUD screens, migration scripts, seed data.
• Investigation: reading logs and stack traces against the code to propose where a bug lives, with the engineer confirming.

Where we keep it on a short leash

• Architecture and data modelling: the AI can lay out options; a lead engineer makes and records the decision.
• Authentication, authorisation and multi-tenant isolation: written or line-by-line reviewed by a senior, with tests that try to break it. See our RBAC and audit logging guide.
• Payments and money movement: idempotency, webhooks and ledgers are human-designed; see Stripe webhooks done right.
• Anything regulated: HIPAA and PCI scope follows the client's policy and our security practices, whatever the tool.

Rescuing AI-built apps

More of the codebases buyers ask agencies to take over were themselves written with AI tools such as Lovable, Bolt, v0 or Cursor. The fix is not to avoid AI; it is to add what those projects usually lack: tests, a clear data model, access control enforced on the server, secrets out of the client bundle, and someone accountable for review. Our Lovable vs Bolt vs v0 comparison covers when a prototype from those tools needs engineers, and our vibe code cleanup service covers the audit and fixes.

What it means for cost

AI tools change how our engineers spend their hours, not our rates: senior engineers bill $25 to $41 an hour and dedicated engineers start from $4,000 a month. Where the tools save time on mechanical work, clients see it as more scope delivered per sprint. We do not publish a productivity multiplier, because it varies too much by codebase to be honest.

Sources

• Claude Code: data usage: https://code.claude.com/docs/en/data-usage (checked October 2026)
• Claude Code: memory and CLAUDE.md files: https://code.claude.com/docs/en/memory (checked October 2026)
• Claude Code: permission modes: https://code.claude.com/docs/en/permission-modes (checked October 2026)
• Claude Code: hooks: https://code.claude.com/docs/en/hooks (checked October 2026)
• Claude Code: security: https://code.claude.com/docs/en/security (checked October 2026)
• Claude Code: zero data retention: https://code.claude.com/docs/en/zero-data-retention (checked October 2026)
• Anthropic privacy centre: is my data used for model training: https://privacy.claude.com/en/articles/7996868-is-my-data-used-for-model-training