AI 產出變快後，真正卡住的是交付節奏
AI coding 讓寫程式變快，卻也提醒我一件做 Growth 很熟悉的事：當上游轉換率突然變好，瓶頸通常會搬到下一站！📈
Linear 最近重新整理 CI，起點不是單純追求更快的測試，而是發現 AI 讓 PR 的數量和變更規模一起放大，原本撐得住的整條交付流程開始排隊。這是典型的 downstream constraint：產出增加了，驗證、排程、部署和人工審查卻沒有同步擴容，最後大家感受到的不是生產力提升，而是等待變長。
從營運角度看，CI 不只是工程團隊的基礎設施，也是產品交付漏斗的一段。漏斗前端可以用 AI 產生更多變更，若中段驗證速度跟不上，整體 throughput 反而被最慢的環節決定。這跟投放很像：廣告點擊暴增，但客服回覆和 onboarding 沒準備好，轉換率未必上升，甚至會因體驗變差而下跌。
小團隊不需要先複製大型公司的基礎設施，可以先做三件事：
量測等待，不只量測執行。把 PR 從開啟到首次 CI 回饋、從通過到合併的時間拆開記錄，再看 P50 和 P90。平均值很容易掩蓋少數 PR 被卡很久的問題。
找出真正的限制。每週抽樣失敗原因，分成測試不穩、資源排隊、環境問題和程式本身。若只追求縮短單次執行時間，可能花很多成本優化一個並非主要瓶頸的環節。
設定治理護欄。AI 產生的 PR 可以要求更小的變更範圍、明確的測試清單和風險標籤，高風險修改保留人工審查。速度指標要和回滾率、缺陷率一起看，否則團隊很容易用品質換來漂亮的交付數字。🎯
我會把這類改善定義成「單位交付成本下降，同時等待和事故不惡化」，而不是追求一個看起來厲害的 CI 秒數。先找到排隊最嚴重的地方，再決定要平行化、調整優先級，或減少不必要的驗證。
AI 放大的不只是產出，也放大系統的弱點。真正的 growth hack，是讓整條交付鏈一起變快，而不是只讓某一個人的游標變快！
作者：Stella