Jay Parikh：编程智能体正在改变 GitHub 的工作方式

主持人 swyx 说，GitHub 必须同时支持越来越多的人类开发者和编程智能体。平台的可靠性受到过批评，但他认为，服务背后的规模和变化同样值得关注。

Microsoft CoreAI 高管 Jay Parikh 在 GitHub Universe 之后接受采访。swyx 说，平台报告智能体创建的拉取请求增长迅速，人类用户也在增长，同时基础设施正在迁往 Azure。

swyx 说，GitHub 已有 2.25 亿开发者，平均每秒增加约一人。他提到 Parikh 曾负责 Facebook 工程团队并领导安全公司 Lacework，以此说明其面对基础设施挑战的经验。

GitHub 也是一个社交网络，开发者在上面共同维护开源软件并发现安全问题。swyx 希望了解，随着编程方式变化，这个共享平台将如何演进。

主题演讲结束后，Parikh 说，活动中的工作坊让开发者能够亲手尝试舞台上来不及逐一展示的安全等功能。采访从 GitHub 的 Octoverse 报告中的规模数据开始。

Parikh 说，社区有 2.25 亿开发者，遍及世界各国。报告显示，连续第二年平均每秒有一位新开发者加入；过去一年有 179 亿次推送、343 亿次提交和 13 亿个拉取请求。

Parikh 说，开源贡献也大幅增长。swyx 指出，每一项活动背后都有数据库、文件和元数据操作；运营开发者社区既有社交层面的需求，也有基础设施需求。

Parikh 认为，AI 可以扩大参与者范围。没有接受过专业软件工程训练的人也可以用编程智能体实现想法、分享代码仓库并征求反馈，无须独自构建。

swyx 问，智能体是否可能让拉取请求这种常见的代码变更审查方式走向终结。Parikh 说，GitHub 应适应新的工作方式，让团队自行配置需要哪些流程。

从学生到大型企业，不同用户需要不同流程。Parikh 说，他在一些个人仓库里会跳过议题和拉取请求，因为他想不断尝试想法，直接继续构建。

开发者 Matt Pocock 的一个 Markdown 指令仓库让 swyx 提出疑问：当智能体既能使用指令也能使用可执行文件时，什么才算代码？Parikh 说，仓库必须容纳不同内容和工作方式。

Parikh 补充说，已有数十年历史的 Java 和 .NET 系统仍在支撑重要业务，需要安全修复、现代化和性能优化。开发者也重视选择适合自己技艺的工具。

swyx 将编程助手的 harness 描述为帮助模型发挥能力的外围系统，其中包括任务路由。他问 GitHub 的 Copilot Fusion 模型选择为什么重要。

Parikh 说，Copilot harness 支持多种模型、工具和集成，其软件开发工具包也可用来构建其他应用。随着模型和工具协议变化，这套系统也需要调整。

Fusion 旨在减轻开发者选择模型的工作。Parikh 说，它希望针对任务平衡质量、速度和价格，而外围 harness 则协调工具和工作流程。

被问及 GitHub 是否既要改进界面又要改进模型时，Parikh 说，公司需要同时改进基础设施、平台服务和用户工作流程。存储、计算、网络和安全都支撑着最终体验。

Parikh 说，手机应用、桌面端和 VS Code 可以使用同一套 harness。用户可以在一台设备上启动工作，在另一台设备上继续，同时保留仓库、议题、安全发现等上下文。

Parikh 希望，即使用户更换模型，积累的上下文、偏好和记忆也能帮助后续工作。他将此与不同厂商各自独立的工具作比较：后者不会自动合并对用户工作的了解。

谈到安全时，Parikh 说，随着生成的代码越来越多，GitHub 需要维持质量。他提到辅助查找严重或隐蔽错误的 AI 代码审查，以及更多扫描能力。

在主题演讲的演示中，一次包含密钥的推送在进入仓库前被拦截。Parikh 还介绍了与 Microsoft 安全团队和开源维护者合作，应对遭入侵的仓库及包管理器风险。

swyx 问，如果 AI 生成代码的成本降低，用自己编写的代码替代大部分外部依赖是否更安全。一个项目可以尝试把数千个依赖缩减为少数核心组件，减少需要信任的外部软件。

Parikh 说，这并非万能解法：替代原有依赖的代码仍需要有人维护。团队必须决定如何投入资金和时间；他倾向于让开源软件更安全，并预计其价值会继续增长。

展望下一年，Parikh 说，GitHub 计划继续改进从基础设施向上的每一层。被问及迁往 Azure 的进度时，他说目标是在下一年完成，这并非保证。

Parikh 说，一年后人们管理的智能体数量可能大不相同，但他不知道团队管理的会是数千个，还是数十或数百个。因此，GitHub 需要提供能由用户组合的基础组件，以适应不同工作方式。

他预计，AI 支出和安全将成为重要关注点。GitHub 希望向组织展示资金流向，在适用时推荐成本更低的模型，并为大企业提供支出上限和治理控制。

Parikh 说，管理者需要把 token 支出与完成的工作和业务成果联系起来。swyx 指出，程序员个人未必直接负责收入；Parikh 同意，也可以衡量成本节省、参与度、留存率和客户满意度。

最后，swyx 称赞 GitHub Universe 的可编程胸牌，它看起来像一台小型游戏机。两人谈到使用 Copilot 制作胸牌，以及在软硬件交界处动手实验的吸引力。