Anthropic has redesigned source control to support AI agents at scale. Most teams won't need to follow its example. But its engineering decisions raise a question every team adopting agents should ask: which of our established development practices still make sense?
Anthropic’s latest disclosures around Scion signal a massive paradigm shift: the transition from prompt engineering to Agent-Native Development.
As developers and architects, we need to stop treating AI as an external utility function and start treating the agent as the foundational core of our application lifecycle. This means rewriting how we think about state, side effects, and deterministic guardrails.
In this post, we’ll break down:
• The core architectural limitations of prompt-heavy infrastructure.
• What "Agent-Native" actually looks like in a production codebase.
• How tools like Scion change the way we orchestrate autonomous workflows.
In February, I published Toward Agent Native Development, questioning why we continue to organize AI agents around development workflows designed primarily for human contributors.
Branches, pull requests, and CI pipelines evolved to help developers work independently, coordinate changes, and maintain quality. They work well for human contributors, but their assumptions may not fit teams of agents producing changes concurrently and at much greater speed.
Increasing code generation without reconsidering coordination risks moving the bottleneck rather than removing it.
I proposed three changes:
- Rethink local branches as the default unit of parallel work: Agents could work with shared change sets and explicit dependencies rather than isolated branches.
- Make changes independently observable: A change ledger could expose ongoing work through APIs, allowing agents to react to relevant changes without waiting for integration.
- Move toward continuous verification as default: Agents could maintain evidence about the system's changing state, while humans supervise critical decisions.
The principle behind these proposals was simple: development workflows should reflect the needs of their contributors. As agents take on more work, the constraints shaping those workflows begin to change.
On October 13, Anthropic published Redesigning source control at Anthropic, describing how its engineers encountered several of these problems at scale.
Anthropic vs Git's assumptions
In their piece, they report that between May and September 2026, Anthropic's daily merged changes increased from approximately 2,500 to more than 30,000. Its monorepo approached 100 GB of main-branch history, while CI performed about 25 million code checkouts daily.
Git's decentralized design allows developers to work independently, including offline, by maintaining local repository data and history. At Anthropic's scale, replicating and maintaining that data across enormous numbers of clients became expensive. Most of those clients were agents and automated jobs that remained connected, making offline operation far less important.
Rather than continue optimizing Git, Anthropic questioned why its infrastructure should preserve capabilities its main consumers rarely needed. Instead of adapting the workload to an established tool, they reconsidered the tool around the workload.
As a result, they built Scion, a centralized source control system. Changesets are stored in a write-ahead log, become immediately available, and can be accessed through APIs without requiring complete local repositories, branches, and most other refs.
Scion shares several characteristics with the change ledger I proposed in February. Both treat changesets as first-class objects, make changes accessible through APIs, and reduce dependence on branch-based isolation.
Anthropic also questions conventional merge queues and CI pipelines. When hundreds of changes land while tests are running, pre-merge verification becomes difficult to maintain. Its engineers have invested in post-merge and pre-deployment testing instead.
This echoes my proposal for verification that follows the system's changing state, although the objectives differ. Scion addresses how changes are stored and integrated at scale. My proposal focused on how agents coordinate related work and maintain evidence about its correctness.
There is a broader distinction here. Using agents to produce code faster is not the same as designing a development environment around agents. The former increases the capacity of individual contributors. The latter questions how work is coordinated, integrated, and verified when those contributors are no longer primarily human.
Scion doesn't make established practices obsolete. It shows why their usefulness depends on the constraints under which they operate. Those constraints differ between teams, and they change as agentic development scales.
Engineering leadership matters more than ever
A small team using occasional coding agents may find conventional pull requests entirely adequate. Teams requiring offline development may deliberately retain Git's decentralized architecture. But a workflow that serves two agents may become unsuitable when dozens work concurrently on the same codebase.
At the other end of the spectrum are dark software factories, where agents perform most of the implementation work and human engineers increasingly supervise the system rather than individual changes.
These environments place different demands on coordination, verification, and engineering leadership. As agents take on more implementation work, engineering leadership increasingly depends on understanding the constraints under which that work happens.
The decisions extend beyond selecting coding tools. They concern how agents share context, coordinate changes, establish correctness, and operate within human-defined boundaries.
While Claude contributed heavily to building Scion, Anthropic's engineers were responsible for its architecture, system constraints, and tradeoffs. Sometimes their most valuable contribution was rejecting an implementation that satisfied the immediate task but violated a broader requirement. They designed and actively steered toward an agent-native development environment, building on and questioning established practices at the same time.
Agentic development doesn't automatically make established practices obsolete. It makes understanding their purpose more important. Some teams will retain Git, branches, and conventional reviews. Others will redesign parts of their workflows as their constraints change.
We may keep the tools we have or replace them. What matters is that we understand why.
This article follows Toward Agent Native Development (February 2026) and discusses Anthropic's Redesigning source control at Anthropic (October 2026).
Top comments (0)