AI 编码让 CI 成了瓶颈，所以我们重做了自己的系统来跟上

原文 ↗ Hacker News 讨论 ↗

AI 驱动的编码正在大幅增加代码变更的数量和速度，使持续集成（CI）流水线成为新的瓶颈。开发者正在尝试更快的构建系统（如 Bazel）、自托管或第三方 runner、激进缓存，甚至把更多检查转移到本地或代理循环中，以在测试套件不断膨胀时保持可接受的反馈时间。许多评论者也在质疑这些额外测试到底有多大产品质量提升，认为即使代码和 CI 吞吐量在加速，人工 QA、产品决策和用户价值仍然是真正的约束。

CI 作为新的瓶颈

  • 许多人反映，一旦 AI 代理大幅增加代码/PR 的数量，CI 流水线就会成为限制因素。
  • 较长的构建时间（10 分钟以上）会拖慢人和代理；人们希望把循环时间压到 2–5 分钟以内，有时甚至低于 60 秒。
  • 也有人认为，真正的瓶颈现在是 QA、产品验证和客户侧（采用、更新疲劳），而不只是 CI。

Bazel、缓存与构建系统

  • Bazel 因为在大型多语言代码库上配合热缓存能实现约 10 秒级的增量构建而受到称赞；AI 代理让 Bazel 迁移比过去快得多。
  • 也有人指出其权衡：设置复杂、每个任务都有沙箱开销、工程体验要求并行保留“普通”工具，对 JS/TS 的效果也喜忧参半。
  • 远程缓存可能受网络和磁盘 I/O 限制；优化措施包括只获取摘要（digest）、对大型制品使用内容定义分块，以及以无 Dockerfile 的方式按不可变原则构建容器镜像。
  • 有人主张采用类似 Bazel 但更简单的系统（例如 RWX、自定义工具），以及把构建 + 测试视为同一图的统一调度器。

CI 基础设施选择

  • 托管的 GitHub Actions 被认为在大规模下又慢又不稳定且昂贵；许多人转向：
    • 第三方 runner，具备更快的 CPU/NVMe 和更好的缓存。
    • 自托管 runner（本地部署或廉价云主机），带热工作区、LXD 容器和激进并行化。
  • 直接与 GitHub 的对等互联/网络连接仍可能不稳定；本地缓存能缓解问题，但无法完全解决。

代理式编码、测试与 QA

  • 代理会生成大量测试；一些流水线报告测试套件规模大约扩大了四倍。
  • 几位评论者认为大量 AI 编写的单元测试是琐碎或重复的“slop”；端到端测试和特征测试被认为更有价值。
  • 一些团队现在比代码更重视测试审查，相信只要相关测试通过，大规模重构大概率是安全的。
  • 也有人质疑，4 倍更多的测试是否能带来 4 倍更多的价值，还是只是更高的 CI 成本。

重新思考 SDLC 与架构

  • 建议包括：
    • 将大多数 lint/单元检查移入代理循环，只把重型/不可复制的检查留给 CI。
    • 允许更多 CI 工作在开发者机器上完成，并配合签名制品，尽管有人指出了供应链风险。
    • 设计更小、面向契约的服务或模块化单体，让代理能在受限上下文中更快迭代。

AI 带来的生产力提升会改善产品吗？

  • 有些人报告了明显收益：大型重构和迁移从几个月缩短到几天，性能提升、基础设施清理、可访问性改进，以及更有野心的个人/独立项目。
  • 也有人主要看到更多代码、更多琐碎应用、更有 bug 的软件，以及旗舰产品或宏观生产力几乎没有可见提升，并将大量 AI 加速编码概括为“更多代码，不是更多价值”。