Anthropic released an engineering note this week detailing a migration from git to a source control system they call Scion.

Rather than paraphrase, I will just directly quote the top of the article.

At Anthropic, coding is no longer the bottleneck to building systems or doing research. Claude is able to autonomously iterate on research loops, micro-optimize complex programs, and build new services from the ground up at a speed and scale we haven’t seen before. The bottleneck, now, is all of the developer infrastructure built for human scale: source control, builds, and CI.

In May 2026, Anthropic averaged around 2,500 code changes merged per day; as of September, we merged over 30,000 per day. We don’t expect this rate of growth to slow down anytime soon; the latent demand for merging code is practically infinite, and every bottleneck we remove immediately leads to a further increase in the amount of code we produce.

They go on to detail that they have approximately 25 million CI checkouts a day. A git pull to a build machine was literally a serious bottleneck impacting ability to issue build artifacts and test the code. Their rate of change has also overwhelmed the conventional CI merge-queue model. They have moved toward post-merge and pre-deployment testing because they cannot effectively maintain a global merge-queue lock while tests are running.

I lived through the era of the Windows' organization moving from Source Depot (a Microsoft-customized Perforce) to git. At the time (early 2017), the Windows codebase was 3.5 million files and 300GB in size. The move to git created the largest git repository in the world. In order to accommodate the myriad teams with their own branches and the massive build infrastructure to support the daily builds and releases, it was literally impossible to pull all of those files everywhere. Microsoft's solution was to create a filter driver called "Git Virtual File System" which created a shadow entry for each file and then on-demand hydrated a file when it was accessed. A developer's workstation (or a build server) would issue a custom command, gvfs clone instead of git clone to accommodate this setup. ArsTechnica

This may go down in history as one of the last massive mono-repos to live in git. At the time, Microsoft was dealing with its inability to create more branches and service the needs of a more rapid delivery cadence for Windows releases (Windows insiders "beta" builds plus feature releases twice a year instead of every 3 years). Anthropic has lived the future of "development is online using agents" at a huge and unprecedented scale. git is hostile to this kind of development, necessitating a pull to a local or server machine.

The really eye-opening aspect of this change is not the massive increase in CI throughput (although that accomplishment is impressive) it is this quote in the Anthropic article:

Our team members still review every change request for the system, but they now examine the intent of the change as opposed to reading every line of code.

This is an admission that agents are changing code at a rate that is beyond the ability of humans to review the actual implementation. When we discuss "continuous integration" (CI), did we really mean that unreviewed code would merge to the authoritative store (repo) faster than the tests for that code can be run?

Scion as a project is impressive. Seven engineers using Claude Mythos preview and Claude Tag were able to build this system (and related elements such as the Antique code review system) and deploy it in five months. This kind of rapid development by small teams was literally impossible in the pre-agentic era. Claude wrote most of the code. What the human engineers did contribute was:

• Architectural foundation and trade-offs
• Monitoring violations of core system principles
• Rejecting inappropriate algorithmic shortcuts
• Preventing their adversarial review system from creating unnecessary complexity (human engineers' job was to literally say "no").

This is a description of a paired intellect system about which I have written previously. It is the combination of human insight and judgment and agentic-scale implementation speed that produces outcomes like this.

But the scale of this gives me significant pause. And angst. At even the current rate of code changes, human-level comprehension becomes extremely suspect. Anthropic may be building the very conditions that enable some of their more extreme AI safety concerns. 30,000 merged changes per day is a merge ~every 3 seconds, 24 hours a day. It is true that no one person understands all the code in a large code base. This was certainly true in Windows where a high double-digit number of architects were responsible for the overall coherence of the operating system. But this begs the following question:

Who is responsible for understanding the cumulative consequences of tens of thousands of individually reasonable changes?

Claude writes the code, Claude reviews the code, Claude resolves merge conflicts, Claude runs tests and evaluates results, Claude monitors the operational results. As humans operate at increasingly higher levels of abstraction, how removed are they from the intricate behaviors of the overall system that results?

In my former team, we had a mantra I call the "Aegis Way":

Understand the system, understand what could go wrong, have a plan for each thing that could go wrong.

At this scale, can humans fulfill the first requirement?

What I see before us is a self-amplifying software development system where humans surrender their ability to understand its behavior and then discover "the hard way" that their supervisory controls do not match the system that has been built.

This is a different kind of loss-of-control problem than has been popular in the media of late. And, in this case, the model does not need to be malevolent at all to create this disastrous situation. Models don't kill, systems do.

And then I worry about the "slope" of quality in a large software system. If the rapid introduction of changes causes a degradation in local and overall system quality, does the system have the metrics and controls to monitor that degradation? When you mix "Claude does everything" with "AI is effectively policing the AI", has the engineering organization then lost its ability to receive the value of independent assessment? Anthropic has convincingly scaled code production by an order of magnitude but has the ability to independently evaluate the quality of that system scaled commensurately?

But the worst problem, by far, is the assessment of architectural coherence in that large software system. Code quality and architectural coherence are distinct. Code changes reflect the behavior of a small part of the system. Architectural coherence is a global property. Consider the reality of a system where thousands of agents are working independently and concurrently:

• A new abstraction is created where an existing one should have been extended;
• Another bypasses an architectural boundary because "it is easier" to resolve the dependency locally;
• A third duplicates functionality (with non-identical code) because the relevant subsystem wasn't in its context;
• A fourth agent then takes a dependency on the new duplicate, establishing a precedent for the next agent;
• etc.

Every change is locally reasonable but the cumulative impact on the overall system is architecturally irrational.

We are now facing a fundamental asymmetry between sufficient local context to satisfy a local change and the much larger context required to evaluate whether that change preserves the architectural coherence of the system. Consider what happened in "the old days". A consequential change across multiple sub-systems was conceived, debated (perhaps heatedly) and then resolved by humans before and during implementation. The discussion (heated or otherwise) created a shared global context sufficiently large to understand the architectural implications of the changes. At the rate of change that is quoted in the Anthropic article, does it seem plausible that that degree of "context establishment" is occurring across all the changes sufficient to maintain architectural coherence? I am deeply skeptical that that is the case.

And this trend towards incoherence is self-reinforcing. The existing implementation becomes the evidence (context) to justify the next implementation. Ad infinitum. The system is not merely accumulating architectural debt. It is progressively losing the ability to distinguish architectural intent from architectural accident.

Where in an engineering system with this level of throughput is there room and opportunity for architectural checkpoints or evaluations? When observation of implementation becomes the de facto evidence of architecture, local errors propagate into global incoherency.

This becomes a difficult measurement question. What metrics can we use to know that the architecture that is implemented is the architecture we (humans) intended to build? This is not something that has traditionally been assessed with "metrics". It has been a direct product of human intent and observation. And hands-on implementation. We ceded the last item and our ability to observe the global impacts on this system are highly degraded.

Agents can make implementation scale. Who makes architectural understanding scale?

Human engineers have created some very large and intricate systems: Windows, Linux, the Apollo space program are just a few examples. Their track record, although highly imperfect, has been largely successful. We are dismantling the mechanisms that have sustained our collective understanding of complex systems, without establishing that fleets of agents can replace them. And we have not yet (even remotely) established that those fleets of agents are capable of building and maintaining systems of this complexity at scale and over long periods of time. The complex systems noted above were successful based on distributed but coordinated human understanding. That comprehension involved continuity, ownership, collective correction and, most importantly, institutional memory. A fleet of agents does not automatically possess any of these. In fact, I have been fond of writing that agents have perfect amnesia, necessitating memory systems which struggle mightily to encompass the global context that effective human system architects are required to possess.

And it is the human collaboration, messy as it is, that may well be the critical glue. A thousand intelligent agents do not necessarily constitute an intelligent engineering organization.

And the humans have somewhat perverse incentives in this equation. They are graded on rapid delivery of features that seem to fulfill the metrics that leaders are so fond of reviewing. But as I wrote above, we have no comprehensive metrics for architectural coherence. When a seasoned and respected developer says "we do not understand the cumulative consequences of these changes" but there are thousands of passing tests and metrics that are "green", will anyone listen? The perversion is that the lack of comprehensive metrics for architectural coherence means that the assertion that "something is wrong" is often difficult to prove and unheard by those who pull the levers of engineering progress.

Scion itself, somewhat ironically, provides a supporting argument for the arguments in this post. Scion was built by a small set of engineers toward a coherent architectural goal, and those decisions were comprehensible to that team. In fact, that team rejected changes that violated that architecture. However, that example is very different from the maintenance of architectural coherence across an enormous, heterogenous software system undergoing tens of thousands of changes per day. Scion's success story demonstrates what is critically necessary: human architects maintaining an understanding of the overall system. What Anthropic has not demonstrated is whether this type of discipline scales to the entire (very large) engineering organization.

Finally, there is a concept for the logical culmination of this degradation: epistemic debt. This is the growing difference between the complexity of a system and the organization's ability to understand it.

Senior engineers often like to describe examples of architectural debt. The direct result of this debt is reasonable changes become harder to execute. Epistemic debt means that the organization is losing its ability to understand why those changes are so difficult to execute. Or even whether a change is correct. (I was going to write "proposed change" but think how the Anthropic engineering system works. That change is not proposed, it is committed and verified later).

Consider this conceptual graph (generated by GPT):

In this conceptual illustration, the "red zone" is the gap between the blue line (system complexity) and the green line (human understanding). As the gap grows wider, organizations will retain the ability to deploy and operate that system, but not to understand it at nearly the level we have traditionally had with our complex systems.

It feels to me like the software industry has been barreling feverishly into another troubling asymmetry: between evidence and responsibility. Source control throughput has been increased by an order of magnitude supported by concrete metrics. But where is the evidence that the aggregate architectural quality of its overall system is improving rather than deteriorating? And whose responsibility is it to produce that evidence? We have already seen the evidence that agentic coding systems can produce software faster. But we seem content to assume that the resulting system remains architecturally sound.

The solution is obviously not to corral agents to human coding speed so we can "keep up." But it is our responsibility that as we increase change throughput, we must also maintain our ability to observe the architectural coherence of the totality of those changes. This is no small feat but as Amazon found out in March of this year, sometimes slowing down and instituting additional human review is the immediate remedy that a very experienced engineering leader (David Treadwell) must bring to bear. It is the responsibility of our most senior engineering leaders to create these epistemic evaluation systems, or we will learn the hard way that source-control scalability is not architectural scalability.