GitHub提交量四月翻倍，代码审查能力未跟上

很高兴你来到这里。你每周一至周五都会收到 TNS 最优质的内容，让你紧跟新闻前沿、保持最佳状态。

查收你的收件箱，里面有一封确认邮件，你可以在那里调整偏好设置，甚至加入其他群组。

在你最喜欢的社交媒体上关注 TNS。

在 LinkedIn 上成为 TNS 的关注者。

在等待你的第一封 TNS 通讯时，看看最新的精选和热门文章。

我一直在等待 Agent 生成的代码出现在公共基础设施数据中，而不是供应商的基准测试里。8 月，它出现了。GitHub 现在每月处理 29 亿次提交，并表示已经跟不上了。月提交量在四个月内翻了一倍多，从 4 月的 14 亿增长到 8 月的 29 亿。

增长搞垮了平台。8 月 17 日，GitHub 宕机 7 小时 47 分钟，原因是其美国中部数据中心的某个核心基础设施组件未能随流量扩展。CTO Vladimir Fedorov 的复盘毫不遮掩：如果你那天正试图发布软件，GitHub 让你失望了。补救措施是超大规模厂商在需求超过供给时的标准做法——新增超过 300 万个 CPU 核心、120 PB 高速存储，以及加速向 Azure 迁移——Azure 现在承担了平台 58% 的负载。

大多数报道把这当作一个容量故事，对 GitHub 来说确实如此。但你应该担心的数字是复盘报告从未触及的。那 29 亿次提交每一次都隐含着一个断言：这次变更可以正常工作。而在产生、传输和合并这些提交的系统里，几乎没有任何东西对这个断言进行过实际运行验证。

"代码生成已经变成了机器节奏，其体积曲线呈指数增长。而验证仍然是人工节奏，其容量曲线接近平坦。"

这就是 GitHub 数据背后的警告。代码生成已经变成了机器节奏，其体积曲线呈指数增长。验证——即证明一次变更做到了预期目的且没有破坏已有功能的工作——仍然是人工节奏，其容量曲线接近平坦。这两条曲线之间的距离，是未来三年基础设施领域最重要的问题。

提交曲线是机器化开发的首个公开轨迹

GitHub 的遥测数据是你所在组织的一个代理指标：它汇总了数千个工程团队同时在做的事情。除了提交数量，复盘报告还提到每月约 1.3 亿个合并的 Pull Request 和 2400 万个新仓库。Engadget 的报道指出，GitHub 将激增归因于 AI 生成的代码。

曲线的形状比高度更重要。提交量多年来的增长速率与开发者人口增长率大致相同，因为提交是跟随人的。然后它在四个月内翻了一倍，因为它不再跟随人了。一个开发者同时运行三个编码 Agent 会话，产生的提交速率是任何招聘计划都未曾预测到的。

"一个开发者同时运行三个编码 Agent 会话，产生的提交速率是任何招聘计划都未曾预测到的。"

你的内部仪表盘几乎肯定以缩小版的形式呈现同样的形状：季度环比上升的 Pull Request 数量、人均提交更多、同时开放的分支更多。公开数字之所以重要，是因为它证明你的曲线不是本地异常。这就是当生成不再是稀缺步骤时，开发呈现的样子。

GitHub 的瓶颈是容量。你的瓶颈是置信度

GitHub 的问题，尽管很严重，有一个已知的解法：当流量超过基础设施时，增加基础设施。核心、磁盘和数据中心可以用钱扩展，而微软有的是钱。

平台你这一侧的问题不能以同样的方式用钱解决。一次提交不是流量。它是关于行为的一个断言：这次变更做了它描述的事情，且没有破坏下游的任何东西。在分布式、云原生的系统中，验证这个断言意味着将变更放到它合并后将遇到的服务、数据和流量中实际运行。

检查前面的流水线一直在变快。AI 代码审查工具在人类审查之前对 Diff 进行分类，能在 Diff 中发现真正的缺陷并且还在不断改进。但它们也有局限：审查者，无论是人还是模型，都在推理他们没有运行过的代码，而 Diff 无法告诉你这个变更在其真实依赖项面前能否站住脚。

第二种做法是限制 Agent，限制进入流水线的生成工作数量。这通过牺牲 Agent 原本要交付的大部分吞吐量来保护验证队列。

第三种做法是照常合并，吸收下游的失败。那些从未在真实系统上运行过的变更，以提交到达的速率进入 main 分支，成本在之后作为破碎的预发环境和冗长的调试会话浮现。或者更糟——生产事故和回滚。

8 月 17 日的宕机预示着这最终会怎样结束。根本原因不是一个糟糕的变更。是一个每个人都依赖、但没人去扩展的组件，在某一天流量终于超过其设计容量时发生了故障。在大多数交付系统中，验证就是那个组件。

验证必须和生成运行在同一曲线上

结构性的修复是让验证匹配生成的形态：并行的、逐变更的。对于单个应用，这个问题几乎已解决：一个 Agent 在笔记本电脑或 CI 容器中运行应用，检查变更是否正常工作。困难的情况是云原生的那个——变更的行为只有在与其他服务、数据库和队列交互时才存在。两种常见的选项在 Agent 体量下都失败了：共享的预发环境把一切序列化成一个队列，而为每个变更复制完整栈成本太高、太耗时。

有第三种形态。保持一个共享环境运行每个服务的稳定版本，对每个变更只部署变更触及的服务。测试流量携带变更的路由键，所以在每一跳，针对那个变更的请求会到达变更后的版本，而其他所有请求都通过稳定版本流动。每个变更在重要的地方——它修改的服务——获得隔离，其他一切共享：同一个集群、同一份数据、同样的下游依赖。

这种形态改变了经济学和执行者。验证多一个变更的成本是一次额外的部署，而不是另一份栈的复制，所以在已有集群上可以并行检查数百个变更。

因为环境在几秒内就出现，一个 Agent 可以在它的循环中使用一个：打开一个变更，针对真实的上游和下游服务运行功能检查，读取失败结果，然后迭代直到通过。到达人类的 Pull Request 已经针对真实系统运行过了，审查时间用于检查意图和设计。

匹配曲线，否则失去生成带来的收益

GitHub 的 29 亿次提交量化了每个工程组织都在以更小规模经历的转变。生成现在实际上已经是免费且无限的，所以它不再是优势来源。

"领先一筹的团队不是产生最多提交的团队，而是验证容量能随生成容量一起增长的团队。"

领先一筹的团队不是产生最多提交的团队，而是验证容量能随生成容量一起增长的团队——这样更多生成的代码变成了更多已发布的代码，而不是更长的审查队列、更深的预发积压和更大的故障账单。问问你自己：当提交量在四个月内翻倍时，你的流水线会怎样——因为这不是假设了。这是我们在 Signadot 致力于缩小差距的问题，在曲线再次翻倍之前，它值得被解决。