AI写代码拖垮GitHub？OpenAI与Anthropic自建代码托管

GitHub 最近频频出现服务异常。

11月3日，GitHub 官方状态页记录了两起故障，其中一起直接波及 Git 操作。次日，代码合并请求（PR）等核心服务再度异常，部分请求面临失败或高延迟。在很多开发者等待抢修时，一条业界消息引发广泛关注：OpenAI 拟收购代码托管工具服务商 Pierre。

不仅是 OpenAI，主流 AI 编程工具厂商都在加快自建代码托管体系的步伐。Cursor 已支持将项目直接托管于自身平台，Anthropic 更将工程师日常使用的核心代码库迁移到了自研系统。背后的核心驱动力非常明确：AI 写代码的速度正在突破传统开发基础设施的承载极限。

OpenAI 自研 Pando 并拟收购 Pierre

OpenAI 内部很早就遇到了传统系统无法支撑高频代码操作的瓶颈。今年3月便有报道指出，由于频繁遭遇 GitHub 故障，OpenAI 开始搭建内部替代方案。

11月2日，OpenAI 正式公开了其内部研发的 Git 后端 Pando，专门承接海量代码的存取需求。据工程团队介绍，过去单个工程师主要推进一份改动，但在借助 Codex 等工具后，单人能够并发产出多份修改。

开发者数量未成倍扩张，但每次代码推送都会触发大量自动拉取和检查任务。旧系统逐渐吃力，导致拉取变慢甚至合并失败。Pando 自今年4月上线承载真实流量后，将代码推送的中位耗时压缩了近八成。

面向外部 Codex 用户，OpenAI 则计划通过收购 Pierre 补齐代码存储能力。

Pierre 旗下的文件树展示（Trees）与代码差异比对（Diffs）工具早已内置在 Codex 中。此外，Pierre 还运营着名为 Code Storage 的代码存储业务，其客户包括 AI 应用开发平台 Lovable。在 Lovable 上，用户通过自然语言生成网站，后台需要为每个项目创建 Git 仓库追踪修改历史。数据显示，Lovable 此前每周新建仓库超800万个，峰值并发达每秒250个。

收购完成后，OpenAI 有望将这一存储与管理能力全链路沉淀到 Codex 内部。

Cursor 推出代码托管服务 Origin

在被 SpaceX 收购后不久，Cursor 于8月中旬开放了其代码托管功能 Origin 的早期测试。巧合的是，开放测试当天，GitHub 发生了一场长达近8小时的大规模故障。

Origin 为开发者提供了两套工作流：针对新项目，可直接在 Origin 内创建仓库、推送代码、发起评审并完成合并，彻底脱离对 GitHub 的依赖；针对已有 GitHub 项目，则提供双向同步机制，开发者在 Cursor 内留下的评审意见能同步至 GitHub，无需反复切换窗口。

当编码、代码审查与合并都在编辑器内闭环，开发者打开外部代码托管网站的频次正在显著降低。

Anthropic 自研 Scion 支撑日均3万次合并

AI 生成代码带来的负载激增，在 Anthropic 表现得尤为明显。今年5月，Anthropic 内部平均每天合并约2500项改动；到了9月，这一数字已暴涨至每天超3万项。

负责持续集成的自动化系统每天需要拉取约2500万次代码。传统方案依赖数百个 Git 镜像分流，但在主仓库以极高频率刷新的情况下，镜像同步成本极高。Anthropic 发现，多数常驻 AI 智能体（Agent）只需验证局部文件的几行变动，根本无需在本地准备完整的代码仓库克隆。

基于此，Anthropic 打造了自研版本控制系统 Scion。客户端仅按需调取目标文件，历史查询与分支合并则全部交由服务端完成。7位工程师借助 Claude 耗时5个月开发出 Scion 及代码审查工具 Antique，并将核心代码库全量迁移完毕。

面对一天上万项的合并规模，改动审查流程也发生了重构。Anthropic 引入了由 Claude 主导的第一道审查，赋予模型浏览器操作权限，模拟真实环境检验界面和逻辑，并生成操作录像与测试日志供人类工程师核验。