AI 时代，CI 才是真瓶颈

🚨 有没有发现一件怪事：AI 让写代码变快了，但代码进主干反而更慢了？
Gautam Korlam（Uber 十年构建与合并基础设施、SubmitQueue 作者，现 Sonar）在 AI Engineer 的分享里把这件事讲透了 👇
🔍 瓶颈早就转移了
Agent 生成变更的速度，已经超过了测试、评审、合并它们的队列。这些队列是为「人类速度」设计的——人一小时提几次，所以能一个一个测。现在 agent 一天提几十个 PR，还都想同时进来，CI 和 review 直接过载。
📊 数据很吓人
Gitar 三年内提交率涨了约 10 倍，PR 量每月环比涨约 25%。他们平台上 13% 的 PR 有过 CI 失败记录，每一次都是一趟完整往返：读日志、定位、修复、再推一版。
⏳ Uber 的老故事
单体仓库、每天上千次变更。全串行合并要 20 天才能全绿，全放开主干天天红。于是他们做了 SubmitQueue：并行测试提交的组合，提前预测哪些会互相打破，把会破的踢回给作者。这套系统今天还在跑。
⚡ 怎么救
1️⃣ 让 CI 真的快：缓存、分片、并行、增量构建。他们用 Rust 把 CI 从 10 分钟压到增量步骤不到 1 分钟
2️⃣ 检查左移，越早发现越便宜
3️⃣ 快速多轮 review 先给信号，高风险才深挖
4️⃣ 风险分级审批：依赖升级、文档、内部工具可自动批准，支付这类敏感变更必须人工；但作者绝不能批准自己的变更
🧾 最容易被忽略的一点：审计
CI 数据会过期，force push 之后分支指向的已经不是被测的那份代码。所以要留下记录：哪个 agent 提的 PR、谁启动的、每个 CI 跑在哪个 commit、每条 finding 怎么被解决的、override 的理由是什么。
一句总结：别把「生成更多代码」当成「交付更多价值」，真正该量的是从变更提出到被接受的全路径 🎯
📎 【AI Engineer】Rebuilding CI for AI-Scale Commit Volume — Gautam Korlam, SonarSource
#AI编程 #CI #DevOps #软件工程 #AIAgent #代码评审 #研发效能 #程序员 #技术分享 #GitHub