Compiled by Lin Qibei and edited by Cai Fangfang.<\/p>\n
GitHub\u2019s own leader is no longer using pull requests on every project. Jay Parikh, executive vice president of Microsoft CoreAI and head of GitHub, says a pull request should not be a required step for all developers. On personal projects used to test an idea, he does not create a pull request or manage issues; he turns the idea into code and continues building.<\/p>\n
The comments come at a specific moment. GitHub data show that, as of September this year, more than 40% of pull requests on the platform had their first version drafted by a coding agent, compared with 17% in March. In about six months, agent-initiated pull requests grew roughly sixfold. As more code is produced by agents, collaboration processes designed around human developers may need to be reconsidered.<\/p>\n
In a Latent Space podcast interview released on November 7, Parikh discussed GitHub\u2019s view of the change. Besides whether pull requests remain necessary, he addressed multi-model collaboration, code review, software supply-chain security, and the return on AI programming.<\/p>\n
One discussion asked whether, if AI can generate code quickly, a team could rewrite many open-source dependencies to reduce supply-chain risk. Parikh cautioned that even when AI rewrites the code, later maintenance does not disappear.<\/p>\n
In traditional collaboration, a pull request is where code changes are submitted and where teammates review, discuss, and merge them. With coding agents in the workflow, some developers are asking whether that process still fits every situation.<\/p>\n
The host cited Peter Steinberger, creator of OpenClaw, who has suggested that pull requests might come to an end. Parikh said GitHub will adjust the platform as development paradigms and working methods change. If a feature is no longer useful to some users, or if they do not want it to be mandatory, the platform can make it configurable.<\/p>\n
Using his own habits as an example, Parikh said GitHub users do not share the same need for collaboration and management processes. Large enterprises may still require code review, permission management, and change records. For a personal experiment, complex collaboration may not add value.<\/p>\n
This does not mean GitHub treats code review as unnecessary. The point is whether different settings should follow the same process: a personal experiment can stay direct and efficient, while enterprise work involving multiple people, permissions, and code-quality requirements still needs review.<\/p>\n
For GitHub, the question is whether a collaboration flow designed around people should remain the default for every project once a developer can describe a change to an agent and have the agent make it. In Parikh\u2019s view, the platform should not decide that for every developer.<\/p>\n
Parikh also discussed how developers choose among models that differ in capability, price, and speed. Tasks do not all need the same model. A simple change may need only a faster, lower-cost model, while complex debugging or architecture work may need stronger reasoning or several models together.<\/p>\n
He wants the system to handle part of that choice. Copilot Harness and Copilot Fusion are intended to work together: Harness connects models and tools and orchestrates the work; Fusion selects a model for the task, reducing the need for developers to keep weighing capability, speed, and cost.<\/p>\n
The mechanism is not free. More models generally mean more calls, longer runtimes, and higher AI credit use. GitHub wants the system to balance quality, speed, and cost while leaving developers the choice of models and tools.<\/p>\n
At its conference, GitHub reported a comparison on the Artificial Analysis Coding Agent Index: the score gap between Fusion Max and Opus 5.5 Max was less than 2 points, while Fusion Max\u2019s cost per task was about half and its time was about 40% lower.<\/p>\n
GitHub is also trying to let developers continue work across devices and tools. Parikh\u2019s example was starting a task on a phone and later opening a computer to continue, or sending a new idea from the phone so the agent keeps working.<\/p>\n
Session continuity supports following the same cloud agent session across the GitHub Copilot app, VS Code, the command line, and the web. According to GitHub, when a developer switches devices or tools, the agent can continue working in the cloud, and the developer can return to the same session to see progress.<\/p>\n
As agents generate more code, teams have more to review. Parikh said GitHub is strengthening code review and security scanning so developers can still find problems as development speeds up.<\/p>\n
At GitHub Universe, GitHub introduced Copilot code review Max to help find more serious and less obvious code issues. A live demo showed secret protection: when a developer accidentally pushed a secret to a repository, the system identified it during the push and blocked the potential leak.<\/p>\n
Beyond secret leaks, GitHub faces supply-chain security. Parikh said GitHub is working with Microsoft\u2019s security team and open-source maintainers to reduce risks to package managers and to handle compromised repositories.<\/p>\n
The host raised a further idea: if AI lowers the cost of writing code and of security review, a team might implement some functions itself and depend less on external open-source components. He supposed a project depended on 2,000 open-source components, each a potential risk surface, and asked whether keeping only 20 and implementing the rest in-house would reduce risk.<\/p>\n
Parikh said the question is worth discussing, but replacing open-source dependencies is not a cure-all. Even if a team keeps only 20 open-source projects, the functions of the other 1,980 components still have to be maintained by the team.<\/p>\n
AI lowers the barrier to implementing code, but maintenance is not only writing and changing code. A component needs ongoing adaptation to external interfaces, vulnerability fixes, and compatibility work, and someone must judge whether a change is reliable and whether it affects other systems that depend on it. Even if agents complete part of that work, an entity still bears the maintenance responsibility.<\/p>\n
For a company, rewriting open-source components moves maintenance cost previously shared by the open-source community inside the company. A lower cost of generating code does not necessarily mean long-term ownership cost falls by the same proportion. Fewer external dependencies also do not remove security risk. Components a company builds itself can still contain vulnerabilities and still need continuous checking and repair.<\/p>\n
Parikh therefore reminded developers to consider not only whether code can be written, but where money, people, and time should be spent. In his view, open source remains important for companies, developers, and creators. He would rather solve software security together with the open-source community than have every team move to a closed approach.<\/p>\n
As agents take on more development work, companies also need to see AI usage and spending.<\/p>\n
Parikh said GitHub is providing tools that help organizations view costs and receive suggestions on model choice. If a team is using one model for a particular kind of task, the system can indicate whether other models are available. Large enterprises also need governance such as usage limits.<\/p>\n
Spending is only part of the measure. The host said company leaders may not mind teams buying tokens and care more about whether the spending produces enough value. Parikh agreed and said teams need feedback between investment and results.<\/p>\n
They stressed different measures. Parikh said that if token spending produces revenue, a company can judge whether the spending was worthwhile. The host noted that programmers are usually not directly responsible for revenue; what they can see directly may be that a feature was delivered.<\/p>\n
Parikh then said that, besides revenue, cost savings, user engagement, retention, and customer satisfaction can also be watched. In his view, product and engineering teams need to pay attention to these measurable results.<\/p>\n
The exchange reflects a practical difficulty in judging the value of AI programming: token use is easy to count, and code commits and feature delivery are relatively easy to count, but whether those outputs actually improve software quality, development efficiency, or business performance often takes longer to judge.<\/p>\n
An agent can generate a large amount of code in a short time, but whether that code passes review, needs rework, or runs stably can affect actual delivery. More generated code does not necessarily mean an equivalent gain in efficiency.<\/p>\n
For companies already using coding agents at scale, the question is therefore not only model-call cost, but how to measure the work agents actually complete and the value that work ultimately creates.<\/p>\n
Agent-driven change is not limited to the tools developers use. It is also changing the infrastructure GitHub itself needs.<\/p>\n
As automated development activity increases, GitHub must handle more commits, repository operations, and related compute. Parikh said the team is continually adjusting the underlying architecture for the new scale.<\/p>\n
One major piece of work is migration to multi-region deployment on Azure. According to an article Parikh published during GitHub Universe 2026, GitHub expects to complete the related migration in early 2027 and to keep adding compute, storage, and network capacity.<\/p>\n
What Parikh finds harder to predict is not how much code GitHub will process, but how developers will organize agent work. He is not sure whether one developer will manage dozens, hundreds, or thousands of agents.<\/p>\n
The challenge for GitHub is changing with that uncertainty. As more software development is carried out by agents, the platform needs to support not only storing and collaborating on code, but also task scheduling, model selection, continuous execution, security review, and control over that work.<\/p>\n
Podcast: https:\/\/www.youtube.com\/watch?v=rSWiNE92xqM<\/p>\n
Original article: https:\/\/www.infoq.cn\/article\/x0B056QFxzYEewT1Et34<\/p>\n","protected":false},"excerpt":{"rendered":"
Compiled by Lin Qibei and edited by Cai Fangfang. GitHub\u2019s own leader is no longer using pull requests […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-10","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/blockoala.com\/index.php\/wp-json\/wp\/v2\/posts\/10","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blockoala.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blockoala.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blockoala.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blockoala.com\/index.php\/wp-json\/wp\/v2\/comments?post=10"}],"version-history":[{"count":0,"href":"https:\/\/blockoala.com\/index.php\/wp-json\/wp\/v2\/posts\/10\/revisions"}],"wp:attachment":[{"href":"https:\/\/blockoala.com\/index.php\/wp-json\/wp\/v2\/media?parent=10"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blockoala.com\/index.php\/wp-json\/wp\/v2\/categories?post=10"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blockoala.com\/index.php\/wp-json\/wp\/v2\/tags?post=10"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}