GitHub Overhauls Infrastructure for AI Agents While Defending Against New Competitors

GitHub is undertaking a comprehensive reconstruction of its infrastructure to accommodate AI agents. The company's leadership team discussed the technical challenges, the future of free repositories, and their perspective on competing platforms during interviews at the annual Universe '26 conference in San Francisco.

The platform announced it is deploying 4 million additional cores and 160 petabytes of storage capacity, coupled with a complete redesign of its backend architecture. Jay Parikh, executive VP of CoreAI at Microsoft and current GitHub leader, and GitHub COO Kyle Daigle fielded questions about the company's direction as new alternatives emerge in the developer tools space.

The timing proved significant: former GitHub CEO Thomas Dohmke launched Entire, a GitHub alternative, just days before the conference. When pressed about Entire and Microsoft's M12 investment arm backing the startup, Daigle took a measured stance. He noted that Microsoft regularly invests in tools that compete with GitHub and other Microsoft products, characterizing this as beneficial rather than problematic.

Daigle emphasized GitHub's reach, noting the platform serves over 225 million developers globally and continues evolving. He stated: "I don't think the world needs a new GitHub." He elaborated that while developers may require different tools, what matters most is GitHub's adaptation to the agent-driven era. "They might need different tools. That's great, but what they need is [GitHub] to evolve for the agentic era, which is what we're doing."

Platform Scale and Ecosystem Role

Daigle underscored GitHub's position within the broader software development ecosystem, spanning individual contributors, major open source initiatives, and large enterprises. He contended that discussions about alternative Git forges often narrow their focus too much, concentrating on corporate and economic dimensions while missing something fundamental.

He pointed out that GitHub has never monopolized Git hosting or source control management, citing Perforce and other long-standing alternatives. What distinguishes GitHub, according to Daigle, is its ability to host developers at scale across all segments—individuals, open source communities, and enterprises—rather than targeting only one category. "I don't see folks trying to go solve that problem. They're trying to solve a part of the problem," he said.

Daigle suggested that building enterprise-focused tools is comparatively straightforward, and that most emerging Git forges, including Entire, currently concentrate on that market. He drew a parallel to the post-pandemic economic shift, describing the current moment as "similar to the end of the zero interest rate era," when "there were a lot of really talented, interesting developer tools, but they were just incredibly narrow." He noted that many of those tool creators eventually joined GitHub.

Entire's Counterargument

Dohmke responded to Daigle's assessment with a direct challenge. "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."

Platforms Versus Products

Parikh stressed the value of GitHub's developer community and platform capabilities as competition intensifies. "With how fast the world is changing around how we build and the lifecycle of software, the power of the community, I think, is more important than it's ever been in terms of what we're creating, how we're sharing, how we're learning together."

He distinguished between standalone development tools and comprehensive platforms. "GitHub and Microsoft have always been platform companies," Parikh said. "So much of what's out there are products, and yes, we have products, and we have platforms." This means offering a complete development workflow while allowing developers to select individual components.

Daigle expanded on this philosophy: "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 Agent Behavior Breaks Systems

Supporting diverse workflows forced GitHub to reconsider which services were most vulnerable to failure. Daigle explained that agents behave fundamentally differently from humans, causing unexpected breakdowns in services that had previously scaled well.

Problems surfaced in early summer, revealing that simply adding capacity was insufficient. "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, whose background includes infrastructure scaling at Facebook and Akamai, noted that the current growth trajectory makes incremental optimization ineffective. "You have to take a full systems look at it," he said. "Getting five or 10% here or there, it lasts you two weeks or a week now."

The challenge is compounded by the need to maintain service continuity and backward compatibility while traffic patterns themselves remain unstable. "The traffic patterns are also not static right now … We optimized CPU, and now all of a sudden the bottleneck is going to move somewhere, and then you're like, 'Oh, I thought it would show up here, but it showed up here.' Right now, the good news is you do these in staged rollouts. You test these things, and then you adjust," Parikh explained.

A major architectural shift involves decoupling compute from storage in GitHub's Git infrastructure, enabling independent scaling of each resource based on demand. This separation allows optimization according to traffic patterns, time of day, user type, and product configuration.

Migration from GitHub's proprietary data centers to Azure infrastructure provides additional capacity, geographic distribution, and redundancy that the legacy facilities could not deliver. Parikh noted that further work remains, including enhancements to GitHub Actions for improved hardening and scalability. "We can't add the capacity. We don't have the scale in those fixed data centers that GitHub has operated on, and so moving into cloud infrastructure that gives us flexibility and scale and location and redundancy and network and all that is much better for us," he told The New Stack.

Sustaining Free Repository Access

The infrastructure redesign carries implications for the economics of hosting open source and free repositories. Daigle indicated that separating compute and storage should lower the cost per repository, allowing GitHub to maintain free access as developers and their agents generate increasing workloads.

Daigle asserted that GitHub bears a responsibility to its community. Restricting developers to minimal free private repositories "breaks the whole contract of what GitHub is," he said. Every developer, whether experienced or new, deserves a home on GitHub. "A repo should not be hidden out on your laptop, or [be] an HTML file shared between friends," he noted. "We have a place for that."

However, Daigle separated this commitment from the cost of providing AI model access. GitHub cannot offer unlimited free tokens to all users and must make strategic decisions about where to subsidize services.

Rethinking Git Itself

Beyond its own systems, Daigle sees potential for Git itself to evolve. He envisions GitHub working with the broader community to reconsider Git's foundations and possibly introduce "a porcelain layer on top of Git," a higher-level interface that would simplify interaction with the underlying system.

Daigle stated that GitHub should "assert our role in the community" and collaborate with both established and emerging players to rethink 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."

Yet Daigle remains cautious about whether the agent era demands an entirely new version control system. "I want to know we need to move before we move," he said. "I don't think we're done with [Git] yet. I just think we do need to lean in more."

The Next Bottleneck: Verification

Daigle anticipates that verification—the process of reviewing, testing, and determining whether code reaches production—will become the next critical constraint. Parikh elaborated at the press conference: "You actually need to review it, you need to push it into production, you need to run other workflows, you need to do AI scanning for security issues."

Daigle pointed out that even unlimited computing power cannot make running every build after every agent commit practical. "If I have 5 or 10 agents running at a single time, I don't actually want or need all those builds for the sake of the agent," he said. "And that requires a change in behavior for the agents or the humans involved."

Possible solutions include signing locally executed builds before submission with agent work, selecting a targeted subset of relevant tests, and exploring proof-driven development approaches. The optimal combination of tests, evaluations, and live verification will vary by application type. "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 said.