Coding Agents Now Draft 40 Percent of GitHub Pull Requests
GitHub head Jay Parikh revealed that coding agents now draft the first version of over 40% of pull requests on the platform, up from 17% in March, a roughly sixfold rise in half a year. He argues PRs should not be mandatory for every project and that GitHub will make collaboration steps configurable, while stressing that code review and access control remain essential for enterprise teams.
Related Entities
Full Report
Contents5 sections
编译｜林绮蓓
编辑｜蔡芳芳
GitHub 自己的负责人，已经不在所有项目里使用 Pull Request 了。
在微软 CoreAI 执行副总裁、GitHub 负责人 Jay Parikh 看来，PR 不应该成为所有开发者必须遵循的流程。对于一些用来验证想法的个人项目，他甚至不需要创建 PR，也不想管理 Issue，而是直接把想法变成代码，继续开发。
这样的表态发生在一个特殊的时间点。GitHub 最新数据显示，截至今年 9 月，平台上超过 40% 的 Pull Request 已由 Coding Agent 起草首版，而今年 3 月这一比例还只有 17%。短短半年，Agent 发起的 PR 数量增长了约 6 倍。当越来越多代码由 Agent 生成，过去围绕人类开发者设计的软件协作流程，是否也需要重新调整？
11 月 7 日发布的 Latent Space 播客访谈中，Parikh 谈到了 GitHub 对这一变化的思考。除了 Pull Request 是否仍然必要，他还讨论了多模型协作、代码审查、软件供应链安全，以及 AI 编程的投入产出问题。
其中一个颇有意思的讨论是：既然 AI 已经能够快速生成代码，开发团队能否用它重写大量开源依赖，减少供应链风险？Parikh 提醒，即使 AI 能替你重写代码，后续的维护工作也不会凭空消失。
Pull Request 不必成为所有项目的必经环节
在传统的软件协作流程中，Pull Request 通常用于提交代码变更，并为团队成员提供审查、讨论和合并代码的场所。但随着 Coding Agent 加入开发过程，一些开发者开始重新思考，这套流程是否仍然适用于所有场景。
访谈中，主持人提到了 OpenClaw 创建者 Peter Steinberger，他曾提出 Pull Request 或许会走向终结。针对这一观点，Parikh 则表示，GitHub 会随着新的开发范式和工作方式调整平台。如果某项功能对部分用户不再有用，或者他们不希望它成为必需环节，平台可以考虑让这项功能变得可配置。
Parikh 以自己的使用习惯为例，指出 GitHub 不同用户对协作和管理流程的需求并不相同。对于大型企业，代码审查、权限管理和变更记录可能不可或缺；但对于个人实验项目，繁复的协作机制未必能带来额外价值。
不过这并不意味着 GitHub 认为代码审查已经不再必要。Parikh 所讨论的，是不同开发场景是否需要遵循相同的协作流程：个人实验项目可以追求直接和高效，而涉及多人协作、权限管理和代码质量要求的企业项目，仍然需要相应的审查机制。
对 GitHub 来说，这意味着一个值得重新思考的问题：当开发者可以直接向 Agent 描述需求，并让它完成代码修改，过去以人为中心设计的协作流程，是否还应该成为所有项目的默认选择？
至少在 Parikh 看来，答案不应该由平台替所有开发者决定。
AI 编程不需要总用最强模型，GitHub 想让系统自己决定
除了开发流程，Parikh 还谈到了另一个具体问题：面对能力、价格和响应速度各不相同的模型，开发者如何为每项任务选择合适的模型？不同开发任务对模型能力的要求并不相同。简单的代码修改可能只需要一个速度更快、成本更低的模型，而复杂的调试和架构调整，则可能需要更强的推理能力，甚至多个模型协作。
Parikh 希望将部分选择工作交给系统。在他看来，Copilot Harness 和 Copilot Fusion 可以相互配合：前者负责接入模型、工具，并编排开发过程中的工作；后者则根据任务选择模型，减轻开发者在能力、速度和成本之间反复权衡的负担。
这种机制并非没有代价。更多模型参与通常意味着更多调用、更长耗时以及更高的 AI 积分消耗。因此，GitHub 希望让系统在质量、速度和成本之间做出权衡，同时让开发者保留模型和工具的选择权。
GitHub 在大会上还公布了一组对比数据：在 Artificial Analysis Coding Agent Index 中，Fusion Max 与 Opus 5.5 Max 的分数差距不到 2 分，但前者单任务成本约为后者的一半，耗时减少约 40%。
模型选择之外，GitHub 还在尝试让开发者能够在不同设备和工具之间接续工作。Parikh 举例说，一个人可以先在手机上发起任务，之后再打开电脑继续处理；有了新的想法，也可以通过手机补充给 Agent，让它继续工作。
GitHub 的 Session continuity 功能支持开发者在 GitHub Copilot 应用、VS Code、命令行和网页之间，跟进同一个云端 Agent 会话。按照 GitHub 的介绍，切换设备或工具时，Agent 可以继续在云端工作，开发者也能回到同一会话中查看进展。
AI 能重写 2000 个开源依赖，却无法让维护责任消失
随着 Agent 生成的代码越来越多，开发团队需要审查的内容也在增加。Parikh 表示，GitHub 正在加强代码审查和安全扫描能力，希望在开发速度提升的同时，帮助开发者发现代码中的问题。
在 GitHub Universe 大会上，GitHub 介绍了 Copilot code review Max，用于帮助开发者发现更严重、更隐蔽的代码问题。另一项现场演示则展示了密钥保护：当开发者意外将密钥推送至仓库时，系统在推送过程中识别并拦截了潜在泄露。
除了防范密钥泄露，GitHub 还需要面对软件供应链中的安全问题。Parikh 表示，GitHub 正在与微软安全团队、开源项目维护者合作，降低包管理器面临的风险，并处理已被攻陷的代码仓库。
围绕开源软件安全，播客主持人提出了一个更进一步的设想：如果 AI 降低了编写代码和安全审查的成本，开发团队或许可以自己实现部分功能，减少对外部开源组件的依赖。他假设，一个项目依赖 2000 个开源组件，每个组件都可能成为潜在的安全风险面；如果只保留其中 20 个，其余部分由团队自己实现，是否能减少风险？
Parikh 认为这个问题值得讨论，但自行替代开源依赖不是万能方案。即使团队只保留 20 个开源项目，其余 1980 个组件所承担的功能，之后仍需要由团队自己维护。
AI 降低了代码实现的门槛，但软件维护并不只有编写和修改代码。一个组件需要持续适配外部接口、修复安全漏洞、处理兼容性问题，还需要有人判断修改是否可靠、是否会影响依赖它的其他系统。即使这些工作的一部分能够由 Agent 自动完成，最终承担维护责任的主体仍然存在。
对企业而言，自行重写开源组件实际上意味着将原本由开源社区共同承担的维护成本转移到内部。代码生成成本下降，并不必然意味着软件的长期拥有成本也会同比下降。而且，减少外部依赖也不等于消除安全风险。企业自己实现的组件同样可能存在漏洞，后续仍然需要持续检查和修复。
Parikh 因此提醒开发者，不仅要考虑代码能否写出来，还要考虑资金、人力和时间应该投入到哪里。在他看来，开源软件对企业、开发者和创作者仍然具有重要价值。他更希望与开源社区一起解决软件安全问题，而不是让每个团队都转向封闭的开发方式。
从 Token 成本到实际交付：企业该如何衡量 Coding Agent？
当 Agent 承担更多开发任务，企业也需要了解 AI 的使用情况和支出。
Parikh 表示，GitHub 正在提供相关工具，帮助组织查看费用，并在模型选择上给出优化建议。例如，如果某个团队正在使用一种模型处理特定类型的任务，系统可以提示是否有其他模型可供选择。对于大型企业，还需要提供使用限额等治理能力。
但支出只是衡量的一部分。主持人提出，企业负责人未必介意团队花钱购买 Token，更关心的是这些投入是否带来了足够的价值。Parikh 对此表示认同，并提出，团队需要建立投入与结果之间的反馈。
双方对如何衡量结果有不同的侧重。Parikh 举例说，如果 Token 支出带来了收入，企业可以据此判断投入是否值得；主持人则指出，程序员通常不直接对收入负责，他们能够直接看到的成果可能是交付了某项功能。
Parikh 随后提到，除了收入，也可以关注成本节省、用户参与度、留存率和客户满意度等指标。在他看来，产品团队和工程团队需要关注这些可以衡量的结果。
这也反映出企业衡量 AI 编程价值时面临的现实难题：Token 消耗容易统计，代码提交和功能交付也相对容易计数，但这些产出是否真正提升了软件质量、开发效率或业务表现，往往需要更长周期才能判断。
例如，Agent 可以在短时间内生成大量代码，但这些代码是否能够通过审查、是否需要返工，以及最终能否稳定运行，都可能影响实际交付效果。代码生成量增加，并不必然意味着团队获得了同等幅度的效率提升。
因此，对于已经开始规模化使用 Coding Agent 的企业而言，除了关注模型调用成本，还需要考虑如何衡量 Agent 实际完成的工作，以及这些工作最终创造的价值。
Agent 时代，GitHub 自己也需要重建基础设施
Agent 带来的变化不仅发生在开发者使用的工具中，也正在改变 GitHub 平台本身的基础设施需求。
随着自动化开发活动增加，GitHub 需要处理更多代码提交、仓库操作和相关计算任务。Parikh 表示，团队正在持续调整底层技术架构，以适应新的使用规模。
其中一项重要工作是迁移至 Azure 多区域部署。根据 Parikh 在 GitHub Universe 2026 期间发表的文章，GitHub 预计在 2027 年初完成相关迁移，并持续增加计算、存储和网络容量。
但对 Parikh 而言，未来真正难以预测的，或许不是 GitHub 要处理多少代码，而是开发者会如何组织 Agent 的工作。他并不确定未来一个开发者会管理几十个、几百个，还是数千个 Agent。
对 GitHub 来说，挑战也正在发生变化：当软件开发越来越多地由 Agent 执行，平台需要支持的将不只是代码的存储与协作，还包括任务调度、模型选择、持续执行、安全审查，以及围绕这些工作的控制权。