OpenAI onepage/ AI delivery
Engineering lens · AI-assisted development
Code 快 10 倍，交付為何只快 1.37 倍？
阿姆達爾定律提醒我們：AI 把某一段工作大幅加速，不等於整個軟體交付流程同樣加速。真正的上限，取決於有多少工作能被一起改造。
Published: 2026-08-06Source: ChatGPT shared conversationTopic: Amdahl’s Law
01 / 定律
局部無限快，整體仍有限
阿姆達爾定律原本描述平行運算：未被加速的串行部分，決定系統加速的天花板。
02 / 套到開發
Coding 只是交付的一段
需求釐清、架構設計、測試、Code Review、資安、Change 與跨單位溝通，都會保留在交付路徑上。
03 / 管理含義
衡量 Close the Loop
別只問 AI 寫了多少程式；更該問一項需求有多少端到端工作，能在可驗證的前提下交給 AI 完成。
The calculation
把「快十倍」放回完整流程
假設一個需求從開始到上線需 100 小時，其中 Coding 佔 30 小時；AI 將 Coding 加速 10 倍，其餘工作暫時不變。
Speedup = 1 / ((1 − P) + P / S)
= 1 / (0.7 + 0.3 / 10) ≈ 1.37×
= 1 / (0.7 + 0.3 / 10) ≈ 1.37×
結果是：30 小時的 Coding 變成約 3 小時，總工時從 100 降至 73；效果很有價值，但不是「全流程十倍速」。即使 Coding 瞬間完成，總體也只會到 1 / 0.7 = 1.43×。
Key signals
三個數字，避免把局部效能當成整體效能
Accelerated share
30%
示例中只有 Coding 能明顯被 AI 加速；剩下七成決定交付天花板。
Coding speed
10×
局部加速很顯著，卻無法自動消除等待、驗證與協作成本。
Delivery speed
1.37×
這是從流程角度看到的淨效益，而不是模型 benchmark。
Coding limit
1.43×
若其餘 70% 不動，Coding 無限快仍突破不了這個上限。
Bottleneck shift
AI 不是移除瓶頸，而是讓瓶頸浮出來
前
寫程式本身是主要等待
工程師花大量時間在實作、查 API、補樣板與反覆修改。這正是 Coding Agent 最容易帶來可見改善的區域。
後
Review、QA 與整合接住更多輸出
當產出速度提高，人工審查、測試環境、CI 容量、產品決策與部署流程可能成為下一個排隊點。更快的產生，不必然等於更快的可用結果。
解
把 Agent 延伸到可驗證的交付閉環
可將規格、測試、證據蒐集、review 準則與發布檢查設計成流程能力；重點不是跳過責任，而是縮短可被可靠驗證的每一段等待。
Operating model
下一步該投資在哪裡
從需求開始縮短 feedback loop將模糊需求轉成可檢查的 acceptance criteria、介面契約與風險假設，降低返工與等待決策的時間。
讓測試成為 agent 的工作產品要求 AI 不只產生實作，也產生可重跑的測試、測試資料與失敗說明；否則 QA 只會承接更多不確定性。
重新設計 Review 的吞吐量用小型變更、可追溯證據、風險分級與自動檢查，將人的判斷留給真正需要判斷的地方。
把治理與部署納入同一張圖在受監管或跨團隊環境，資安、合規、Change 與 Release 不是附帶流程，而是端到端交付的一部分。
A useful caveat
別把定律用成悲觀結論
先用 Amdahl 看固定流程的上限它適合指出：在工作量與流程固定時，哪個未加速部分會吞掉局部速度提升。
再用需求擴張的視角看新價值AI 降低開發成本後，團隊可能願意多做測試、重構、文件與 prototype。這不是失敗，而是把節省下來的能力投入更大的問題。
把 KPI 從產碼量改成可用交付追蹤 lead time、重工、驗證通過率、review 等待與發布可靠度，會比追蹤 AI 產生多少行程式更接近真實效益。
References