Featured image of post Built for human pace: what Anthropic's source control rewrite means for enterprise IT strategy
Copilot & AI

Built for human pace: what Anthropic's source control rewrite means for enterprise IT strategy

Anthropic went from 2,500 to 30,000 merges a day and rebuilt source control. What that means for architecture, review, agent identity and IT controlling.

Deutsch

In May 2026, Anthropic merged about 2,500 code changes per day into its monorepo. By September it was more than 30,000. Git and the mirror infrastructure around it could not keep up, so a team of seven built its own version control system and moved the entire monorepo onto it in five months (Anthropic Engineering).

Almost nobody reading this will build a version control system. That isn’t the point of the story. Every organization runs processes that were sized for the speed of people: change advisory boards, four-eyes approvals, access reviews, CI pipelines, budgets calculated in person-days. Once agents do a large share of the work, those processes become the bottleneck, and the question is which of them you redesign before they break.

TL;DR

  • Agents are becoming the main consumers of your systems. Architecture decisions should assume machine clients that are always online and call APIs at high volume.
  • Review and approval have to move from “a human looked at everything” to rules that decide where a human must look.
  • Every agent needs an identity, an accountable person and a cost center. Without those three you can neither govern nor budget agent work.

What Anthropic actually changed

The headlines say “Anthropic threw out Git”. The engineering post is more careful. The new system is called Scion, the review tool Antique. Anthropic explicitly says Scion is not a general replacement for git, because that would mean replacing the whole development toolchain. They published the design so that git platforms can adopt parts of it.

The numbers explain why they did it anyway. The main branch history is almost 100 GB, a compressed working copy more than 25 GB, and CI runs roughly 25 million checkouts per day. Git is designed for distributed clients that work offline. Anthropic’s clients are almost entirely agents and jobs that are always online. Scion moves the expensive work to the server: commits, merges, rebases, history and blame happen there, clients get sparse, virtualized checkouts that load files on demand, and much of the functionality is available through an API without any local repository. According to the post, the new infrastructure uses about 200 times less CPU and memory than the old git mirrors, and CI checkouts take seconds instead of minutes.

Three decisions in the post matter beyond source control:

  1. There is no merge queue with a global lock. Anthropic invested in post-merge and pre-deploy testing instead. Conflicts between concurrent changes happen, and Claude usually fixes them faster than a human would notice them.
  2. Antique can express semantic rules for approvals. A comment-only change gets treated differently from a change to sensitive logic, so human reviewers spend their time where it counts.
  3. Access control at repository and directory level was built in from the start, not added later.

Agents are the new primary client

The first lesson is about architecture. Most enterprise systems assume a person in front of a screen. Agents behave differently: they poll, they run in parallel, and they don’t take lunch breaks.

In Microsoft 365 you can see this today in Microsoft Graph throttling. Microsoft lists two typical causes: many requests across all applications in a tenant, and many requests from one application across tenants. Polling a resource and repeatedly scanning collections are named as patterns that lead to throttling. The recommended alternatives are delta queries and change notifications, and for bulk extraction Microsoft points to Graph Data Connect instead of the REST APIs (Microsoft Learn). SharePoint Online goes one step further: an application that keeps exceeding limits can be blocked entirely (Microsoft Learn).

That guidance was written for integration developers. It now applies to every agent that reads mailboxes, sites or Teams channels on someone’s behalf. When I evaluate an agent scenario, I now ask how it detects changes before I ask what it does. An agent that rescans a document library every ten minutes works fine in the pilot and becomes a problem when 40 departments copy it.

For your own systems the same principle applies in the other direction. If agents are going to be the main consumers of an internal platform, give it a proper API, change feeds and per-client limits. A web UI with a scraping agent in front of it is the git mirror of your organization: it works until the volume grows tenfold.

Review by intent instead of line by line

The second lesson concerns control processes. The Anthropic team still reviews every change, but they review the intent, not every line. Their main job, as they describe it, is telling Claude “no”: when it violates system constraints, or when it over-engineers in response to hypothetical concerns.

In regulated environments this is the uncomfortable part. Many change processes implicitly promise that a qualified person checked everything. At 30,000 changes per day that promise can’t be kept, and honestly it often wasn’t kept at 30 per week either. The CAB that approves a stack of changes in 45 minutes is mostly checking that the form is complete.

In my experience, auditors want evidence that changes are controlled and traceable. NIS2 asks for risk management measures that include security in development and maintenance; it does not prescribe that a human reads every line. That leaves room for a model that ITIL already knows as standard changes, applied to agent output:

  • Low risk (documentation, tests, formatting, configuration within defined guardrails): automated checks, no mandatory human review, full logging.
  • Medium risk (business logic, integrations): human review of intent and test evidence, with the agent’s summary as input.
  • High risk (authentication, permissions, data flows across trust boundaries, anything regulated): line-level review by a named person, the way it has always been.

What decides the tier has to be a rule, not a gut feeling. Anthropic models this in the review tool, and you can model it in branch protection rules, CODEOWNERS files or a Power Automate approval flow. The rule itself is the control that an auditor will want to see.

I would be careful with one part of the Anthropic approach: moving checks after the merge. For an internal developer platform that is a reasonable trade. For a system in a KRITIS environment where a faulty change can reach production directly, I wouldn’t do it. The safeguard has to sit before deployment, even if it no longer sits before the merge.

Every agent needs an identity and an owner

Anthropic built access control into Scion from day one, down to the directory level. In Microsoft 365 the equivalent is the identity layer for agents. Microsoft Entra Agent ID gives agents their own identities in the directory, created from agent identity blueprints. Every agent identity requires a human sponsor who is accountable for purpose, lifecycle and access reviews. If the sponsor leaves, sponsorship transfers to their manager. Conditional Access and access packages from entitlement management apply to agents as well (Microsoft Learn). As of October 2026, identity governance for agents is labeled preview, and the licensing depends on Microsoft 365 E7 or Agent 365 licenses; check the current terms before you plan with it.

On top of that, Microsoft Agent 365 provides the registry as one inventory of Microsoft and non-Microsoft agents, including counts of agents without owners (Microsoft Learn). I described the governance side in more detail in the post on the agent lifecycle.

The strategic point: an agent that runs under a shared service account or a person’s delegated credentials cannot be distinguished in the audit log, cannot be throttled separately and cannot be billed separately. Fixing that later for hundreds of agents is the kind of project nobody wants to fund.

Measuring agent work

The budget side breaks in the same way. Controlling in most IT organizations still calculates in person-days, and that model has no line for agent work. A practical way to close the gap is to route agent sessions through an AI gateway, so that every token and every hour of runtime can be assigned to a project and a repository and priced at real cost.

A feature that needed 20 days last year and 3 days of review plus agent runtime this year doesn’t fit that model. Counting agent hours is a start, but hours are an input metric. What you want to know is the cost per accepted change: tokens and runtime plus the human time for review, rework and the cases where someone had to say “no”. Without the human share, agent work looks cheaper than it is.

For Microsoft agents, Agent 365 observability collects activity data and is meant to support business metrics like usage and time savings (Microsoft Learn). That covers part of the picture. Coding agents outside Microsoft 365 need their own attribution, and that is where the gateway approach comes in.

Decisions for the next twelve months

Anthropic expects other organizations to run into this class of problem within the next six to twelve months. Even if your timeline is longer, these are the decisions I would make now:

  1. Inventory human-paced controls. List every approval, review and pipeline step that assumes a person and a working day. Mark which ones would break at ten times the volume.
  2. Introduce risk tiers for changes. Write down which changes need a human, which need a human for intent only and which need logging only. Make the rule machine-readable.
  3. Give agents their own identities. No shared service accounts, every agent with a sponsor, permissions through access packages with an expiry date.
  4. Design integrations for machine clients. Delta queries, change notifications and API budgets instead of polling and scraping.
  5. Attribute agent cost. Tokens and runtime per project, plus the human review time, from the first productive agent onward.

What I wouldn’t do is copy Anthropic’s tooling. Their problem was 25 million checkouts a day. Yours is more likely a change process that takes two weeks for a configuration change an agent prepared in ten minutes. That is the place to start.

References