Linear 表示，AI 辅助编程使其拉取请求的验证速度落后于代码产出。根据该公司的说法，其测试套件规模几乎增至原来的四倍，而拉取请求的平均等待时间从六分钟以上降至略高于五分钟，每次测试的运行器耗时则减少了约一半。这些是 Linear 自行报告的数据，并非独立基准测试结果。
该公司得出的主要经验是，持续集成速度是一个系统性问题。更快的运行器确实有所帮助：Linear 表示，在将工作负载迁移到配备更快 CPU、存储和缓存的基础设施后，任务平均运行速度提高了 34%。但公司还缩短了检出步骤，从合并路径中移除不必要的工作，预装共享依赖，并只安装每项任务所需的软件包。每个分片的准备时间因此下降约 44%，从 110–140 秒缩短至 67–73 秒。
在讨论更快的运行器、更短的环境准备和减少关键路径工作之后，逐步计时数据让流水线的提速效果变得具体可感。
最大的提速来自改变测试的运行方式，而不仅仅是改变其运行位置。Linear 拆分了大型测试文件，将 API 测试分片从四个增加到八个，并为能够安全使用的文件引入了可选择加入的共享 Vitest 模块注册表。该公司表示，最慢的分片从大约 300–379 秒降至约 195 秒，而每次运行中 API 分片的运行器耗时从约 32.8 分钟降至 22 分钟。
这张图支持文章的解释：重新组织工作和依赖关系，而不只是更换硬件，也促成了更快的验证。
调整前后的结构说明，共享一个状态如何减少重复构建；文章同时指出，不安全的文件仍需满足隔离要求。
这种优化会带来正确性方面的代价。共享模块状态可能暴露伪造计时器或其他状态交互问题，因此 Linear 将不安全的文件保持隔离，增加了清理步骤，并更新了针对生成式测试的指引。实际的启示比“购买更快的运行器”更具体：当 AI 增加变更数量时，持续集成的提速往往来自减少重复的环境准备、缩短关键路径任务，以及只在隔离规则仍然安全的情况下进行并行化。