重新设计 Anthropic 的源代码管理
Anthropic 已经构建了“Scion”——一个定制的中心化源代码管理系统，用来替代 git，以支持其快速增长的 monorepo 和编程 agents 队伍；这些 agents 现在每天会产生数万次 merges 和数千万次代码 checkout。评论者将该设计与 Perforce 或 Subversion 相比较，并讨论真正的问题究竟是 git 的可扩展性、Anthropic 的 monorepo 与工作流选择，还是 AI 生成变更的巨大 churn。该讨论串还提出了关于 agent 驱动开发的更广泛问题：如何审查意图而不是每一行代码、这种速度是否可持续或明智，以及为什么 Anthropic 没有开源那些训练于大量外部代码之上的工具。
Anthropic 为什么构建 Scion
- Git 在 Anthropic 的规模下开始失效：主分支历史约 100 GB、工作副本约 25 GB、每天用于 CI 和 agents 的 checkout 约 2500 万次。
- 如果每个任务都天真地重新克隆，就意味着每天约 600 PB 的流量；即便使用缓存和 repack，大家也提到 git 仓库维护正在变得脆弱。
- Monorepo 是有意为之：它支持原子性的跨领域变更、一致的工具链，以及让 agents 轻松访问，但也放大了扩展性问题。
设计与对比
- Scion 是中心化且始终在线的：所有 commits/merges/rebases 都在服务器上完成；客户端只按需获取所需的 blobs。
- 历史和文件内容是不可变的、基于内容寻址的对象，存储在日志 + 对象存储中，派生数据则异步计算。
- 很多评论者说这“听起来像” Subversion、Perforce、ClearCase，或者 Google 的 Piper / Meta 的 Sapling，也就是中心服务器 + 虚拟化工作树。
- 也有人指出 EdenFS、基于 artifact 的文件系统，以及基于 jj 的工具链里也有类似想法；还有人认为，对于超大规模 monorepo，这几乎是不可避免的模式。
规模、agents 与工作流变化
- merges 从每天约 2500 次增长到超过 3 万次，主要由 agents 推动。有人把这看作“用代码做梯度下降”或暴力探索。
- CI/merge-queue 语义发生变化：你不能全局锁住仓库，因此更多事情在 merge 后、部署前完成；并发的语义冲突是预期内的，由 agents 修复。
- 人类工程师的角色被描述为：选择问题、做架构权衡、经常对 agents 说“不”，然后审查意图，而不是逐行审查每一行代码。
质量、安全与可维护性担忧
- 很多人对每天 3 万次 merges 和高 churn 感到不安：担心 spaghetti code、jank，以及“AI slop”积累得比理解它的速度更快。
- 还有几位指出，即使是今天，他们也必须仔细审查 AI 生成的代码，以避免微妙 bug；他们怀疑 Anthropic 是否真的能在这种速度下监督一切。
- 中心化、仅在线可用的 VCS 会带来对宕机、安全性和失去离线工作流的担忧；也有人回应说，大型组织本来就已经生活在始终在线、由 API 驱动的环境中。
开源、通用性与更广泛的影响
- Anthropic 说 Scion 太定制化、与 git 的差异太大，无法有用地开源；许多读者对一篇详细博客文章却没有代码感到失望。
- 有人认为，大多数组织应继续使用 git，或者购买类似 Perforce 的系统；只有拥有庞大 agent 队伍和 token 预算的前沿实验室才需要 Scion 风格的工具。
- 更广泛的争论是：LLM 让重建基础设施（VCS、CI、deploy、dashboards）的成本变低了，但这些重建里究竟有多少能带来持久价值，还是只会带来 churn 和技术债，仍不清楚。