Linear CI 瓶頸深度解讀：AI 寫程式變快，驗證為何跟不上？（2026）

2026 年 9 月 21 日，Linear 工程師 Mufeez Amjad 在官方 Now 專欄發布了〈AI coding has made CI a bottleneck, so we reworked ours to keep up〉。這篇文章把一個很具體的 Linear CI 瓶頸攤在桌上：當 Coding Agent 讓程式與測試快速增加，原本藏在背景的驗證時間、Runner 成本與等待佇列，開始變成整條開發流程的新限制。

接下來我會先忠實整理 Linear 做了什麼，再把內部數字和外部證據分開，最後回答兩個問題：這是否真的證明 AI 提升了軟體生產力？你的團隊又該先優化 CI，還是先檢查 Agent 產生的測試是否有價值？

Linear CI 瓶頸的核心：產生速度超過驗證速度

Agents have made it exponentially faster to ship code, but validating those changes hasn’t quite kept up at the same rate.

中文：Agent 讓程式交付快得多，但驗證這些變更的速度沒有同步跟上。

Mufeez Amjad，Linear

原文的論點不是「CI 突然壞了」，而是上游產能變大後，固定成本與等待時間被放大。Linear 表示，2026 年初到 9 月之間，測試套件規模接近原來的 4 倍；同一期間，每項測試消耗的機器時間約減少 46%，PR 等待時間也從超過 6 分鐘降到略高於 5 分鐘。即使如此，公司仍以每週約 2,000 項測試的速度增加。

這張圖很有說服力，但要讀對指標。它證明的是 Linear 自己的測試量與單位機器成本出現分岔；外推到其他公司需要額外樣本。圖中指標止於測試量與單位機器成本，新增測試抓到多少真實缺陷，仍要由另一組品質指標回答。測試數量是工作量；測試品質則要看覆蓋到哪些變更、能否殺死錯誤變異、是否降低逃逸到正式環境的缺陷。

Linear 做對了什麼：先拆固定成本，再談更多平行化

Linear 把改造分成四層：更快的 Runner 與工具鏈、縮短關鍵路徑、減少重複初始化，以及提高測試執行效率。這個順序比「直接加更多機器」重要，因為每開一個 Shard，都會再付一次啟動 Runner、Checkout、安裝依賴與準備資料庫的固定成本。

1. 工具變快，但內部百分比仍是 Linear 自報

Linear 表示，搬到更快的第三方 Runner 後，相鄰兩日的同類工作平均快了 34%；把 TypeScript 檢查切到原生編譯器 tsgo 後，週中位數再降 73%。外部能確認的是機制：Microsoft 的 TypeScript 7.0 Beta 說明確實把 tsgo 描述為 Go 原生移植，並在多個大型專案呈現約 7.5～10.2 倍的官方測試加速；但 Linear 的 73% 仍是它自己的工作負載結果，不是第三方重現。

2. 關鍵路徑只留下真正會擋住合併的工作

原本用來判斷「哪些路徑改了」的小工作，會完整 Checkout 整棵程式樹。Linear 改成限制歷史深度、Sparse Checkout 與 Blobless Checkout，並把不會影響合併結果的快取寫入移出關鍵路徑。這類優化的價值很直接：它不改變驗證內容，只拿掉每次 PR 都重複支付的等待。

Git 官方把 Partial Clone 定義為避免預先下載不需要物件的效能功能，因此這條路徑在技術上合理；至於 Linear 將變更偵測工作的中位時間從 26 秒降到 8 秒，仍應視為單一公司的內部觀測。

3. 批次化短工作，消掉重複啟動費

七個短檢查原本各自啟動 Runner、Checkout、安裝依賴，實際工作卻只有幾秒。Linear 把它們併成兩個 Job，再在 Job 內平行執行。公司依 6 月使用量估算，這一項每月省下約 87,000 Runner-minutes，相當於總 CI 用量的 11.8%。這是全文最醒目的成本數字，也最需要保留「Linear 估算」這個主詞。

4. 共用 Module State 很快，也最容易換來隱性錯誤

Linear 最大的單項改善，是讓一部分安全的測試檔在同一 Worker 中共用 Module Registry，不必每個檔案都重建 Entity、GraphQL 與 Decorator Graph。它把這條路徑做成逐檔 Opt-in，對 Fake Timer 或共享狀態難以清理的測試保留隔離。

Vitest 官方文件確認 Sharding 切分的是測試檔案，不是單一 Test Case；isolate: false 文件也明確指出，關閉隔離可能加速，但前提是程式不依賴副作用。Linear 沒把這個開關全域打開，而是把適用條件寫進 Agent Skill，這比單純追求更低 Runner-minutes 更值得學。

外部證據支持「驗證稅」，但不替 Linear 的數字背書

Linear 的敘事並非孤例。Google Cloud DORA 在 2026 年 3 月整理 1,110 份 Google 工程師開放式回覆時指出，AI 省下的撰寫時間常被重新花在稽核與驗證；其 2025 年研究也把更高 AI 採用率與更高交付吞吐、同時更高交付不穩定性連在一起。這支持「瓶頸會移動」的方向，但它是不同樣本的關聯與質化研究，不能拿來驗證 Linear 的 4 倍測試或 87,000 分鐘。

另一份 2026 年 7 月的Agentic PR 測試覆蓋研究分析 4,882 個由五種 Coding Agent 產生的 Java／Python PR，發現修改受測程式碼的 PR 中，只有 49.6% 同時包含測試變更；Agent 撰寫的測試也只有少數 PR 帶來覆蓋增益。這組資料不代表 Linear，卻提醒我們：Agent 能大量寫測試，和它能寫出有效測試，是兩個不同命題。

更早的 METR 隨機對照研究則讓結論更保守：16 位熟悉大型開源專案的開發者完成 246 個真實任務時，使用 2025 年初的 AI 工具平均反而慢 19%。模型世代、任務與團隊都不同，因此不能用它反駁 Linear；它真正推翻的是「AI 寫程式一定讓所有情境更快」這種無條件外推。

AlphaLab 的判讀：真正稀缺的不是程式碼，而是可信的回饋

我同意什麼

我同意 Linear 抓到了一個重要轉折：當產生程式與測試的邊際成本下降，工程系統會把限制推向 Review、CI、測試資料、環境啟動與人類判斷。此時最有效的改善，通常不是把所有步驟都平行化，而是先把固定成本、錯誤快取、無意義序列依賴與關鍵路徑外的工作拆掉。

我存疑什麼

我不會把這篇文章讀成「AI 已讓軟體生產力呈指數成長」。原文提供的是索引曲線與 Linear 內部的前後比較；要把它升級成生產力因果判斷，還需要絕對測試數、PR 數、變更大小、缺陷逃逸率、Flaky Rate、Mutation Score，以及「不使用 Agent」的反事實基線。現有數字足以支持 CI 工程改善，卻不足以證明新增產出等比例轉化為使用者價值。

這正是 Linear CI 瓶頸最值得保留的張力：如果 Agent 先大量生成程式，再大量生成測試來證明自己的程式，團隊可能只是把便宜的文字轉成昂貴的運算與審查。只有當驗證能攔下真實錯誤，而且沒有把回饋時間拖到人與 Agent 都開始切換工作，整條鏈才算變快。

你的團隊現在可以怎麼做

1. 先量端到端回饋，不只量 Test Count。至少同時記錄 PR 的 Queue Time、p50／p95 Run Time、Runner-minutes、重跑率、Flaky Rate、Changed-line Coverage 與正式環境逃逸缺陷。
2. 先砍固定成本，再增加 Shard。檢查 Checkout、依賴安裝、容器啟動、資料庫初始化與短 Job 是否重複；固定成本沒降，更多 Shard 只會更快燒掉更多機器時間。
3. 把 Agent 產生的測試當成候選證據。用 Changed-line Coverage、Mutation Test 或 Hidden Oracle 驗證它真的能抓錯；可接著參考 AlphaLab 的Coding Agent 測試驗證實戰。
4. 把效能例外寫成可驗收規則。像 Linear 對 isolate: false 採逐檔 Opt-in，並把限制寫回 Agent Skill；若 Agent 常交出大型 PR，可用CI Budget 稽核把變更大小與驗證成本一起設門檻。
5. 每次事故都回灌測試與 Gate。不要只修紅燈；把原因、偵測方式與回復條件留下來，做法可延伸到Agent CAPA 與 CI 閘門。

Linear 的案例不是所有團隊都已進入「AI 讓 CI 爆量」的證明，而是一張很清楚的路標：當寫程式變便宜，可信、快速、可重跑的驗證就會變貴。下一輪真正拉開差距的，不是誰能生成最多程式碼，而是誰能用最短的回饋迴路，判斷哪些程式值得留下。