Don’t inherit someone else’s bottleneck

Anthropic published an impressive engineering story about replacing Git with Scion. The response should be to examine its architectural choices. Too often, our industry treats a prominent company’s solution as permission to stop asking why. Once Anthropic describes a problem as a consequence of agent development, everyone else starts preparing to inherit it.

I have spent enough time working with customers at GitHub and GitLab to question that reflex. I have seen customers handle 30,000 daily merges on existing infrastructure without additional changes. That does not make their workloads equivalent to Anthropic’s. It establishes why the headline number cannot explain the bottleneck on its own. We need to understand how the work is organized and what the underlying system must coordinate.

In its Scion article, Anthropic reports more than 30,000 daily merges, nearly 100 GB of main-branch history, and roughly 25 million daily CI checkouts. Its response moves source-control operations server-side and makes working copies optional and sparse. Those are concrete answers to an expensive workload. They also invite a more fundamental question: why does this workload have this shape?

Why does collaboration require a monorepo?

I encountered the other side of this problem at GitHub and GitLab. One intent could require changes across five repositories. Each repository supplied its own review surface, checks, discussion, and merge decision. Someone still had to establish that the five changes collectively satisfied the original purpose. Five individually acceptable pull requests could leave the overall work incomplete.

A monorepo makes that coordination easier by bringing the files and review into a common boundary. That is a legitimate benefit. But one repository can contain many applications, services, libraries, and independently deployed components. Sharing a root directory does not make them one application, and it does not eliminate the relationships among them.

Agents face the same coordination requirement. When an agent struggles to discover dependencies or coordinate work across repositories, consolidating everything can make the environment easier to navigate. Before accepting consolidation as the requirement, however, we should ask whether the missing capability is a shared directory or an explicit model of the work.

I am not claiming Anthropic adopted its monorepo because its agents could not collaborate. Its article does not establish that. I am challenging the assumption that other organizations should make their repository boundaries compensate for limitations in agent collaboration and review.

The scope of an intent should determine the scope of review. Repository layout should not decide how much of that intent our tools can understand.

A folder selection cannot define the change

Once enough projects share a repository, we need ways to avoid giving every worker everything. Sparse checkouts, virtual filesystems, caches, and server-side operations address real costs. Anyone who worked with earlier client-server version-control systems will recognize the architectural instinct to move expensive work away from the client.

But CI needs more than a convenient selection of folders. A service change might depend on a shared library, a generated client, a schema, and tests owned by another team. The useful input is the dependency closure required to validate the change, including the exact states of the participating components.

A build system can resolve declared build dependencies. The broader acceptance decision also needs to establish which proposed changes belong together, which intent they satisfy, and whether the evidence covers their combined effects. Making retrieval cheaper does not supply those relationships.

This is where a poor representation of change becomes an operational bottleneck. If relationships remain implicit, people and agents must repeatedly reconstruct them. As activity increases, so does the cost of that reconstruction. Faster storage and transport can relieve the pressure while leaving its architectural source intact.

Count the work before declaring the limit

Consider an illustrative organization with 1,000 engineers and 30,000 daily merges. That is 30 merges per engineer. With ten agents supporting each engineer, it is three merges per agent. These are assumptions for understanding the arithmetic, not claims about Anthropic’s staffing or workflow.

Thirty reviews still require judgment. Their difficulty depends on what the reviewer receives. Thirty investigations through diffs, conversations, and disconnected test results impose a different burden from thirty bounded changes with explicit intent, dependencies, impact, and verification evidence.

Atomic commits are good practice because each should express a coherent change. Line count alone cannot establish safety: two lines can alter authorization across an application. We need to understand the affected behavior and dependent components, rather than mistake a small diff for a small blast radius.

Anthropic says its engineers now review intent rather than every line, and that it has invested in post-merge and pre-deploy testing as conventional merge queues struggle. Reviewing intent raises the right requirement. The question is how the system connects that intent to the exact change and the evidence supporting acceptance.

Atomic changes the primitive

Atomic is an alternative to this model. We make folders, binaries, and closures first-class citizens because agents need to work with meaningful parts of a software system without inheriting the entire repository as their unit of coordination. A folder is an object the system can represent and relate to change. A binary is a versioned part of the software state with dependencies and provenance. A closure establishes the records and dependencies required for a particular state.

Those distinctions matter together. A service might consume a compiled library produced elsewhere, share a schema with another application, and depend on changes still being evaluated. The system needs to represent the participating source, folders, binaries, and their relationships. Putting them under one root does not establish those relationships. Splitting them across repositories should not make the relationships disappear.

Atomic’s semantic change graph connects intent, acceptance criteria, tasks, code entities, evidence, and review. Its causal change graph records patches and their dependencies. Provenance preserves how the work happened. A view resolves the relevant records into a state defined by its closure. The semantic relationships explain the work and its impact; the causal dependencies establish what produces the state. These are distinct structures that give collaboration and verification something explicit to operate on.

This changes what we ask the infrastructure to do. An agent needs the context and state required for its work. CI needs the closure required for validation, including the relevant binary dependencies. A reviewer needs the intent, affected entities, participating changes, and evidence for the exact state being accepted. Folder boundaries organize the software without having to define the limits of those decisions. Tools that require files can still materialize them, but the filesystem is a representation of the work rather than the only place its scope can be reconstructed.

That is why Atomic is a different architectural choice from making the inherited workflow faster. We start with objects and relationships that represent agent-driven change, then build collaboration, review, and validation around them. We do not require the agent to absorb a human workflow and repeatedly infer the continuity that people once supplied.

Agents inherit our assumptions too

Building Atomic has made this problem personal. We have repeatedly encountered agents that interpret unfamiliar requirements through familiar Git concepts. They move toward a plausible answer, and that answer quietly restores the assumptions we were trying to remove. The implementation can look reasonable while violating the architecture.

That experience taught me to distinguish an agent’s ability to implement a design from its willingness to question the design’s premises. Giving an agent more coding capacity does not establish that it is solving the right problem. Sometimes it gives us a faster way to build around the wrong primitive.

Building around first-class folders, binaries, and closures requires us to defend that architecture when an agent reaches for a familiar branch, checkout, or pull-request pattern. Otherwise, we can spend months writing a new system that reproduces the constraints we set out to remove. The architectural judgment has to survive the implementation.

Anthropic closes by acknowledging nearly two decades of Git engineering and proposing improvements with the community. That investment deserves respect. It also deserves examination. A mature ecosystem can be extremely good at serving the assumptions it was built around while those assumptions become less appropriate for current work.

Stop being sheep. Ask why collaboration needs that repository boundary. Ask why CI needs those checkouts. Ask what the system actually knows about the change before commissioning agents to code around what it cannot represent. We built Atomic because we believe those relationships belong in the foundation of software change. You can choose a different foundation too, but only if you stop treating the existing one as inevitable.