OpenAI要把代码仓库装进Codex，GitHub的地盘也要抢？

你打开 Codex，让它修一个 Bug。

它找到文件，改完代码，把差异摆在你面前。到这一步，团队还有一件事要决定。这份代码存在哪儿，谁来审，什么时候合进去？

OpenAI 现在盯上了后半程。

11 月 4 日，OpenAI 官宣拟收购 Pierre Computer。你可能没听过这家公司，但如果你在 Codex 里翻过项目文件、看过代码改动，你已经用过它做的工具。现在，OpenAI 还想把 Pierre 的 Code Storage 接进来。

图注：OpenAI 拟收购 Pierre Computer，计划扩展 Codex 的代码相关工具。

两天前，OpenAI 刚亮出自研 Git 后端

11 月 2 日，OpenAI 发了一篇工程长文，介绍内部的 Git 仓库后端 Pando。

团队遇到的问题很好理解。一个工程师改一条分支，和一群 Agent 同时改不同分支，对仓库的要求完全不同。有人在推送新代码，有人在拉取历史，还有 Agent 正在另一条分支上跑任务。代码写得越快，底下的仓库就越要扛得住这些并发操作。

据 OpenAI 披露，Pando 已经支撑其内部主代码仓库的开发，中位推送延迟降到此前的大约五分之一，每天传输接近 1 PB 的 Git 数据。

两天后宣布拟收购的 Pierre，做的是同一个问题的另一面。它给应用提供可编程的 Git 仓库服务，也做了文件目录、代码差异这些开发者每天会碰到的界面工具。Pando 展示了 OpenAI 怎么处理内部大量并发的代码操作，Pierre 的能力则有机会被装进用户手里的 Codex。

图注：Pierre 的 Diffs 官方演示。Codex 已采用这一开源组件来展示代码改动。

GitHub 的地盘，究竟是哪一块？

想想你平时为什么打开 GitHub。你会去看某次提交改了什么，会在 Pull Request 里问同事一句“这行为什么这么写”，也会等测试跑完，再决定要不要合并。仓库之所以重要，是因为团队可以在这里围绕代码做决定。

图注：Pull Request 把代码变更、讨论和审查放在同一个工作流里。

如果 Codex 能把写代码、看差异、存版本这几步连起来，一个变化可能先发生：工程师每天看代码改动的第一站，从 GitHub 页面变成 Codex。 团队的主仓库仍然可以托管在 GitHub，日常操作的入口却可能先变。

眼下，收购仍待监管批准。OpenAI 表示，交易完成后会着手把 Code Storage 的功能带进 Codex，Pierre 的开源项目也会继续开源。

所以，接下来值得看的，是 Codex 会把仓库、审查和协作做到哪一步。当 Agent 一天能替你改十个分支，你会在哪个界面决定，哪一条值得合进去？