Anthropic is right: AI broke source control. A bigger repo isn’t the fix.
Agents broke tools built for human scale. Anthropic scaled the repo. There is a second answer: connect software on a graph.
Anthropic just shared how they rebuilt source control. It’s a great read, and they’re right about the problem. We thought about it differently.
AI makes software cheaper to create, and harder to coordinate. Git assumes every copy is complete and offline. Agents are always online, and there are thousands of them. So Anthropic built Scion: a server-first system that scales the repo to meet the load.
More commits is the symptom. When coding stops being the bottleneck, the pressure moves to whatever comes next. For Anthropic it was source control. The next one isn’t the repo. It’s the product: which one changed, who owns it, what it affects. A faster repo doesn’t know that.
Same problem. Different model.
Scion solves the scaling problem inside the repo model. Bit changes the model.
Bit takes the second path. Take the folders in a typical monorepo: a storefront app, a billing service, a checkout flow. In Bit, each one is a component, and each is versioned, built, reviewed and checked out on its own. The graph knows what depends on what. One change can still touch many components and ship as a single reviewed change, like in a monorepo. Each agent checks out only the components it’s changing.
Know what a change will break
Source control tracks which files changed. But people and agents think in products, services and owners. Dependency graphs and ownership rules help, but they’re layers on top of files.
Bit makes the unit explicit. Billing is a component with an owner, an API and known dependents. Every change shows more than files: which components it touches, how it flows through the graph and which products it reaches. Agents and reviewers work from that, and Bit builds and tests only what it affects.
Same principles. Different unit.
Bit follows the same six principles. It builds each one on the graph, not the repo.
Agents work on what they need
A Bit workspace is built for the change: one feature, a few components or a whole app. An agent checks out only what it’s changing and reads the rest over MCP: each component’s API, docs, dependents and owner. Context, not the codebase.
Changes stay atomic, like in a monorepo. One change can span many components across scopes, and their dependents update and ship with it as one reviewed change. Or let teams adopt it when they’re ready, and see who’s on the old version.
Scion scales the repository. Bit scales with the change.
Build freely. Connect what matters.
Software used to be built by one engineering team around one codebase. AI changes who builds. Now product teams, operators, engineers and their agents build at the same time. Putting all of them in one repo to keep shared parts connected gets harder with every builder. Split it, and the shared parts drift apart.
Companies are already graphs. Teams own their products, domains and shared capabilities, and everything still depends on everything else. Their software should work the same way. People and agents each own a part and build at the same time. Shared parts are built once and reused. A fix ships everywhere it’s used. Every app you add makes the next one cheaper and safer to build.
AI will create more builders and more parallel changes than repo-based workflows were designed for. The graph lets each one own a part, see what it affects and ship without waiting on everyone else. We build all of Bit Cloud this way, down to this post. Fortune 500 engineering and product teams are already using it.
It also changes how you adopt it. A bigger repo pays off once everyone moves in. A smaller unit pays off from the first one. You don’t have to replace what works. Keep your repos and CI, and build the next thing on the graph.