GitHub’s Agent Workload Is Reshaping Its Infrastructure Challenge

Jay Parikh described a platform growing on two fronts at once: more people are joining, while agents are changing the volume and character of the work GitHub has to support. The Octoverse figures he cited were 225 million developers across every country, 17.9 billion code pushes, 34.3 billion commits and 1.3 billion pull requests in the year. Open-source projects generated 2.5 billion contributions, he said, up two and a half times from the prior year. A new developer joined GitHub every second for the second consecutive year.

More than 40% of pull requests were agent-generated, according to the Octoverse graphic shown during the interview; 110 million agent-started pull requests were recorded in September 2026, after sixfold growth in six months. A chart presented at Universe also showed 45.4 billion Actions jobs in 2026, alongside the 34.3 billion commits. Together, the figures capture activity across repositories, pull requests and automated jobs—not just the writing of code.

For Parikh, those totals translate into “a lot of complexity”: database and file writes, metadata updates and indexing. The scale is not only a matter of storing more code. It also involves processing the activity around that code and keeping services available as patterns of use change.

A GitHub Engineering diagram shown during the interview illustrated one piece of the Azure migration: a replica live in an Azure region, with traffic divided between that region and GitHub data centers. The diagram showed 80% of traffic on GitHub data centers and 20% in Azure, and labeled the next step as shifting traffic to the live Azure replica. Another engineering chart showed requests to one repository rising from an average of 44 million per day in March to 181 million in May, a fourfold increase over three months.

Wang framed GitHub as a social network as well as an infrastructure platform. Parikh agreed that the analogy has force, though GitHub’s users differ from those of the social networks he has worked on. AI, he argued, broadens who can participate. GitHub has historically served software engineers, product managers and designers; coding agents make it possible for people without deep software-engineering skills to start a repository, express an idea and share it for feedback. Parikh put the community aspect simply: “You don't have to build alone.” The possibility he described is a larger community of people building together.

The growth in agent-generated pull requests raises a question about whether agents make the pull request less central. Parikh’s answer was not to defend one workflow as mandatory. He said GitHub should keep adapting as new ways of working emerge, and make its concepts configurable where users do not want or need them.

He offered his own repositories as an example: in some, he tinkers by “constantly just firing in ideas” and does not want to deal with issues or pull requests. That mode of work should be possible alongside the more structured workflows needed by large enterprises, students and other users across a platform of 225 million developers. GitHub, in his view, needs to provide a range of concepts that people can assemble to suit how they work.

That flexibility matters as the boundaries of a repository shift. Wang pointed to a repository of Markdown files by developer and educator Matt Pocock, including instructions for test-driven development and other agent skills. The example prompted a broader question: if repositories can be made up of instructions as well as executable code, what counts as code, and what does it mean for a repository to be “76% Rust”?

Parikh accepted the premise that repository contents are broadening, while cautioning against treating conventional code as obsolete. Businesses still run on decades-old Java and .NET systems that need security fixes, modernization, optimization and bug fixes. At the same time, new software is being “vibe coded into production,” as he put it. These are different contexts, and tooling has to accommodate both. Developers also want choice, he said, because their tools are part of how they express their craft and working preferences.

GitHub’s Copilot strategy combines a shared harness with a system for deciding which model should handle a task. Jay Parikh said the Copilot harness has been in development for some time, and that its SDK is open source so developers can build other applications with it. It supports multiple models and is meant to evolve as models and tools change, including integrations such as MCP.

The harness provides the environment for an agent to work; Copilot Fusion adds task-level orchestration. Parikh described the system as taking a prompt or work item that could become a completed unit of software, breaking it down, and selecting how to handle it. The aim is to reduce the cognitive load on engineers who would otherwise have to choose among models with different costs and capabilities.

The Fusion visual showed three routing modes: Single, Cascade and Critique. A separate demo presented three effort levels—Standard, High and Max—and showed Fusion selecting GPT-6 Luna for a low-complexity task. Parikh described the broader aim as choosing an approach suited to the work, so developers can get quality quickly and at lower cost. He said the harness and Fusion “ebb and flow together”: one coordinates tools and work, while the other helps choose a model for the task.

That orchestration is part of a broader claim about a connected development environment. Parikh said GitHub’s app, VS Code and website use the same harness. He described a developer starting work on a phone and continuing it on a desktop, with context retained across those surfaces. The relevant context, in his account, includes the repository, issues, pull requests and security findings, as well as memory and preferences.

Parikh presented this as an intended advantage of GitHub’s connected tools: context should compound in one place even when a developer changes models or surfaces. He contrasted that aim with switching among different providers’ tools, which he said do not compound their intelligence together. He also said users can choose different models, use Fusion or bring in other tools.

Jay Parikh said the increase in generated code makes preserving software quality more important. He cited Code Review Max as a way to help find higher-severity or less obvious bugs, and described AI scanning in GitHub Advanced Security as another part of the response.

One Universe demonstration showed push protection catching a secret before it entered a repository. In the terminal example, a push was rejected after AI detected a generic secret in a YAML file. A second demonstration showed a webhook signing secret detected in source code, with the push declined under repository rules. Parikh described these as examples of GitHub trying to catch mistakes at the point where code is submitted, alongside deeper scanning intended to find more than surface-level vulnerabilities.

He also pointed to work between Microsoft’s and GitHub’s security teams, including efforts with maintainers and open-source projects. Parikh mentioned limiting exposure around package managers such as NPM, using time delays and taking down compromised repositories. He emphasized that this was ongoing work, involving daily improvements and collaboration with the community.

Wang raised a harder question about the economics of open-source dependencies. If code becomes cheap to produce—and security review becomes cheaper too—could organizations replace thousands of dependencies with a much smaller number of components they maintain themselves? The visual accompanying the exchange made the trade concrete: out of 2,000 dependencies, 20 remain external and 1,980 become the organization’s maintenance responsibility.

Parikh said the idea was not far-fetched, but it was no simple cure. Reducing the number of external dependencies does not make the work disappear; it transfers some of it to the organization. A team still has to decide whether it has the people, time and money to maintain what it brings in-house. The choice is therefore not simply “open source or safer code,” but where to place maintenance effort and which risks a team is equipped to manage.

That trade-off did not lead Parikh to expect open source to retreat. He said its value to businesses, builders and creators would continue to grow, and argued that the better goal was to make open source more secure rather than move everyone into walled gardens. Reducing dependencies may make sense for some organizations, but it does not eliminate the responsibility attached to the software they keep.

Jay Parikh said GitHub would continue evolving every layer of its stack, from infrastructure through platform services and user-facing workflows. When Wang asked whether the Azure migration would be complete by the following year, Parikh said the plan was to finish in early 2027, while qualifying that as the target.

The migration diagram showed a live replica in Azure and traffic split between Azure and GitHub data centers. Parikh described the broader task as hard engineering work and said GitHub needed to keep moving fast and make “step function improvements” in every layer of the stack.

He expects software development and deployment to look substantially different a year later, but did not predict a particular agent-to-human ratio. Organizations might be managing thousands of agents, or dozens or hundreds; he said he did not know. That uncertainty is part of why GitHub needs platform primitives that customers can combine in different ways. Continued infrastructure scaling, he said, would remain a constant theme.

As organizations use more agents, Jay Parikh expects security and financial governance to become more prominent. GitHub is developing ways to show organizations where AI spending goes, recommend cheaper or better-suited models for particular uses and set limits—controls that matter especially to large companies.

The Copilot Automations screen shown in the interview illustrated limits per run, day, week and month. Its example set a 150-credit per-run cap, with no daily, weekly or monthly cap. Wang put the business concern plainly: leaders may not object to spending on tokens, provided they can see that the money is being spent well.

Parikh’s example was a team spending $1,000 on tokens in a week and connecting that cost to $25,000 in revenue. Wang objected that revenue may not be a fair measure for an individual coder, suggesting shipped features or story points instead. Parikh widened the measure beyond revenue: cost savings, increased engagement or retention, and improved customer satisfaction could all be relevant. Product and engineering teams, he argued, should be connected to measurable outcomes.

Limits and recommendations can help an organization govern usage, but the question Parikh wants teams to answer is what the spending helped them achieve. The outcome need not be revenue; it might be a shipped feature or another measurable product or business result.

Shawn Wang ended the interview by holding up the GitHub Universe badge: a programmable, Game Boy-like device with buttons and a screen, capable of running Doom. Wang said developers could connect it to Copilot and described it as a reason to attend the conference. Parikh said it was made with Copilot and encouraged him to try it.

Wang used the badge to point to a practical possibility for developers interested in hardware: models may help with the software-hardware interface without requiring someone to know every detail in advance. The exchange connected the discussion of flexible tools and agent-assisted coding to a physical device that attendees could tinker with.