AI Is Making Companies Rebuild the Tools Behind the Code

Anthropic's coding agents were producing so much work that the system keeping track of its code became a bottleneck. The company says its daily volume of merged changes grew more than tenfold between May and September. It built a replacement called Scion and moved its main shared codebase over in five months. Claude helped build the replacement, too. Anthropic's engineering account.

That is an unusual way to discover the next problem: get AI to help you write software, then use AI to rebuild the machinery struggling under the extra work.

My view is that we're going to see more of this. The next advantage in AI coding will increasingly come from how well a company handles the work its agents produce. Generating a change is one step. Deciding whether that change belongs in the product, checking it, and combining it with everyone else's work takes a whole system.

To understand why, picture a small team building an app. One person changes the sign-in screen. Another changes how accounts are stored. Before those changes reach customers, the team needs to know that they work together. A screen that looks correct can still fail when it talks to the rest of the app.

Now imagine each person has several AI agents working on separate tasks. The first drafts arrive much faster. But the work still has to pass through those checks, and some agents may be changing related parts of the app at the same time.

Speed at the keyboard has become pressure everywhere else.

The tool at the center of Anthropic's story is Git. You don't need to know its commands to understand its role. Git keeps a history of changes to a project's files, lets people work on separate versions, and helps bring their work together. A project and its history are stored in what developers call a repository.

Git's usual design gives each developer a local copy with the project's history. That independence is useful: people can inspect earlier work and save changes while disconnected. The Git project's introduction explains the model. Git also has options for downloading less, so the choices aren't limited to copying everything or replacing Git. Git's cloning documentation.

Scion takes a different approach. Much of the work happens on a shared service, and agents fetch the files or answers they need. Anthropic also built a new review tool. It explicitly says Scion suits unusually large workloads, and that its own ability to spend heavily on internal AI use is exceptional. Anthropic's explanation.

So the useful lesson for most teams is to notice which assumption faster coding puts under strain. That question has a history.

Years before today's coding agents, Google faced the difficulty of coordinating an enormous shared codebase. Its engineers built a centralized source-control system called Piper. Google's account describes how its scale made adopting ordinary tools difficult, and why repeatedly downloading information an individual developer rarely needed was wasteful. Software Engineering at Google.

Microsoft ran into a related problem with Windows. In 2017, it reported that even asking Git which files had changed could take almost ten minutes. Its answer was a virtual filesystem: make the files appear available, then download their contents when needed. It wanted to retain Git while changing how a huge repository reached a developer's machine. Microsoft's GVFS announcement.

Meta followed its own path with Sapling, developed over years to support a growing shared codebase. It changed storage, communication, and workflows rather than give up the benefits of keeping related code together. Meta's Sapling account.

These were responses to large organizations and large projects. AI adds another route to heavy workloads: more automated workers, saving changes and asking for checks in rapid succession. A small human team doesn't automatically get Google's problems. But headcount becomes a less useful guide to how much activity its tools must handle.

The closest contemporary comparison comes from GitHub, where many teams store and review their code.

On October 6, a week before Anthropic's post, GitHub described rebuilding its Git infrastructure for developers and agents working concurrently. It explains that an agent can save checkpoints so frequently that the time taken to share each one starts limiting its progress. Each shared change can also trigger many downloads for automated tests and security checks. GitHub's infrastructure account.

Think of the difference between someone saving a document a few times during an afternoon and software saving a new version after almost every action. Then imagine each save causes other machines to open the document and inspect it. Making the writer faster increases the work for all those machines.

GitHub is separating the storage that keeps code safe from the machines that answer requests for it. That lets it add capacity to serve more readers without making every saved change wait on more copies. The rebuild is underway; its published results include internal benchmarks, rather than proof of a completed rollout for every user. GitHub's proposed architecture.

That makes the pattern harder to dismiss as one AI company's unusual habits. A platform serving many kinds of developers is preparing for the same pressure. It also suggests that much of the adaptation can happen inside services teams already use.

But keeping track of more code only solves part of the problem. The next difficulty is helping all that work make sense together.

Cursor's experiments offer a useful story. It initially let agents coordinate through a shared task file, with locks to prevent two agents claiming the same task. Agents held locks too long or failed to release them. More workers spent their time waiting. Cursor improved the arrangement by separating planning from execution and giving agents clearer responsibilities. These were research experiments, with further coordination problems still unresolved. Cursor's account.

The lesson I take from that is straightforward: buying more capacity to write code can also buy more confusion. Someone, or some system, must decide who owns a task, which changes depend on others, and what counts as finished.

Stripe shows how much existing engineering work can help. Its unattended coding agents, called Minions, use standardized cloud development machines originally built for human engineers. Those machines give agents separate places to work without interfering with one another. Stripe also combines flexible AI steps with fixed steps for required checks, and people review the resulting changes. Stripe's engineering account.

That detail matters. A model can decide how to solve an unfamiliar problem while ordinary software makes sure a required check actually runs. You don't have to ask AI to make every decision just because AI wrote the change.

OpenAI describes a different experiment: an internal product whose code and supporting tools were written by Codex. Engineers concentrated on making instructions, tests, and feedback accessible to the agents. Its review process relies heavily on agents, and its authors warn that the approach depends on the environment they built. They also say they don't yet know how well the software's design will hold together over years. OpenAI's account.

Stripe and OpenAI chose different levels of human review. Both invested in the surrounding system. I think that is the more durable pattern: clearer tasks, reliable checks, useful feedback, and a way to recover when the work goes wrong.

There is a temptation to read these stories as proof that more code means more progress. A company can count changes much more easily than it can measure whether customers are better off. A useful fix, an unnecessary rewrite, and a correction to yesterday's mistake all create activity.

Even measuring time saved is difficult. The independent research group METR reported in February that its newer productivity experiment had become hard to interpret: developers were selecting which tasks to submit, and running several agents made time tracking messy. It believed benefits had likely increased, while calling its evidence for the size of that increase weak. METR's research update.

The infrastructure pressure is credible. The wider productivity story still needs careful measurement.

I expect the tools around coding to absorb more of the work next. A change should arrive with a clear account of what it does, evidence that it works, and an explanation of which other changes it relies on. Tests should give agents useful feedback quickly. Review should help people focus on decisions with real consequences.

Consider two hypothetical changes: correcting a label and changing who can access an account. Sending both through an identical approval process wastes attention on the first and may provide too little scrutiny for the second. Better tools should help teams distinguish them, while leaving the team responsible for its rules.

Engineers will need to express more of their judgment in forms those tools can use. A requirement such as “customers must never see another customer's records” needs checks that can reject a violation. An architectural decision needs to be discoverable by the next agent that touches the code.

Anthropic's engineers describe having to tell Claude “no” when it broke system constraints or added unnecessary complexity. Their understanding of the system still shaped the result. The company also describes investing in testing after changes are combined and before release, as many changes can arrive while earlier tests are still running. Anthropic's lessons.

Moving a check changes where a mistake can be caught. Teams need to distinguish code entering the shared project from code reaching customers, and keep a dependable barrier before release. Faster repairs alone don't make every mistake acceptable.

For a small team, I'd start with the delay already visible in its work. If agents finish quickly but changes wait for review, improve the size and clarity of those changes. If checks take too long, improve the feedback. If agents keep making the same mistake, turn the lesson into something they can find or a rule the tools can enforce.

The reason to do this is that faster drafting gives you more opportunities to improve a product, and more opportunities to spend time on work it doesn't need. The surrounding system determines how much of that extra capacity becomes useful.

Anthropic's story starts with an abundance of code. The question I would carry into my own team is what happens after the code arrives. Can we understand it, trust it, and maintain it? That is where the next advantage will be earned.