The Agentic Shift: How GitHub is Rebuilding its Core for the AI Era

In the landscape of modern software development, GitHub serves as the primary engine for the global digital economy. Every day, millions of developers rely on the platform to host open-source projects, manage corporate intellectual property, and ship products that define our daily lives. However, the paradigm of software development is undergoing a seismic shift: the rise of "agentic" software development—an era where AI-driven agents, operating autonomously alongside human engineers, are contributing code at unprecedented velocities.

To accommodate this explosion in activity, GitHub has announced a massive architectural overhaul. By moving away from its long-standing storage models, the company aims to move beyond traditional Git limitations, preparing for a future where repositories are not just repositories of code, but hubs of constant, concurrent automated activity.

The Main Facts: A Paradigm Shift in Version Control

The core challenge GitHub faces is simple in theory but monumental in practice: Git was never designed for the level of concurrency demanded by thousands of AI agents working simultaneously.

For years, GitHub’s infrastructure has relied on a system called "Spokes." In this model, every repository is stored on the local disks of five different fileservers. While this provides excellent redundancy and low-latency reads, it creates a "coupling" problem. Because the durable storage and the compute-heavy read/write layers are intertwined, adding more replicas to handle read traffic inevitably slows down the write process.

As Brian Celenza, Principal Software Engineer at GitHub, notes, "Every replica participates in every write, so a push is only as fast as the slowest replica in its set." With agentic workloads, this ceiling is no longer sustainable. GitHub is now moving toward an architecture that decouples storage from compute, allowing each to scale independently—a move that promises to resolve the bottleneck that has historically plagued high-volume repositories.

Chronology of an Infrastructure Evolution

GitHub’s architectural history can be viewed in three distinct phases:

The Early Era (The Filesystem Approach): In its infancy, GitHub relied on standard Unix filesystems. As the platform grew, this became unmanageable, leading to the development of custom infrastructure to handle the sheer volume of data.
The Spokes Era (2010s–2026): To ensure high availability, GitHub introduced Spokes. This distributed system allowed for multiple durable copies of a repository. It was a masterstroke for reliability, providing a robust foundation that allowed GitHub to grow to over a billion repositories.
The Agentic Era (2026–Present): With the rapid adoption of AI agents, the nature of "traffic" has changed. Between September 2025 and August 2026, total Git activity on GitHub doubled, climbing from 218.2 billion events per month to a staggering 473.3 billion. The transition to the new, decoupled architecture began in response to these metrics, as engineering teams recognized that the "Spokes" model was nearing its physical limits.

Supporting Data: The Scale of the "Agentic" Surge

The data provided by GitHub underscores the necessity of this pivot. The gap between an average repository and the "busiest" repositories is widening at an exponential rate. In August 2026 alone, the busiest repository on the platform processed approximately one billion requests.

The surge in commit volume is perhaps the most telling statistic:

September 2025: Total commits were approximately 1.4 billion.
September 2026: Total commits skyrocketed to 7.38 billion.

This five-fold increase in just twelve months is driven almost entirely by the proliferation of AI agents. These agents are not just "committing" code; they are running continuous integration (CI) pipelines, conducting automated testing, and performing refactoring tasks that once required a human touch. When these activities occur in a massive, shared repository—such as one managing an entire operating system—the coordination required to ensure consistency becomes a significant hurdle.

Official Responses and Engineering Philosophy

GitHub’s engineering team, led by figures like Brian Celenza, is approaching this rebuild with a "don’t break the world" mandate. The platform cannot simply go offline for a maintenance window; the global software supply chain is too interconnected to pause.

"We are building for the most demanding workloads on GitHub," Celenza explains. "An enterprise shipping under strict regulatory requirements, a team landing a change across a repo that builds an operating system, and an organization running thousands of agents against a single codebase—these are the use cases driving our design."

The team has adopted two primary guiding principles for this transition:

1. Minimize Coordination

In the current architecture, coordination is necessary to protect repository integrity. However, too much coordination creates a bottleneck. GitHub is redesigning the system to allow non-conflicting operations to proceed independently. By reducing the "chatty" nature of the three-phase commit protocol, GitHub aims to ensure that one agent’s commit doesn’t force the entire system to pause, even for a millisecond.

2. Decouple Storage from Compute

This is the heart of the new strategy. By separating the storage layer (where data lives) from the compute layer (which processes Git commands), GitHub can scale its read capacity horizontally without penalizing write latency. Internal benchmarks have already shown that this approach can deliver up to 35 times higher write throughput compared to the existing Spokes-based architecture.

Implications: A Faster, More Resilient Future

The implications of this shift are profound for every level of the development ecosystem.

For Large Enterprises:
The most immediate beneficiaries will be large organizations managing massive, monolithic codebases. These teams have been hitting the "ceiling" of traditional Git performance, often forced to shard their code into smaller, less-efficient sub-repositories. The new architecture promises to allow these organizations to maintain larger, more unified codebases without sacrificing performance.

For Open Source Maintainers:
The "floor" of performance is being raised for everyone. When GitHub optimizes for the busiest repositories, the underlying infrastructure improvements—such as faster clones and more responsive pull request processing—trickle down to smaller projects. A maintainer reviewing a pull request from a contributor on the other side of the world will benefit from the same latency-reducing optimizations designed for high-frequency AI agents.

For Governance and Compliance:
Critically, GitHub has emphasized that this architectural change will not compromise the controls that teams rely on. Branch protection rules, required reviews, audit logs, and repository visibility settings are being built into the new architecture at the foundational level. The goal is to provide a system that is "agent-native" while remaining "enterprise-ready."

Conclusion: The Next Chapter

As software development continues to move toward an automated, agent-driven model, the infrastructure underlying our code must evolve accordingly. GitHub’s transition from a storage-coupled architecture to a decoupled, high-throughput system is more than just a technical upgrade; it is a recognition that the "human-only" era of programming is ending.

By building for the extremes—the busiest repositories on the planet—GitHub is essentially future-proofing the collaborative potential of the entire developer community. As we look toward the coming years, it is clear that the speed of innovation will be limited only by the capacity of the systems that store our ideas. With this new foundation, GitHub is positioning itself to handle the next decade of unprecedented growth, ensuring that whether a commit comes from a human or an agent, it is handled with speed, security, and absolute reliability.

As Brian Celenza promised, this is merely the first part of a larger story. In the coming months, the engineering community expects to see the rollout of these core architectural changes, marking a new era in the history of version control.