GitHub两天两故障：AI写代码太快，基础设施扛不住了？
AI写代码太快，基础设施跟不上了
AI写代码的速度上来了，底层设施却有点吃不消。
听雨 发自 凹非寺 量子位 | 公众号QbitAI
GitHub怎么又挂了……
11月3日，官方状态页一天记录了两起故障，其中一起波及Git操作。
第二天，也就是4日，合并请求等服务同样出了问题，有些请求直接失败，有些则卡着延迟。
代码明明改完了，想让同事看看能不能合进主项目，结果偏偏在这一步卡住。
有网友干脆调侃起来：
正好趁这会儿去喝杯咖啡。
GitHub还在抢修，Axios那边抛出一条独家消息：
OpenAI打算收购代码托管工具Pierre，交易尚未交割。
两件事凑到一块，时间上确实有点巧。
更关键的是，做AI编程工具的几家公司，已经有好几家开始自己管代码了。
马斯克旗下的Cursor，现在允许开发者把整个项目直接存放在Cursor里。
Anthropic走得更远，把自家工程师日常使用的主代码库迁进了自研系统。
这几家公司为什么都盯上了这件事？
原因在于AI写代码越来越快，现有基础设施慢慢跟不上了……
OpenAI一边自造，一边还准备再买一家
代码系统跟不上，OpenAI自己就深有体会。
今年3月，The Information曾报道，OpenAI工程师多次碰上GitHub服务中断，公司当时就在做内部替代工具。
11月2日，也就是前几天，它把自家Git后端Pando公开出来，负责内部代码的存取等操作。
据工程团队介绍，过去一个工程师手里只推进一份改动；有了Codex之后，一个人可以同时准备好几份。
每推送一次代码，又会触发多个自动化任务，去拉代码、跑检查。
写代码的人并没有一下子多出好几倍，可系统要处理的活却变多了。
老系统渐渐扛不住，拉取、推送变慢，合并也开始失败。
Pando早在4月就接手了真实的开发流量。OpenAI给出的统计是，换用之后单次推送的中位耗时少了接近八成。
自家工程师的麻烦解决了。OpenAI还打算把Pierre收进来，让Codex用户也能用上代码存储这类能力。
说起来，Pierre的东西你可能早就碰过——比如你让Codex修一个bug，它一口气动了五个文件。
你点开文件列表挑出其中一个，再逐行看它删了什么、加了什么。前者用的是Pierre做的Trees，后者用的是Pierre做的Diffs，两套工具早已接进Codex。
Pierre手上还有一门叫Code Storage的生意，AI应用开发平台Lovable就是它的客户之一。用户在Lovable里敲几句话就能生成一个网站，后台每个项目都得靠一个或多个Git仓库存代码、留修改记录。
按Pierre今年8月披露的数字，Lovable当时每周新建仓库超过800万个，峰值每秒250个。
OpenAI的计划是，等收购交割完成，把Code Storage的能力装进Codex。往后开发者让AI写代码、查它改了哪儿、再把这一版存下来，都有望在Codex里走完。
当然，这笔交易眼下还得过监管批准等交割条件。
Cursor开放代码托管那天，GitHub也挂了
大家可能还记得，8月14日马斯克的SpaceX把Cursor收入囊中。三天后，Cursor的代码托管服务Origin开放早期测试。
偏偏就在8月17日，GitHub闹出一场持续7小时47分钟的故障。Cursor员工Matt Palmer当时还打趣说，他们本想更早发布，可GitHub它、它又挂了！！
Origin给开发者留了两条路：做新项目可以直接在Origin建仓库，代码推到Cursor，请同事审、收修改意见、合分支，这些都能不走GitHub；老项目已经放在GitHub上的，也可以只同步一份到Cursor。
你在Cursor里留的评论，队友回到GitHub照样能看见，代码仍以GitHub上的版本为准。
那问题就来了：写代码、审代码、合并，都能在Cursor里办完，那我还专门打开GitHub干啥？
哪怕是老项目、仓库还搁在GitHub，审代码的人也已经可以不去那儿了。
Claude写得太快，Anthropic自己造了一套
OpenAI和Cursor把越来越多的开发操作搬进了自家产品，Anthropic这边则是内部活儿多到必须重做代码管理系统。
说到底，还是Claude写代码太快了。
按Anthropic公布的数字，今年5月公司平均每天合并约2500项代码改动，到9月一天已经超过3万项。换句话说，每天有3万多份修改被合进团队共用的代码版本里。
单是自动化测试这类持续集成任务，每天就要取用约2500万次代码。高峰时公司维护着数百个Git镜像，靠这些仓库副本分摊压力。可主仓库更新越快，副本就越难跟上。
工程师注意到，来拉代码的多是常年在线的Agent和自动化任务。有些任务不过想知道某个文件改了哪几行，何必先在本地备一份仓库？让服务器算好、把结果送过去就够了。
顺着这个想法，Anthropic做出了Scion。客户端用到哪个文件才去取哪个；查历史、建提交、合并改动，都交给服务器。
7名工程师带着Claude，用5个月搭出这套内部版本控制系统，还有配套的代码审查工具Antique等，公司主代码库也整体迁了过去。
不过Scion主要服务的是Anthropic这种体量大、改动密的内部代码库。Claude Code的公开仓库等社区资源，依旧放在GitHub上。
一天三万项改动，谁来把关？代码取得更快、存得更顺之后，还有个更棘手的问题：这些修改怎么判断能不能用？
在最近一场对谈中，Anthropic的Addy Osmani讲了他们的做法：先让Claude审一轮，还得给它创造条件，像真实用户那样把功能跑起来。
比如改的是网页，就让它打开浏览器看页面、点功能，再跑该跑的测试。之后工程师检查它交来的验证证据，包括操作录像、页面截图和测试结果。每项改动仍有人负责，出了问题由负责人处理。
△Claude Code团队公布的代码改动检查与发布流程
Anthropic的工程博客还提到一个更麻烦的情形：一轮测试跑着跑着，代码库里可能又合进了成百上千项改动。这个规模下，团队发现用仓库全局锁来协调合并队列很难跑得动，于是把力气放到合并之后、部署之前的自动测试上。
公司方面也承认，并发修改还是有可能撞上冲突。按照他们的说法，Claude 修复冲突的速度一般比人快，但具体的量化数据没有对外公布。
One More Thing。看到这里你大概会问，那 GitHub 呢？
GitHub 其实也没歇着，底层同样在重做。10月28日，它对外披露，今年已经新增 400万个CPU核心和160PB高速存储，服务还在继续往 Azure 上迁。
光加资源还不够，原来的排队方式也得改。以往哪怕几个 Agent 各在不同分支上提交改动，到了同一个仓库的写入环节仍要互相等着。GitHub 正让这些更新能并行处理，把没必要的排队压下去。
△左侧按整个仓库排队，右侧允许不同分支等引用的更新并行进行
代码存进去之后，还有大量自动测试任务要来取用。GitHub 也在把读写所用的资源拆开：来取代码的任务一多，就给负责读取的服务单独扩容，让两边少抢资源。
这些改造还在一步步推进。OpenAI、Cursor 已经自己提供代码托管，Anthropic 重做了内部系统，GitHub 也在改造自己的基础设施。
说到底，大家都是在应对 AI 带来的开发工作量。至于咱们用的人，要求其实很简单：
代码写完了，该检查的也检查过了，准备合进去的时候，可别又给我掉链子啊……
