AI 把交付速度推到極限後，最先崩的是 Sprint
MotorK 的案例讓我重新思考：當 AI 把產出速度推上新水位，真正的瓶頸會從寫程式轉移到問題定義、驗收標準與團隊脈絡。
最近在 Threads 看到一段分享，很像一顆石頭丟進我腦袋裡：MotorK 的 CPO/CMO Johnny Quach 描述他們團隊「全面導入 AI」後，開發節奏被徹底改寫。內容裡有幾個數字很刺眼——衝刺流程被廢掉、70 人工程團隊縮編、行銷團隊從 20 人精簡到 2.5 人、PM 用 4 天做完原本估 4 個月的前端重構。
我先把話講在前面：這些敘述大多是當事人的經驗分享，外界很難逐條驗證。把它當成「可複製的成功配方」會很危險。但它依然值得寫成文章，原因是它把一個正在發生的趨勢講得很直白：AI 讓產出速度暴增之後，最先被淘汰的常常不是某個工具，而是整套管理節奏。
原文 Threads 連結我放在這裡（建議先看一次，感受那個語氣與節奏）：
1) 當交付速度變成「每天都在改版」，Sprint 會先壞掉
分享裡最有代表性的一句話，是他們「廢除衝刺流程（Sprints）」，改成「開發、交付、重複」的極簡循環。
我自己做過幾次把 AI 放進開發流程的試驗，最常見的現象是：當你把「寫程式」這段的摩擦降到很低，Sprint 的價值會被迫重新定義。Sprint 原本扮演的是「把不確定性切成兩週一包、讓團隊可以同步節奏」。但當交付速度變快、需求變動也跟著變快，Sprint 反而容易變成：
- 為了儀式而儀式的排程
- 為了追 burndown 而做出錯誤切割
- 為了下個 Sprint 才能做事而延遲修正
AI 把「做出一個可跑的版本」變得太便宜，大家就會開始問：我們到底在管理什麼？
2) 人變少、產出變大：真正的瓶頸轉移到「決策與定義問題」
原貼文描述：過去要 5 名工程師、QA、設計師、PM、技術主管協作的專案，現在 3 個人就能完成；甚至提到工程團隊縮編、行銷團隊大幅精簡，但產出品質提升。
這裡我不想把焦點放在「裁員」上。更值得放大的是瓶頸位置的移動：
- 以前卡在實作能力（人手不夠、技術債、QA 來不及）
- 現在更常卡在問題定義（要做什麼、為什麼做、怎麼驗收）
你會發現，AI 讓「手」的速度變快，但「腦」的速度沒有跟上。組織如果不補上決策機制、驗收標準與優先級排序，速度只會讓混亂擴散得更快。
3) PM / 設計師走到第一線：重點是「設計系統 + 可交付介面」
分享裡提到他們建立設計系統，並連結到 AI 代碼編輯器 Cursor，讓非工程職位也能直接交付功能；甚至有 PM 用 4 天完成前端重構。
我看到這段的第一個反應是：這不是「PM 變工程師」，而是「交付介面變了」。
當你的 UI 元件、設計規範、資料結構、路由邏輯被收斂成一套可重複引用的語彙，AI 才能把「把需求翻成程式」的成本降到足夠低。沒有設計系統，非工程角色多半會卡在：輸出很像需求、但缺乏可落地的約束。
所以這個轉變的本質是：
- 把設計與規格的資訊密度提高
- 把「可以交付」的範圍明確化
- 讓 AI 有穩定的上下文可以依循
4) Blueprints 的價值：讓 AI 生成的內容可被接力、可被審核
原貼文提到他們發展一套名為 Blueprints 的標準化流程，教大家怎麼跟 Cursor 互動，並提升技術文件品質。
這點我非常有共鳴。
你只要真的讓團隊依賴 AI 產出，就會立刻遇到「上下文斷裂」：
- 這段程式為什麼這樣寫？
- 這個選擇犧牲了什麼？
- 邊界條件在哪？
Blueprints 這種東西，實際上是在做兩件事：
- 把提問方式固定下來（避免每個人都在用自己的 prompt 方言）
- 把產出的脈絡固定下來（讓下一個人能接得住）
這會讓 AI 從「個人效率外掛」變成「團隊級的生產力系統」。
5) Ralph Wiggum：把 Bug 修復當成 24 小時的自動迭代
分享裡的案例很戲劇化：他們讓 AI 獨立處理 53 個附驗收標準的 Bug，24 小時迭代比對需求，2 天修好 20 個；而過去團隊平均一天只能處理 1 個。
我不會拿這個數字去對標任何團隊，但我會拿它提醒一件事：如果你想讓 AI 接近「自動除錯」的工作模式，最先要投資的不是模型，而是驗收標準。
Bug 如果只有一句「這裡怪怪的」，AI 很難穩定收斂；Bug 如果有明確的可驗證條件（輸入、輸出、限制、反例），AI 才有機會像一個不會累的工程師一樣做迭代。
6) 季度計畫的終結：規劃不會消失，但粒度會被迫變小
原貼文說當效率提升到 10 倍，季度計畫變得沒有意義，目標變成「數週內清空 backlog」與「零 Bug」。
我對「零 Bug」這種敘事保持保留，但我同意另一半：規劃仍然需要，只是它的粒度會縮小。
AI 讓你能更快做出可驗證的版本，好的組織會把規劃從「承諾」轉成「校正」：
- 更頻繁地把假設拿去測
- 更快地承認方向不對
- 更快地把資源移到真正有效的問題上
我從這篇分享帶走的一個結論
MotorK 是否真的做到貼文所說的縮編幅度，外界難以核對；但它依然把一件事講得很清楚：當 AI 把產出速度推到新水位，技術債、流程、角色分工會一起被重新定價。
接下來最吃香的，不會只是「會用 AI」的人，而是能把問題定義、驗收標準、系統語彙做得很乾淨的人。這類能力以前常被忽略，現在會直接決定你能不能把速度轉成成果。
