最近 AI Coding 最明顯的改變，大概就是：

Build 真的變快了。

以前一個 Feature，Engineer 可能估 10 個工作天。

現在有 AI Coding Tool 協助，也許 5 天，甚至更短。

Prototype 更明顯，以前幾天才能看到的東西，現在幾個小時就可以跑起來。

照理說：

Coding 快 50%，Product 上線速度是不是也應該快 50%？

但真的做 Project 時，我發現完全不一定。

因為一個 Feature 從 Requirement 到 Production，

真正花掉的時間，可能根本不主要在 Coding。

一個 Feature 做 4 天，為什麼 25 天才上線？

假設今天有一個 Requirement：

在申請 System 裡，自動帶出員工組織資料。

真正需要動手 Build 的時間可能是：

Frontend          1 天
API Integration   2 天
Testing           1 天

Total             4 天

但整個 Project 可能長這樣：

Day 1
提出 Requirement

↓ 等 Business 確認欄位

Day 4
欄位確認

↓ 等 API Owner 回覆

Day 8
API 確認

↓ 等 Permission

Day 13
Permission Ready

↓ Development

Day 17
Build Complete

↓ 等 UAT

Day 21
User Testing

↓ 修改 / Sign-off

Day 25
Production

真正有人動手 Build：

4 天。

Requirement 到 Production：

25 天。

這兩個數字其實在回答完全不同的問題。

Touch Time 和 Lead Time，是兩件事

我現在會把 Product Delivery 的時間拆成兩種：

Touch Time

真正有人在處理這件事情的時間。

例如：

寫 Requirement
Design
Coding
Testing
Review

Lead Time

從 Requirement 開始，

一直到 User 真的可以使用，

總共經過多久。

假設：

Touch Time = 8 天

Lead Time = 25 天

代表剩下的 17 天，

很多時候其實都在：

Waiting for User

Waiting for Decision

Waiting for API

Waiting for Permission

Waiting for Review

Waiting for UAT

這也是為什麼 AI Coding 就算把：

Development
8 天 → 3 天

整個 Product 的 Lead Time，

也不一定會：

25 天 → 10 天

可能只是：

25 天 → 20 天

因為真正最大的 Waiting Time 還在。

AI Coding 可能只是讓 Bottleneck 搬家

這其實很接近 Theory of Constraints 的概念：

一個 System 的 Throughput，會受到主要 Constraint 限制。

假設原本：

Requirement → Design → Build → Review → Release

    3天        5天      10天      3天       2天

最大的 Bottleneck 是 Build。

所以大家一直想：

怎麼讓 Engineer 更快？

現在 AI Coding 進來：

Build
10 天 → 3 天

很好。

但下一個 Bottleneck 馬上浮出來：

Design：5 天

再把 Design 加速，

可能又變成：

Security Review：7 天

所以 Bottleneck 沒有真的消失。

它只是：

Bottleneck Migration。

這也是我覺得 AI 時代 PM 很需要建立的一個視角：

不要只看哪一個 Step 被 AI 加速，而要一直找：新的 Constraint 搬去哪裡了？

Build 越快，另一個問題反而可能出現：WIP 變多

這件事其實更反直覺。

以前一個 Team 一個月只能做 5 個 Feature。

Business 知道資源有限，

自然會比較謹慎：

這件事情真的值得做嗎？

現在大家開始覺得：

「這個 AI 一下就能做吧？」

「先 Vibe Coding 一版看看。」

「這個應該不用幾天。」

結果一個月可能同時進來 20 件。

Coding 的確變快。

但每一個 Feature 後面還是需要：

Review
Test
UAT
Security
Release
Maintenance

最後 Team 手上開始出現很多：

做到一半

等 Review

等 User

等 Permission

等 Release

的 Feature。

這就是 WIP（Work in Progress）。

Build Capacity 增加，

不代表 Throughput 一定增加。

如果 WIP 不斷累積，

Product Flow 反而可能更塞。

所以我現在不只想知道「Development 到幾 %」

以前 Project Meeting 很常問：

「現在開發進度多少？」

80%。

90%。

但如果：

Code              90%

Business Rule      ?
Permission        Waiting

Security Review   Not Started

UAT               Not Started

這個 Product 真的算 90% 嗎？

我現在反而更想看：

Requirement Ready    ✓

Data Ready           ✓

Dependency Ready     ?

Permission Ready     ?

Build Ready          ✓

UAT Ready            ?

Production Ready     ?

因為真正決定 Product 什麼時候能上線的，

不是：

Code 寫了多少。

而是：

整條 Delivery Flow 還剩多少 Blocker。

AI 時代，PM 可能要從管理「Development Effort」轉向管理「Flow」

以前 Development Capacity 很稀缺。

所以 PM 很常討論：

Engineer 要幾天？

這個 Sprint 放得下嗎？

這個 Feature 幾個 Story Point？

Resource 夠不夠？

這些當然還是重要。

但如果 AI 持續把 Build Cost 往下降，

我覺得 PM 會越來越需要多看幾個數字：

1. Lead Time

Requirement
→ Production

總共多久？

2. Touch Time

真正有人處理它多久？

3. Waiting Time

有多少時間其實在等？

4. WIP

同時有多少事情做到一半？

5. Rework

有多少東西 Build 完，

又因為 Requirement / Rule 不清楚而重做？

這幾個數字，會告訴你真正該 Optimize 哪裡

假設：

Lead Time      20 天
Touch Time      5 天
Waiting Time   15 天

可以很粗略地看一個概念：

Flow Efficiency
= Touch Time / Lead Time

= 5 / 20
= 25%

我不一定會真的把它變成 Team KPI。

但這個概念會逼我問：

我們到底是在做事情，還是在等事情？

如果 AI 已經把 Coding Time 壓得很低，

下一個最大的 Opportunity，

可能根本不是：

再讓 AI 幫 Engineer 快 20%。

而是：

怎麼把那 15 天 Waiting Time 拿掉？

一個很實際的方法：更早把 Dependency 找出來

這也會接回我 Day 18 寫的：

Known
Unknown
Assumption
Next Action

以前可能是：

Requirement
↓
Design
↓
Development
↓
做到一半發現需要 API
↓
問 API Owner
↓
發現還要 Permission
↓
開始申請

這是一個很典型的 Sequential Flow。

但如果 Requirement 一進來，

PM 就先把 Dependency 找出來：

Requirement
     ↓
Dependency Review
     ↓
┌──────────┬──────────┬──────────┐
│ Design   │ API確認  │ Permission│
└──────────┴──────────┴──────────┘
     ↓
Build

很多事情就可以 Parallel Start。

真正省掉的，

可能不是 Coding 的兩天。

而是：

原本第 10 天才發現的 Blocker，第 1 天就開始處理。

這對 Lead Time 的影響可能更大。

Build 變快，也代表「做錯」可以變得更快

AI Coding 還有一個我覺得很值得注意的副作用。

以前 Build 很貴，

大家會比較慎重：

Requirement Ready 了嗎？

Design 確定了嗎？

現在因為很容易做，

很可能變成：

Day 1 Requirement

Day 2 AI Coding

Day 4 Feature Done

Day 5 User Review

然後 User 說：

「不是，我們實際流程不是這樣。」

接著：

Build
↓
Rework
↓
Build
↓
Rework

每一次 Build 都很快。

但整體 Product Delivery 不一定比較快。

所以真正值得 Optimize 的問題不是：

How fast can we build?

而是：

How fast can we get the right thing into production?

這也讓我開始理解，為什麼 Product Team 的組織方式可能也要變

當最大的 Bottleneck 從：

「Code 寫得太慢」

慢慢移到：

Requirement

Decision

Data

Integration

User Feedback

跨 Team Dependency

我覺得下一個值得問的問題就是：

我們現在這種一層一層 Handoff 的 Product Team，還是最快的方式嗎？

這也是為什麼最近我開始注意到 Forward Deployed Engineering（FDE） 這種模式。

它真正讓我有興趣的地方，

不只是：

「Engineer 更靠近 User。」

而是另一個問題：

如果 Bottleneck 已經變了，我們是不是也需要重新設計 Product Team 的 Delivery Model？

這個我後面會再單獨寫一篇。

Day 22｜AI Coding 加速的是 Build，PM 要 Optimize 的是整條 Flow

如果只看 Coding，

AI 帶來的效率提升已經非常明顯。

但站在 PM 的角度，

我現在更想知道：

Requirement 到 Production 快了多少？

Waiting Time 少了嗎？

Dependency 有沒有更早發現？

WIP 有沒有增加？

Rework 有沒有下降？

因為最後 User 不在乎：

Code 是三天寫完還是十天寫完。

User 真正在乎的是：

他需要的東西，什麼時候真的可以用。

Product Principle

AI Coding Optimize 的是 Build Time；真正的 Product Velocity，要 Optimize 的是 End-to-End Lead Time。

當 Coding 不再是最大的 Bottleneck，

PM 下一步要找的，

可能不是：

「哪一段 Code 還能再快一點？」

而是：

整條 Product Delivery Flow 裡，時間到底都卡在哪裡？