GitHub is undertaking a fundamental redesign of its backend systems to accommodate the demands of AI agents. The company's leadership team used its annual Universe '26 conference in San Francisco to address platform stability concerns and outline the scope of necessary changes.
The infrastructure expansion includes provisioning 4 million additional cores and 160 petabytes of storage capacity, coupled with a complete rearchitecture of the backend. Jay Parikh, executive VP of CoreAI at Microsoft and current GitHub leader, and GitHub COO Kyle Daigle fielded questions about the platform's direction and competitive positioning.
The timing of these announcements coincided with the launch of Entire, a GitHub alternative created by former GitHub CEO Thomas Dohmke just days before the conference. When pressed about Entire and Microsoft's M12 investment arm backing the startup, Daigle took a measured approach, noting that Microsoft regularly invests in tools that compete across its product portfolio.
Daigle emphasized GitHub's global reach, serving more than 225 million developers, and its continuous evolution. He articulated a clear position on the competitive landscape:
I don't think the world needs a new GitHub.
GitHub COO Kyle Daigle
According to Daigle, developers may require different tools, but what they fundamentally need is for GitHub to adapt to the agentic era. He pointed to GitHub's unique positioning as a platform serving individual developers, major open source initiatives, and Fortune 100 enterprises simultaneously—a breadth he argued competitors were not attempting to replicate.
Daigle contended that discussions around new Git forges often overlook a critical aspect: GitHub's ability to host all developer communities at scale rather than targeting only enterprises or only open source projects. He compared the current moment to the end of the zero interest rate period, when numerous specialized developer tools emerged but lacked staying power. "Luckily, a lot of those folks ended up joining GitHub — and doing some really great work," he said.
Entire's Response
Dohmke countered Daigle's assessment with a statement to The New Stack:
GitHub may not think there needs to be a new GitHub, but developers clearly do. Do we really want to put the future of software development and open source into the hands of a single big tech company? We are building Entire so the new home of the community is open source, scalable, and resident in many regions around the world.
Entire CEO Thomas Dohmke
Platforms Versus Products
Parikh stressed the significance of GitHub's developer community and platform capabilities as competition intensifies. He highlighted the importance of community in an era of rapid change, emphasizing how developers share knowledge and collaborate on software creation.
Parikh drew a distinction between standalone development tools and comprehensive platforms. "GitHub and Microsoft have always been platform companies," he stated. "So much of what's out there are products, and yes, we have products, and we have platforms."
This platform philosophy translates into offering complete development workflows while allowing developers to select individual components. Daigle elaborated on this flexibility: "we'll give you the full flow, or we'll give you the primitives, which I think is what most companies want. Everyone's interested in what is the one way to do this, but nobody wants to buy the only way. They want to have the optionality and the choice."
Where Agents Break Things
Supporting diverse workflows forced GitHub to reconsider long-held assumptions about service failure patterns. Daigle explained that AI agents behave fundamentally differently from human developers, causing unexpected breakdowns in systems that had previously scaled reliably.
Early summer failures prompted GitHub to look beyond simple capacity additions. "It's not just increasing the number of cores, the overall horizontal scaling, but looking at core services that need to be completely rewritten because the behavior pattern is so incredibly different," Daigle said.
Parikh, drawing on experience scaling infrastructure at Facebook and Akamai, noted that current growth rates render incremental improvements obsolete. "You have to take a full systems look at it," he explained. "Getting five or 10% here or there, it lasts you two weeks or a week now."
The challenge intensifies because GitHub must implement these changes without disrupting service or breaking compatibility with existing workflows. Traffic patterns themselves remain unstable, shifting bottlenecks from one component to another as optimization efforts progress. Parikh described the iterative approach: "Right now, the good news is you do these in staged rollouts. You test these things, and then you adjust."
A major architectural shift involves decoupling compute from storage in GitHub's Git infrastructure, enabling independent scaling of each resource according to demand. This separation allows optimization based on traffic patterns, time of day, user behavior, and product offerings.
Migration from GitHub's own data centers to Azure infrastructure provides additional capacity, geographic distribution, and redundancy that existing facilities could not deliver. Parikh noted ongoing work to strengthen and scale GitHub Actions, indicating the transformation remains incomplete.
Keeping Free Repos Free
The architectural changes carry implications for the economics of hosting open source code and free repositories. Separating compute from storage should reduce Git repository storage costs, helping GitHub sustain free access as developers and agents generate increasing workloads.
Daigle articulated GitHub's commitment to its developer community, stating that restricting developers to minimal private repositories would violate the fundamental value proposition. Every developer, whether experienced or new, deserves a home on GitHub, he argued. "A repo should not be hidden out on your laptop, or [be] an HTML file shared between friends," he said. "We have a place for that."
However, Daigle distinguished this commitment from subsidizing AI model access. GitHub cannot provide unlimited free tokens to all users and must make deliberate choices about where to offer subsidized access.
Rethinking Git and Verification
Beyond internal infrastructure, Daigle sees opportunities to evolve Git itself. He envisions GitHub working with the broader community to reconsider Git's foundational design and potentially introduce "a porcelain layer on top of Git"—a higher-level interface that abstracts underlying complexity.
Daigle emphasized GitHub's responsibility to assert its role in the developer community and collaborate with established and emerging players on rethinking Git's core assumptions. "They kind of didn't make sense before the agent change," he said, "and now they really, really don't make sense."
Despite these observations, Daigle remains cautious about whether the agentic era demands an entirely new version control system. "I want to know we need to move before we move," he stated. "I don't think we're done with [Git] yet. I just think we do need to lean in more."
Parikh highlighted the verification stage—reviewing, testing, and deciding whether code reaches production—as increasingly critical. This encompasses security scanning, production deployment decisions, and workflow execution.
Daigle expects verification to emerge as the next system bottleneck. He argued that unlimited compute capacity would not justify running every build after each agent commit. With multiple agents operating simultaneously, developers need selective testing rather than exhaustive builds.
Potential solutions include locally signing agent-generated builds before submission, selecting targeted test subsets, and exploring proof-driven development approaches. The optimal combination depends on application requirements. "If you're an automaker, you're not going to say, 'Well, I'll let my agent check if the brake caliper was engaged or not,'" Daigle noted.