Agents push you to a monorepo, not to a monolith

Now that AI agents write much of the code, keeping each service in its own repository costs more than it used to. Anthropic has just replaced git with a system of its own so it can keep a single repository. Putting the code together doesn’t force you to put the services together, but watch out: an atomic commit is not an atomic deploy, and that’s where the advantage stops.

Three pull requests for one field

You ask your agent to add a delivery date to the orders API. The API lives in orders-api, the shared types in contracts and the frontend in web. The agent changes the repository it has open and stops at its edge: you open the other two, in order, with a new release of contracts in between.

A team absorbs that cost with owners and meetings. An agent works with what’s in its working copy: you can hand it all three repositories, but then you’re the monorepo, by hand. With everything in one repository, the same change is one branch, one review and one CI run, and the agent sees who calls the API before it touches it.

Hence the idea that AI brings the monorepo back. It isn’t new: in February, Nx, which sells monorepo tooling, announced a webinar called “Why Monorepos are King in the Age of AI”. That was a vendor’s opinion, with no data behind it. The data arrived this week.

What Anthropic did

On 13 October, Anthropic wrote on its engineering blog that it has moved its monorepo off git.

The numbers explain the move. In May 2026 they merged about 2,500 changes a day; in September, over 30,000, twelve times as many in four months. The main branch’s history is almost 100 GB, the compressed working copy over 25 GB, and CI runs some 25 million checkouts a day. git assumes every client works offline with a full copy, and Anthropic’s clients are mostly agents and jobs that never go offline.

Scion, the replacement, flips that around: the server answers history and blame queries, creates commits and performs merges, and the client fetches only the directories it asks for. Seven people built Scion and a code review tool called Antique, and finished the migration in five months. Anthropic says it uses 200 times less CPU and memory than its git mirroring setup, and that CI checkouts take seconds instead of minutes. It attributes the volume to Claude, which is also what it built Scion with. Don’t expect to download it: The Register reports there will be no open source release, and Anthropic says Scion isn’t a general replacement for git and would rather share its thinking so others can bring the best parts to git.

A monorepo is not a monolith

Faced with that volume, Anthropic changed its tool and kept its single repository. The post doesn’t mention microservices, and it shouldn’t be read as a vote for the monolith. A repository decides where code lives and which changes get reviewed together; a service decides what gets deployed and fails on its own. Google has kept a single repository for tens of thousands of developers for years, as it explained in Communications of the ACM in 2016, and it too had to build its own system, Piper, to keep it.

Microservices solve two kinds of problems. Some are about production: parts that scale differently, that must fail separately or that need another runtime. Others are about the organization: teams that deploy without waiting for each other. My take is that one repository per service came mostly with the second kind: each team with its own repository, pipeline and pace.

When the team is small, or is one person with several agents, the organizational reasons weigh less, but the production ones stay where they were. What changes, in my view, is that the repository boundary no longer has to trace the org chart; services stay separate wherever production has a reason.

An atomic commit is not an atomic deploy

Here’s the catch. In a monorepo, the agent changes the API and its client in the same commit, CI tests them together and everything passes. In production they don’t arrive together: during a rollout, pods on the old version serve next to pods on the new one, and clients you don’t control, like a mobile app or a customer’s integration, update when their owner gets around to it.

The contract still needs backward compatibility, the pattern known as parallel change, or expand and contract: accept the new shape first, then use it, and remove the old one once nobody sends it. An agent that sees the repository as one program has no reason to know any of that. Anthropic reports something similar from its migration, in a different area: agents sometimes violate core system constraints to satisfy a pattern that should never have been allowed, and very often the engineers’ job was to tell Claude “no.”

When it doesn’t pay off

One repository has costs you don’t see on day one:

• CI has to know what changed. Without path filters, a docs change runs every service’s tests, and with agents merging more and more, that shows on the bill and in the queue.
• If the repository ships several things, each with its own version, your release tooling has to know which commit touches which.
• Your repository is probably nowhere near Anthropic’s almost 100 GB of history, but what agents multiply is the merge rate, and that shows up in the merge queue and in CI times long before it shows up in git.
• If part of the code has a different audience, such as a client’s code, the repository boundary is also the permission boundary. Anthropic built an access control system into its source control, down to permissions per directory, to protect its most sensitive code without giving up the monorepo. Without people to build something like that, that code belongs in another repository.

And it doesn’t pay off when teams share neither code nor release pace, or when each part’s tooling is so different that a shared CI would just be several CIs glued together.

Try it

If you already work in a monorepo, or you’re about to merge repositories, write down in your agent’s instructions (AGENTS.md, CLAUDE.md or whatever file your tool reads) which directories deploy separately, where each one runs (servers, phones, browsers) and the compatibility rule between them. It takes ten minutes, and the agent will have it in front of it the next time a change crosses an API. It isn’t a guarantee either, since the agent can ignore it, so reviewing is still on you.

Scion’s details are in Anthropic’s post, “Redesigning source control at Anthropic”. Picaporte Labs is one person, in Spain; if this doesn’t match what you see on your team, write to me.