What Changes When a Whole Team Adopts Claude Code, Not Just One Developer

One installer, two different tools

A single developer adopting Claude Code is a simple story: install the CLI, run it in a terminal, form habits over a few weeks. A team adopting it is a different kind of event, and it is easy to overstate how automatically the first turns into the second. The product genuinely ships team-level primitives — a project memory file, a settings hierarchy with an enforced organizational layer, and a code review product built for pull requests a machine helped write. None of those primitives do anything for a team until someone deploys them as infrastructure: checks a file into the repository, writes a policy an individual cannot override, wires a reviewer into the pipeline everyone’s pull requests pass through. Until then, “the team uses Claude Code” usually means five or six engineers each quietly built their own private CLAUDE.md, each approved their own tool calls, and each reviews agent-authored diffs by instincts that, as this article works through, do not transfer cleanly from reviewing a colleague’s work.

This article traces three specific shifts that separate a team of individuals who happen to run the same CLI from a team that has actually adopted Claude Code as shared infrastructure: a memory file that means something only once it is versioned, a permission model that means something only once an administrator — not each developer — authors it, and a review process rebuilt around the fact that a meaningful share of an incoming diff was never typed by the person whose name is on the pull request. Throughout, the goal is to keep four kinds of claim visibly separate: what Anthropic’s documentation specifies as a mechanism, what Anthropic and its customers say about their own results, what independent researchers and reporters have measured, and where this piece is doing its own analysis of what those measurements imply.

A file that only means something in version control

Claude Code reads project instructions from a file called CLAUDE.md, loaded automatically at the start of every session alongside a self-updating auto-memory system the tool writes to itself ^[1]. The documentation is explicit that this file has a scope hierarchy, and that the scope is the whole point: an organization-wide managed policy file sits above everything and cannot be excluded by an individual; a personal file at the user’s home directory applies to that one person across every project they touch; a project file at the repository root is described in the documentation as holding instructions “shared with your team through version control”; and a local file, meant to be gitignored, holds one person’s private preferences for one project ^[1]. Only one of those four locations is a team artifact by construction. The rest are either an individual’s private configuration or an organization’s policy imposed from outside the team, and Anthropic’s own best-practices guidance is direct about which one a team should actually use: “Check CLAUDE.md into git so your team can contribute. The file compounds in value over time.” ^[3]

That instruction only does real work once a team follows it, and the documentation is equally direct about what belongs in the file once they do: build and test commands a new hire would otherwise have to ask about, coding standards that differ from the language’s defaults, repository etiquette like branch naming and merge conventions, and architectural decisions specific to that codebase — not things Claude can already infer from reading the code, and not long tutorials ^[3]. The heuristic Anthropic gives for what earns a line in the file is worth repeating because it is the same heuristic that separates a personal notebook from a team artifact: add something when “a new teammate would need the same context to be productive” ^[1]. A rule that only ever mattered to the person who wrote it belongs in their own gitignored local file, not in the version-controlled one everyone reads.

Two structural details matter for teams specifically, beyond the basic hierarchy. First, CLAUDE.md is explicitly advisory rather than enforced: “Claude treats them as context, not enforced configuration. To block an action regardless of what Claude decides, use a PreToolUse hook instead.” ^[1] A shared CLAUDE.md is closer to a style guide a team has agreed to than to a rule a compiler enforces — useful, but it can be misread or deprioritized in a long session, the same way a human might skim past a contributing guide. Second, for organizations bigger than one team, the documentation provides .claude/rules/ directories that can be scoped to specific file paths so instructions only load when relevant, symlinked shared rule sets so multiple repositories can point at one canonical source, and a claudeMdExcludes setting so an engineer in a large monorepo isn’t forced to load every other team’s conventions along with their own ^[1]. None of that machinery matters to a lone developer working in one repository. It exists specifically for the case where “the team” is actually many teams sharing infrastructure, which is the condition under which a memory file stops being a convenience and starts being something closer to a linter configuration: read by every session, diffed like code, and, per Anthropic’s own troubleshooting guidance, something to “review when things go wrong, prune it regularly, and test changes by observing whether Claude’s behavior actually shifts” ^[3].

Permissions as policy, not preference

The same split between “individual configuration” and “team artifact” runs through Claude Code’s permission system, and it maps onto the same four-tier hierarchy: an enforced organizational layer, a personal layer, a project layer, and a local override layer, resolved in that order of precedence with managed settings always winning ^[2]. What changes for a team is not the mechanism but who is allowed to author which layer. A project’s .claude/settings.json is, in the documentation’s own words, for “team-shared settings (permissions, hooks, MCP servers)… checked into source control and shared with your team,” while .claude/settings.local.json is gitignored specifically for “personal overrides for a specific project” and “testing configurations before sharing with the team” ^[2]. That project file is where a team writes down which commands are pre-approved, which are blocked outright, and which still require a human to say yes — the kind of policy that used to live only in each developer’s muscle memory about what felt safe to click through.

Above that sits a layer individual developers cannot touch at all. Organizations can deploy a managed-settings.json file through mobile device management, Group Policy, or configuration tools like Ansible, to fixed filesystem locations on every machine, and the documentation describes this scope as being “for security policies that must be enforced organization-wide” and “compliance requirements that can’t be overridden” ^[2]. Specific managed-only controls make the point concretely: allowManagedPermissionRulesOnly strips user and project settings of the ability to define permission rules at all, so only the managed policy applies; allowManagedMcpServersOnly restricts which external tool integrations can be connected; and enforceAvailableModels restricts which models can be selected ^[2]. A parallel claudeMd key even lets an organization inject managed behavioral instructions directly into every session without deploying a separate file ^[1]. The documentation’s own summary of the division of labor is a clean one: settings enforce technical limits regardless of what the model decides to do, while a managed CLAUDE.md shapes behavior without technically preventing anything ^[1].

What this buys a team, in practice, is a permission posture that an administrator authors once, checks into a repository or deploys through existing device-management tooling, and can audit — as opposed to a posture that exists only as an aggregate of individual developers’ judgment calls about what looked safe to approve at two in the afternoon. Whether an organization actually uses that capability is a separate question from whether the capability exists; the gap between a documented mechanism and an organization choosing to deploy it recurs throughout this article, and it is exactly the gap that separates a team that has adopted Claude Code from a set of individuals who each installed it.

What changes in review once the diff has a co-author

The clearest place to see why team-level configuration matters is code review, because this is where the consequences of skipping it land hardest. Anthropic has published its own internal numbers here, and they are stated plainly: “As of May 2026, more than 80% of the code we merge into Anthropic’s codebase was authored by Claude,” up from the low single digits before Claude Code’s release in February 2025 ^[5]. That figure has been reported independently as well, alongside the detail that engineers at the company were merging roughly eight times as much code per day in the second quarter of 2026 as in 2024 ^[12]. What matters for this article is not the percentage on its own but what Anthropic says happened next: “human code review has become a new bottleneck,” which the company frames explicitly as “one signature of Amdahl’s law” ^[5].

That framing is worth making precise, because it is a structural claim, not a figure of speech. Let $p$ be the share of a change’s total cycle time that code generation itself used to consume before Claude Code, so $(1-p)$ is the share consumed by review and everything else. If generation alone speeds up by a factor $g$, total cycle time scales as $(1-p) + p/g$, and the achievable speed-up in total cycle time is

Amdahl’s law was originally about parallel processors, not engineering teams, but the constraint has the same shape: a serial bottleneck that does not scale caps the benefit of accelerating everything around it, no matter how large $g$ gets. For a team, review is that bottleneck.

Anthropic’s own response was to build an automated reviewer and check its value against history: “an automated Claude review of every change to our codebase would have caught roughly a third of the bugs behind past incidents on claude.ai before they ever reached production” ^[5]. That is a vendor’s retrospective claim about its own tool catching its own past mistakes — a self-reported estimate, not an independently audited figure — but it is consistent with what independent parties separately report about the shape of the problem across the industry, not just inside one company.

GitHub’s own engineering blog, describing the state of review broadly across its platform rather than any one vendor’s tool, reports that agent-related code review activity has processed more than sixty million reviews and grown roughly tenfold in under a year, and that more than one in five code reviews on GitHub now involves an agent ^[9]. The same reporting flags a failure mode worth taking seriously: reviewers report feeling better about approving agent-generated pull requests even when independent research finds those changes carry more redundancy and technical debt per change than human-written code, because “the tests passed. The code was clean. You merged it.” ^[9] A clean-looking diff with passing tests can still be quietly worse for a codebase’s long-term health than a messier one — a reviewer optimizing for how a diff feels to approve is not optimizing for what the codebase needs.

Independent, large-sample data on code quality gives that concern some empirical weight. GitClear’s analysis of over six hundred million code changes between 2023 and 2026 found cross-file reuse down by roughly a third over the period, block-level code duplication up 81% since 2023, and the share of changes that involved moving or refactoring existing code falling from about a fifth of all changes in 2022 to under four percent by 2026 ^[10]. None of that shows up as a failing test. It shows up as a codebase that gets harder to change six months later, which is exactly the kind of cost a reviewer skimming a green build has no direct way to see.

Review capacity data points in a related but distinct direction: not toward what gets missed, but toward what gets delayed. LinearB’s benchmarking of over eight million pull requests found that AI-generated pull requests wait roughly four and a half times longer for a reviewer to pick them up than unassisted ones, even though once picked up they are reviewed about twice as fast; the same data set found AI-generated pull requests accepted at a rate of 32.7%, against 84.4% for manual ones ^[11]. Read alongside Anthropic’s own bottleneck language, this suggests the constraint sits less in review speed than in review attention — the same scarce resource getting rationed differently once the queue in front of it changed composition.

Academic work on a narrower, more directly comparable slice of the same question adds a useful correction against overreading any of this as an argument against agent-authored code generally. Watanabe and colleagues studied 567 pull requests authored with Claude Code across 157 open-source repositories and found 83.8% were eventually accepted and merged by maintainers — a healthy acceptance rate on its own — but only 54.9% of those merged pull requests were integrated without further human modification, with the rest needing revisions for bug fixes, documentation, and project-specific conventions before they were acceptable ^[8]. Put together with the GitHub and LinearB data, the fair summary is not that agent-authored code fails review at unusual rates. It is that review is doing more of the actual work of making the code fit the project than a “looks done, tests pass” heuristic will register, and a team that has not deliberately redesigned its review process around that fact is relying on individual reviewers to compensate for it unaided.

The tool’s own answer: a review policy that lives in the repository

Anthropic’s response to this bottleneck, at the product level, is a code review feature built specifically for the case where a fleet of specialized review agents examines a pull request in the context of the full codebase, tags findings by severity, and posts them as inline comments without approving or blocking the pull request itself, so existing human review workflows stay intact around it ^[4]. It is currently a research preview available on Team and Enterprise plans, set up once by an organization owner who installs a GitHub App and chooses which repositories and which review triggers — on every pull request, on every push, or only when manually requested — apply to each one ^[4].

The detail most relevant to this article’s argument about team-level configuration is how the tool is customized. It reads a repository’s existing CLAUDE.md and treats newly introduced violations of it as low-severity findings, which means the same file a team already checked in for authoring conventions does double duty as review guidance ^[4]. But teams that want to change what gets flagged, and how strictly, are pointed to a second, review-specific file: REVIEW.md, described in the documentation as being “injected into the system prompt of every agent in the review pipeline as the highest-priority instruction block,” letting a team redefine what counts as a blocking-severity finding, cap how many minor style comments a single review posts, exclude generated or vendored code entirely, and add repository-specific checks such as requiring an integration test on every new route ^[4]. That is a genuinely new kind of artifact: not a coding-style file and not a permissions file, but a version-controlled statement of what this specific team wants a reviewer, human or automated, to actually care about. Cost is metered per review rather than bundled into a flat subscription, averaging fifteen to twenty-five dollars and scaling with pull request size, with an organization-level spend cap administrators can set ^[4].

Whether a REVIEW.md-style file solves the deeper, codebase-level problem GitClear’s and LinearB’s data describe is a separate, open question: a reviewer tuned for logic errors and security flaws is not obviously well-suited to noticing that reuse is quietly declining across hundreds of unrelated pull requests. What it unambiguously provides is the same thing CLAUDE.md provided for authoring conventions — a place for a team’s judgment to live as a diffable, version-controlled artifact rather than an assumption each reviewer carries around inconsistently.

What the evidence on adoption actually shows

Two very different kinds of evidence exist about what happens when organizations roll Claude Code out at scale, and keeping them separate matters more here than almost anywhere else in this piece.

The more evidentially load-bearing one is independent. Researchers at Microsoft Research tracked adoption, retention, and merged pull-request throughput for tens of thousands of engineers across a four-month rollout of Claude Code and GitHub Copilot CLI in the first third of 2026, using direct developer telemetry rather than survey self-report ^[7]. Their central finding is that adopters “merged roughly 24% more pull requests than they would have otherwise,” a lift that held across the full observation window rather than fading after an initial novelty period ^[7]. Two other findings matter as much as that headline number. On how adoption spread inside an organization with the authority to mandate a tool: “first use spread primarily through social networks, not top-down mandate,” with retention correlating more with an engineer’s pre-existing coding activity than with demographics ^[7] — a useful data point against treating enterprise rollout as primarily an org-chart problem solved by an announcement from leadership. And the researchers state their own result’s limits rather than overselling it: “a merged PR is not the same as the value it delivers” ^[7], precisely the caution this article’s review-section evidence would suggest is warranted. The same study notes token spend scaling into the millions of dollars annually at that scale — a cost-governance problem downstream of the adoption pattern itself.

The second kind of evidence is Anthropic’s own, and it should be read as exactly that: a vendor’s published account of its customers’ results, not an independently verified data set. Anthropic’s 2026 report on agentic coding describes Zapier reaching 89% adoption across its organization with more than 800 internally deployed agents, describes TELUS building over 13,000 custom AI solutions while shipping code 30% faster and saving a claimed half a million hours, and describes Rakuten engineers using Claude Code to complete an activation-vector-extraction task inside a twelve-and-a-half-million-line codebase in seven hours of autonomous work with 99.9% numerical accuracy ^[6]. The same report includes a figure that cuts against a simple “full autonomy” narrative, worth citing because it does not flatter the vendor unconditionally: developers reported using AI in roughly 60% of their work while being willing to fully delegate only 0% to 20% of tasks without supervision ^[6]. These are specific numbers tied to named customers, more informative than generic marketing language — but they remain figures selected and published by the company selling the product, gathered from customers with a commercial relationship to it, without the independent methodology section the Microsoft study provides.

Set side by side, the disagreement between these two bodies of evidence is not about whether adoption happens or produces more shipped code — both agree it does. It is about what “more shipped code” is evidence of. The Microsoft study is explicit that a rise in merged pull requests is a throughput proxy that may or may not track delivered value, and the review-layer evidence earlier in this article — GitClear’s duplication and reuse figures, LinearB’s lower acceptance rate for AI-generated pull requests, GitHub’s warning about approval bias — supplies concrete reasons that gap could be real. The vendor case studies report outcomes without the same instrumentation around whether they correspond to code that held up over time. Neither contradicts the other outright; they measure different things at different levels of independence, and a reader deciding how much organizational change to bet on Claude Code adoption should weight them accordingly rather than averaging them into one number.

Predictions

These are forecasts, kept explicitly separate from the sourced evidence above. Horizon: August 2028.

One. Version-controlled, review-specific policy files in the shape of REVIEW.md — distinct from general coding-convention files like CLAUDE.md — become a standard convention across teams using any AI code-review tool, not only Claude Code Review. Assumption: teams that adopt automated review discover that authoring conventions and review priorities need to be tunable separately. Indicator: competing review products converge on a similarly scoped repository file. Disconfirmed if by 2028 a single shared conventions file still does both jobs, with no separate review-policy artifact in wide use.

Two. Admin-authored, non-overridable permission policies — the managed-settings model — become the default deployment mode, rather than an optional hardening step, at organizations with more than five hundred engineers. Assumption: the cost and audit pressure the Microsoft study documents around token spend generalizes to pressure for centralized, inspectable policy. Indicator: enterprise sales materials present managed policy as the recommended starting configuration rather than an advanced option. Disconfirmed if 2028 enterprise deployments still predominantly rely on per-developer or per-project configuration, with managed policy used only for narrow compliance carve-outs.

Three. Industry benchmarking of AI-assisted engineering shifts away from pull-request-count and velocity metrics toward ones that capture downstream cost — defect rates, rollback rates, or a maintainability signal like GitClear’s — because the throughput-versus-value gap this article describes becomes visible enough in production incidents to force the change. Assumption: the maintainability signals already visible in 2026 data continue rather than reverse. Disconfirmed if 2028 benchmarking reports still rely primarily on merged-PR or lines-shipped metrics without a paired defect- or maintainability-adjusted figure.

What to take away

None of the three shifts this article traces — a memory file that only functions as a team artifact once it is checked into version control, a permission model that only functions as policy once an administrator authors it rather than each developer, and a review process only built for agent-authored volume once someone deliberately rebuilds it — happens automatically when a team installs Claude Code. Each is a documented, available mechanism ^{[1, 2, 4]}, and each requires a specific, visible decision by the team to actually use it as designed. The independent evidence on what happens when organizations make that decision is genuinely encouraging on throughput and genuinely unsettled on whether throughput is the right thing to be measuring ^{[7, 10, 11]}. A team that adopts the configuration layer without adopting a way to check whether the resulting code holds up has not really finished adopting the tool; it has only made the individual habits of five or six developers faster, which is a smaller and different achievement than the one usually being claimed.