当智能体把代码写得更快，Linear 用半年重做 CI
智能体让写代码变快了，但验证没跟上。每个 PR 仍然要过一次 CI，于是开发提速的代价全落在流水线上：基础设施账单上升，人和智能体一起等反馈。Linear 把两个指标写进目标——PR 在 CI 上的等待时间，以及每个测试消耗的 runner 时间。结果是测试套件规模涨到年初的近四倍，等待时间还是从 6 分多钟降到 5 分钟出头，单个测试的机器时间减半。
做法没有什么魔法，都是“把冗余找出来”。第一步是换基础设施：从 GitHub Actions 迁到第三方 runner，同类任务平均快 34%，类型检查这类任务快 52%；换成原生 TypeScript 编译器 tsgo 之后，tsc 检查的周中位耗时降了 73%，瓶颈直接换人。第二步是拆依赖：一批 lint 规则原本依赖类型信息，每次都要先构建完整类型图，改写成基于语法树的静态分析后，仓库级 lint 时间少了 55%，内存大幅下降，之后迁移到 Oxlint 也顺理成章。
第三步是把关键路径上的东西挪走。七个各自拉起一个 runner 的短检查合并成两个任务，内部并发执行，按 6 月用量算每月省下约 8.7 万 runner-分钟，相当于全部 CI 用量的 11.8%。数据库迁移原本每次重放，改成加载 schema 快照，每个容器从约 12 秒降到 1 到 2 秒；合并前顺手写的缓存标记根本不 gate 任何东西，挪出关键路径又省下 42 秒。
也有反直觉的结论：缓存 node_modules 反而更慢——缓存命中要还原约 28 秒，而按包过滤的安装只要 7.5 秒，于是他们干脆取消了这个缓存。真正能省钱的地方往往不是跑得更快的机器，而是少跑一遍已经做过的事。
评论区里两种声音都成立：有人说瓶颈根本不在 CI，而在“人来判断这是不是用户想要的东西”；也有人主张智能体时代系统应该更小、更隔离，模块之间只靠契约通信。不管站哪边，结论是同一个——智能体的产出速度会把基础设施里每一处冗余都放大成账单，CI 只是第一个被打出来的。