AI 编码让 CI 成瓶颈，Linear 如何破局
AI coding has made CI a bottleneck, so we reworked ours to keep up
今年早些时候，我们的 CTO Tuomas 给我分配了一个任务：解决 CI 成本过高且速度滞后的问题。随着 AI 代理让代码交付速度呈指数级增长，验证这些变更的 CI 流程却成了新的瓶颈，导致等待时间变长、基础设施成本飙升。在 Linear，我们致力于优化 PR 在 CI 中的等待时间和 Runner 资源消耗。尽管测试套件规模几乎翻了两番，我们成功将 PR 等待时间从超过 6 分钟缩短至 5 分钟出头，同时将单次测试的 Runner 时间减半。通过升级基础设施、优化关键路径任务、减少重复设置以及提升测试执行效率，我们不仅降低了成本，还显著提升了开发体验。
AI 代理让代码交付速度呈指数级增长，但验证这些变更的流程却未能以同样的速度跟上。
HN 评论区
381- torben-friis
我有一个常问的问题：
大家跑得飞快，却不断撞墙。代码审查、CI、产品提需求，诸如此类。
为什么我们没看到产品有什么实质改进？
虽然每篇帖子和讨论都让人感觉像是 90 年代的华尔街办公室，但新出的 Android 和 iPhone 搭载的功能反而比往常少了。没有独立开发者搞出一个 Linux 级别的替代操作系统。Switch 2 依然没被破解。Windows 右键菜单要等 3 秒才出来。
难道大家只是在原地全速空转吗？
- aliclark
在我的情况里，瓶颈根本不是 CI，而是人工测试环节。功能能不能跑通，当然没问题。但它真的做到了我们想要的效果吗？更重要的是，它是以客户能理解、真正喜欢的方式做到的吗？
- dgroshev
我怀疑这其中很大一部分是测试泛滥造成的雪崩。
如果你还在看 PR，上一次你没直接跳过测试是什么时候？如果你看过那些重度依赖 LLM 的 PR 里的测试，有多少是测试了真正有用的东西，而不是仅仅测试内置功能或琐碎行为？
业界至少已经意识到 LLM 会在业务逻辑中生成大量样板代码。但感觉我们对测试中充斥了多少这类东西，意识还远远不够。
- classictraffic
> 将工作负载从 GitHub Actions 迁移到第三方 Runner，利用更快的 CPU、更高性能的存储和更好的缓存基础设施，让我们能在更强大的机器上运行同样的流水线
看到这段话一点也不意外。Actions 如果你已经用 GitHub 确实很方便，但也可能相当慢。考虑到 GitHub 最近可靠性也是个大问题，我预计会有更多组织转向其他流水线方案。
- algesten
Linear 早就完工了，也不需要更多功能，所以 AI 编码可以慢点来。哎呀糟糕，它正忙著变成下一个 Jira 呢 :(
- frangonf
我最大的收获（作为一个连 Gitlab 免费计划和自托管 Runner 都在优化、预算只有人家二十分之一的单兵开发者）是：他们直到 ARR 达到 1 亿、估值超过 10 亿 [0] 之前，压根没操心过这些事儿。
[0] https://linear.app/now/sharing-growth-with-the-people-buildi...
- fb03
随着提交速度、节奏以及仓库内容量的普遍大幅提升，我在想，对于那些 CI/CD 需求巨大的公司来说，是不是有个角度可以直接在本地自建 CI/CD 机器？
根据我的经验，自托管 CI/CD Runner 在成本节约方面影响最大，同时也允许使用更强大的机器，这意味着 CI/CD 运行速度直接提升。
- azkalam
如果你能承担搭建成本，Bazel 能让即使是巨型项目的构建时间（在缓存预热后）缩短到约 10 秒。