OpenAI 的 Git 扩展规模

代码和提交量激增的感知

• 许多人对庞大的提交量/LOC 规模感到震惊，并质疑这如何能成为资产而不是负担。
• 另一些人指出，相对于公司规模而言，这一体量可能只是“温和”，而且传统的 LOC 指标正变得不如仓库规模和变更率模式那样有意义。

AI 生成的“slop”与生产力

• 多位评论者将 AI 代理输出描述为大量的“slop”：过度设计的抽象、重复逻辑、冗长的注释，以及无穷无尽的“修复”提交。
• 他们表示，小任务会膨胀成巨大的 token 和提交数量，而代理会反复修补自己造成的错误。
• 支持者认为，只要算力足够便宜，这样是可以接受的：代码和测试可以被反复重新生成或重构，直到满足基准。

人工监督、信任与责任

• 一方认为 LLM 可以可靠地编写和审查大多数代码，人类只需处理分布外或高风险场景。
• 批评者强调激励机制（写出糟糕代码的人会被解雇，模型不会）、监管和客户数据责任，以及需要有人真正理解数据是如何被处理的。
• 有人担心管理者最终必须回答“我不知道，是模型干的”，以及人类可调试性的丧失。

这些代码到底在做什么？

• 猜测包括：RL 环境、训练/推理基础设施、内部应用、大规模实验，以及为训练而捕捉每一次代理编辑。
• 还有人怀疑存在重复、短暂脚本，以及“缓存”生成代码，而这些代码其实可以按需重新生成。
• 也有人担心，考虑到可见的产品变化相对有限，有时客户端应用还很笨拙，这些收益对用户来说并不清晰。

Git、monorepo 与替代 VCS 模型

• 几位评论者指出，Git 在大型 monorepo 规模下本来就已经吃力（Meta、Google）；OpenAI 正在通过代理驱动的工作流触及类似甚至更严重的极限。
• 争论焦点在于，这本质上是 monorepo 问题、Git 问题，还是一种新的“代理规模”用例（高提交率、类似快照/日志的使用方式）。
• 有人认为，大厂应当采用完全新的、中心化的 VCS 拓扑，而不是继续勉强扩展 Git；也有人认为 Git 会演变得更像协议层。

更广泛的影响

• 有些人认为，这是 LLM 能够快速构建复杂系统的令人印象深刻的证明。
• 另一些人则把它视为警告：代码库膨胀、攻击面扩大，以及一种优化吞吐量而非清晰性和可维护性的开发文化。