Scion: When Agents Hit Development Infrastructure Limits (#AI4SDLC)

There is an intriguing self-reinforcing loop in Anthropic’s article on Scion: agents produce so many changes that development infrastructure cannot keep up. Then they help build new infrastructure so they can produce even more changes :)

According to the team, daily merged changes grew from about 2,500 in May to over 30,000 in September 2026. Seven engineers built Scion, the Antique review tool and several related systems in five months, fully migrating their monorepo from Git. In my annotations, I singled out the speed of migration: building a system and moving a functioning company onto it are very different tasks.

Who is the version control system’s client now?

Predominantly always-online agents and CI jobs. In Scion, the server therefore handles history, blame, merges and rebases. Clients keep a bounded cache and fetch the files they need, while many operations run through an API without a working copy at all.

Further into the article, my notes increasingly boiled down to “this sounds like databases.” A changeset is a WAL entry listing changed files and pointers to their contents. Trees, path history and blame are built as derived data. This resembles CQRS: recording changes and building read structures are optimized separately. New indexes can be added, computed eagerly or on demand, and their internals changed without updating clients.

Immutable objects are served through node and regional caches. A commit’s cost should depend on the size of the change. Familiar scaling principles applied to a new workload. It is good to see the authors acknowledge predecessors: Google’s Piper and Meta’s Sapling.

An engineer who knows when to tell an agent “no.”

The team still reviews every change, but focuses primarily on its intent. Humans uphold architectural constraints and stop unnecessary complexity: for example, an agent reviewer may invent a hypothetical threat, prompting another agent to diligently surround a service with unnecessary checks. This is where engineering judgment matters. Even so, the implementation still needs to be checked against that intent.

Another note of mine was “an electronic SRE.” Each component has a “superfan” agent watching telemetry and logs for anomalies. According to the team, these agents spot problems that conventional alerts miss. The conventional alerts remain in place.

The rethink extends to CI.

While tests run, hundreds of other changes can land on main. Anthropic is investing in post-merge and pre-deploy checks, accepting conflicts between concurrent changes and relying on agents to fix them quickly. In my annotations, I specifically highlighted the process redesign. This leaves me wanting more detail: what is eligible for release, how long does main stay broken, and how does that disrupt other agents? The article does not disclose that contract.

And impressive numbers deserve careful reading. The prose claims two orders of magnitude faster checkouts, while the final chart shows 8× for compute jobs, 8.8× for CI and 84× for creating an agent’s new worktree. Conditions may differ, but the discrepancy is not explained. Merge counts alone do not measure the usefulness of code either. This is a company’s engineering report on its own solution.

The authors are candid about their unusual scale and available token budget. Adopting Scion wholesale is unlikely to make sense for most teams. But checking which operations in our SDLC exist out of habit, and whether agents actually need them, is already a practical idea.

P.S. Later today, towards the evening, I will host a Research Insights Made Simple livestream to discuss this system in more detail.

#AI4SDLC #Architecture #DistributedSystems #DevTools #Engineering