Adopting Claude Code across an engineering team is a configuration and review problem, not a licensing one. Three things have to be standardised before usage spreads: the instructions the repository gives every session, the permission rules that decide what runs without asking, and the verification step that proves an automated change actually landed. Pilot on one workflow with a number you already measure. Expect the first failures in review capacity and spend, not in code quality.
What "adoption" means once the seats are bought
Buying seats is a procurement decision. We covered that side of it in our guide to what to decide before Claude Enterprise seats: identity first, roles and spend limits before broad invitations, and a bill that follows behaviour rather than headcount.
The engineering side is a different problem, and it starts the day the first developer runs Claude Code in a real repository. From that moment your team has three new artefacts whether or not anyone decided to create them: a set of repository instructions, a set of permission rules, and a set of habits about what gets reviewed. Left alone, all three form by accident. Each developer's configuration drifts from everyone else's, and by the time someone asks why two engineers get different behaviour from the same repository, the answer is spread across files nobody has read together.
What should you standardise first?
Start with the file that loads into every session. Claude Code reads CLAUDE.md from the working directory and every directory above it, concatenating what it finds from the filesystem root down, so instructions closest to where the session started are read last. That means a monorepo can carry a root file for company-wide conventions and per-package files for local ones, without either overriding the other.
Two constraints from Anthropic's documentation should shape what you put in it. First, size: the guidance is to "target under 200 lines per CLAUDE.md file," because longer files consume more context and reduce how consistently the instructions are followed. Second, specificity: "Use 2-space indentation" is followed more reliably than "format code properly." A repository instructions file that has become a wiki page is worse than a short one, because it costs context on every session and buys less adherence.
When instructions only matter for part of the codebase, they belong in .claude/rules/ with a paths: frontmatter field, so they load when Claude reads matching files instead of on every session. It is easy to miss, and the symptom is an instructions file that grows because there is nowhere else to put API conventions that only apply under src/api/.
One thing repository instructions cannot do is enforce anything. The documentation is explicit that settings "are enforced by the client regardless of what Claude decides to do," while instructions "shape Claude's behavior but are not a hard enforcement layer." If a rule matters enough that a violation is an incident, it is a permission rule or a hook, not a line in a markdown file.
Who decides what Claude Code is allowed to run?
Permission rules live in settings files that stack in a fixed order. Highest precedence first: settings your organisation manages centrally, then the command line, then your personal project file at .claude/settings.local.json, then the shared project file at .claude/settings.json, then your user-wide file.
Three behaviours in that stack decide how a rollout actually goes.
Allow lists merge rather than replace. When several files set permissions.allow, Claude Code combines the lists. Your organisation's rules keep applying alongside a team's, unless an admin sets allowManagedPermissionRulesOnly. Nobody removes a rule by adding one somewhere else, which is usually what you want and occasionally a surprise.
Deny and ask apply immediately; allow waits for trust. Rules that block or prompt take effect as soon as the file is read. Allow rules from a committed project file, along with additionalDirectories, apply only after each teammate trusts the folder. So the person who commits a shared settings file and tells the team "you won't get prompts any more" is wrong until every teammate has trusted the repository.
Approvals default to private. When a developer answers "Yes, and don't ask again" to a permission prompt, the CLI saves that as an allow rule in their own .claude/settings.local.json. It is not shared, not reviewed, and not visible to anyone else. When two engineers get different behaviour from the same repository weeks into a rollout, these private approvals are the first place to look. The fix is boring: read the local allow rules in the first retro and promote the legitimate ones into the committed file, where the team can see them.
For rules that must hold regardless of what the model decides, use a hook. A PreToolUse hook runs before a tool call executes and can block it: exit 2 denies the call and writes a reason back. When several hooks match the same event, the most restrictive answer wins, in the order deny, defer, ask, allow. That is the layer for "never touch production credentials" — not the instructions file.
What breaks first?
These are the failures we have hit running Claude Code routines inside ATI, in the order they showed up.
A step is denied and the run reports success. This is the expensive one. One of our scheduled content routines ends by deleting a source record after publishing. The dry-run of that delete passed the permission check; the destructive flag did not. The script exited zero either way, so six consecutive daily runs reported a clean finish while nothing was deleted, and the backlog was only found when someone read the logs end to end. Nothing in the run was lying — the routine checked whether the call had been made, not whether the state had changed.
The correction is a rule worth adopting before you need it: verify the resulting state, not the call. After a routine deletes something, re-query for it and require "not found." After it publishes, fetch the live URL and grep for the text that should now be there. An automation that checks its own exit codes is checking the least informative signal available.
The instructions file becomes a document nobody reads. Ours grew past the point where anyone could hold it in their head, which is roughly the point where adherence starts to slip. Splitting path-scoped material into .claude/rules/ is a maintenance chore that pays for itself.
Review capacity becomes the constraint. Generation stops being the bottleneck within about a week. What replaces it is the number of changes your senior engineers can meaningfully review per day, and that number does not move because you bought a tool. Skip it and you get more merged code passing through reviewers who have started skimming. Decide the review gate before volume rises, while the queue is still short enough that anyone will admit to it.
Spend tracks behaviour, not headcount. On Enterprise seats, tokens are billed at standard API rates on top of the seat fee, so a forecast built from a headcount spreadsheet tells you the floor and nothing else. Long sessions, oversized context and retry loops are the drivers, which is why our operating cost guidance puts the review cadence for active deployments at weekly. Monthly is too slow to catch context bloat before it compounds.
A rollout sequence that survives a quarter
The order matters more than the timeline. Standardising instructions and permissions across a team of five is an afternoon; doing it across a team of fifty who each built their own configuration is a negotiation. Our Claude for business adoption work runs value, governance and enablement as parallel workstreams for the same reason: the control conversation is a design input, not a sign-off at the end.
Choose the pilot by what you can already measure. The qualifying question is not which team is keenest but which team has a number that exists today, was measured the same way twice before Claude arrived, and would be believed by a sceptic. Cycle time on a specific service, time from ticket to draft PR, hours spent on a recurring migration — any of these beat enthusiasm. The Claude Code for companies explorer shows how the same rollout looks across engineering, operations, QA and analytics, which helps when you are deciding where the second wave goes.
How do you measure adoption without fooling yourself?
On Team and Enterprise plans, the analytics dashboard reports "lines of code accepted, suggestion accept rate, daily active users and sessions." Connect the GitHub app and you also get contribution metrics: merged PRs containing Claude Code-assisted lines, labelled claude-code-assisted in GitHub. Enterprise plans can pull the same data through the Analytics API with a read:analytics key; for per-user token counts, OpenTelemetry export or the spend report is the route.
Read those numbers with the caveats attached to them. Anthropic states the contribution metrics are "deliberately conservative and represent an underestimate," attribution only considers sessions from 21 days before to two days after a merge, and code a developer substantially rewrote — more than 20% different — is not attributed at all. So the dashboard undercounts, and it undercounts most for the developers who edit heavily, which is the behaviour you actually want.
Treat those metrics as adoption telemetry, not outcome measurement. Lines accepted tells you the tool is being used; it does not tell you the team ships faster or that the code survives contact with production. The outcome number has to come from your own delivery data, which is why the pilot gate above requires a baseline measured before the rollout. Without it you will be arguing about a counterfactual for the rest of the year.
What to write down before you scale
Four artefacts, all of them short, all of them in version control:
- Repository instructions — conventions, build and test commands, the things a new teammate would need. Under 200 lines, path-scoped rules for the rest.
- A committed permission file — the shared
.claude/settings.json, with deny rules for anything that touches production, and allow rules that were promoted from someone's local file after review. - Enforcement hooks — for the two or three rules where a violation would be an incident.
- A verification convention — for every automated routine, what state is checked after the run, and what proves it. Not the exit code.
None of these are exciting and all of them get harder to introduce later. If you are choosing where to spend the first week of a rollout, that list is it — and if you are still deciding who owns the implementation after the strategy work is done, our note on choosing a Claude implementation partner covers that question directly.
Frequently asked questions
Do we need Claude Enterprise to roll out Claude Code across a team?
No. Claude Code runs on individual plans and through the API. What Enterprise adds for a rollout is centrally managed settings that developers cannot override, organisation-wide analytics, and the identity and provisioning controls covered in our Claude Enterprise rollout guide. Small teams often standardise perfectly well with a committed project settings file.
Where should permission rules live — the shared file or each developer's file?
Shared, in .claude/settings.json, committed to the repository. Personal files exist for genuine exceptions and are where the CLI writes approvals when someone answers "don't ask again," so they fill up on their own. Review them periodically and promote what belongs to the team.
How long should a Claude Code pilot run before we decide?
Long enough to collect the same measurement you took as a baseline, on the same workflow, with the same method. For most delivery metrics that is four to six weeks. Deciding earlier means deciding on adoption telemetry — sessions and accepted lines — which does not answer whether anything shipped faster.
What stops a developer from letting Claude Code run anything it likes?
Deny rules and hooks, not instructions. Deny and ask rules apply as soon as the settings file is read, and a PreToolUse hook can block a tool call outright by exiting 2. Instructions in CLAUDE.md are context, and the documentation is direct that they are not an enforcement layer.
How do we forecast the cost?
Not from seat count. Tokens are billed on top of seats at standard API rates, and consumption varies with session length, context size, tool calls and retries. Instrument a few weeks of real usage, then review weekly by workflow rather than reading the invoice total once a month.
Who should own the rollout internally?
One engineer with commit rights to the settings and instructions files, paired with whoever owns the delivery metric you chose. A committee will produce a document about the rollout. Someone who can merge a permission rule produces the configuration the team actually runs on.
How this article was produced
Written by the ATI implementation team. The configuration behaviours described here — settings precedence, permission rule merging, hook enforcement, analytics attribution — were verified against Anthropic's published Claude Code documentation on 9 September 2026. The failure modes are from ATI's own operating experience running Claude Code routines, including the silent no-op described above. AI assistance was used in research and drafting; a human owns every claim and recommendation in it.