Py学习  »  Git

AI 一天能造三座屎山,GitHub 先扛不住了:单月 73.8 亿次 Commit,架构都得重写~

IT服务圈儿 • 6 小时前 • 13 次点击  

来源丨经授权转自 菜鸟教程(ID:runoob)

作者丨RUNOOB

突然好奇,今天还有人每天认真看 AI 写的代码吗?

话说,以前程序员写代码,写半天、改半天,最后才提交一次。

现在好了,Claude Code、Codex、OpenCode 这些 Agent,改几行代码就能提交,跑个测试再提交,发现 Bug 继续改,改完接着提交……

然后事情开始无法掌控了,之前分享过别人的经历:Vibe Coding 后,代码已经没人能看懂了~团队没法掌控了~

原帖:https://v2ex.com/t/1224558

现在人类已经完全无法掌控 AI 写的代码了,连 GitHub 的服务器都有点扛不住这节奏了。

2026 年 10 月底,GitHub 在 Universe 大会上公布:今年已经新增 400 万个 CPU 核心、160 PB 高速存储和 50 Tb/s 网络容量,同时还在向 Azure 多区域架构迁移,预计 2027 年初完成。

GitHub 表示,光加机器已经解决不了问题,底层 Git 存储架构也得重新设计。


1、先看看 AI 把 GitHub 折腾成什么样了

GitHub 的 Octoverse 2026 报告和工程团队的技术文章,给出了这样一组数据。

2026 年 9 月:

  • 73.8 亿次 Commit,超过去年同期的 5 倍。
  • 32.6 亿次 GitHub Actions Job,同比超过 4 倍。
  • PR 合并数量同比接近 4 倍。
  • 超过 40% 的 PR 由 Agent 起稿,3 月这个比例还是 17%。
  • 仅 9 月,就有大约 1.1 亿个 PR 由 Agent 发起。

再看过去 12 个月:

  • 179 亿次 Push,超过前两个统计年度之和。
  • 343 亿次 Commit,比两年前增长超过 3 倍。
  • 13 亿个 PR 被合并,平均每天约 350 万个。

GitHub 最忙的那个仓库,2026 年 8 月一个月就收到了大约 10 亿次请求,这可是单个仓库的数据。

现在 Agent 大规模参与开发,再加上开发者增长和自动化工作流,让 GitHub 的代码量上了一个台阶。

为什么压力这么大?不只是代码多了、硬盘不够装。

人写代码,中间会思考、调试、喝水,Agent 则可以在修改、提交、测试、修复的循环里不停跑,频繁保存状态、建立检查点,一次操作慢一两秒,重复上百轮,就成了瓶颈。

更麻烦的是,一个大型仓库里,可能同时有几千个 Agent 在不同分支上工作,它们可以各写各的,最后很多修改却要合并回主干。

每次 Push 后面,还跟着测试、代码扫描、拉取最新代码等操作。

GitHub 举出的高负载场景中,同一个分支的最新状态,每分钟可能被 Clone 或 Fetch 上千次。

一个 Agent 写,后面一群自动化系统跟着忙。

2、光加机器,已经不够了

扩容之外,底层架构也得改。

原来的 Git 存储架构,默认把一个仓库的完整副本保存在五台文件服务器上。这样既能容错,也能分摊读取请求。问题是,写入时还得协调不同副本的状态,副本增加,协调工作也会增加。

新架构准备把存储和计算分开:

  • 权威数据放到持久化存储层,由计算 Worker 处理读取r。

  • 需要更多读取能力,就增加 Worker。

  • 仓库压缩、垃圾回收等维护任务,则交给专门的后台 Worker。

同时,一次 Push 中必须协调的步骤尽量缩短,其他工作尽可能并行。

GitHub 公布的内部基准测试中,新架构的写入吞吐量最高达到原来的 35 倍。这个数字指内部测试,不代表网站现在已经整体提速 35 倍。

扩容计划的变化也很直观:

  • 2025 年 10 月,GitHub 启动的是 10 倍容量计划。

  • 到 2026 年 2 月,就发现可能不够,把未来架构目标提高到了 30 倍。

模型公司还在比谁写代码更快,GitHub 已经开始重新算需要多少服务器了。

3、8 倍提交,算得上 8 倍生产力吗?

Octoverse 2026 还有一组数据:在 2026 年新建的仓库中,包含 Agent 配置文件的仓库,平均 Commit 数量是其他仓库的 8 倍,但这不能直接换算成 8 倍生产力。

提交多,可能是功能做得多,也可能是在反复尝试、修改和回滚。Commit 数量也不等于 Push 次数,更不等于 CI 执行次数。

活动更频繁,最后产出了多少有价值的软件,还得另算。

用 AI 写代码时,这个问题很容易碰到:Agent 一个小时写出几千行,你却可能要花半天检查。它写得快,你也确实省了敲代码的时间,但理解和审查的工作还在。

而且,处理得快不保证结果正确。

GitHub 在 2026 年 4 月发生过一次 Merge Queue 事故,影响了 2092 个 PR,原因是合并逻辑的回归缺陷,相关测试和监控没能提前发现,并非 Agent 提交太多导致。

如果底层有个 Bug 没被发现,自动化也可能让错误传播得更快。

所以我觉得,接下来更费功夫的,可能是判断哪些代码值得留下,以及我们能理解、验证和维护多少代码。


GitHub 可以扩容服务器,人看代码的时间却不会跟着翻几倍,以后评价开发效率,除了写了多少行、提交了多少次,更得看功能是否可靠、问题是否解决。

毕竟,把十座屎山堆起来不难,难的是十年以后,还有人知道这些屎山为什么不能删。


参考资料:

  • GitHub Universe 2026:https://github.blog/news-insights/company-news/github-universe-2026-evolving-every-layer-of-the-stack/
  • GitHub Engineering:https://github.blog/engineering/architecture-optimization/building-git-infrastructure-for-agent-scale-development/
  • Octoverse 2026:https://github.blog/news-insights/octoverse/octoverse-commits-pushes-reach-new-highs-in-2026-as-developers-build-with-agents/
  • GitHub CTO 可用性说明:https://github.blog/news-insights/company-news/an-update-on-github-availability/

1、微软发布DirectX光追史上最大更新!帧率飙升66倍、显存暴降90%

2、Stack Overflow 已死,月增提问不足 1000,爆降 99.3%

3、太猛了!首个 Three.js 组件库突然开源!160+ 3D 组件!

4、用 AI 写代码,该选什么语言?Python、TypeScript 谁更吃香,看看主流 Agent 自己怎么选~

5、 90年代 Linux 留下的3个设计,Windows 和 macOS 也在使用

Python社区是高质量的Python/Django开发社区
本文地址:http://www.python88.com/topic/203205