AI 寫得越快，屎山會長得越快嗎？AI 原生開發的新技術債

摘要

生成式 AI 與 coding agents 正快速降低程式碼產生、局部修改、文件草擬、測試生成與重構建議的成本。這使一個直覺問題變得迫切：如果程式碼可以比過去快數倍產生，而架構理解、驗證、整合、治理與知識同步的速度沒有同比提高，軟體是否會更快進入 technical debt、architecture erosion、compensation accumulation 與 Big Ball of Mud？

目前的實證結果並不支持「AI 必然提高或降低軟體工程生產力」這種單向結論。Microsoft 2025 年彙整三個企業 field experiments、共 4,867 名開發者，觀察到 AI coding assistant 使用者完成任務數約提高 26%；METR 對熟悉大型開源專案的資深開發者所做的早期 2025 RCT，則觀察到使用 AI 的任務完成時間增加 19%。METR 在 2026 年嘗試以更新模型延續研究，但因愈來愈多開發者不願在無 AI 條件下參與，使樣本選擇偏差加劇，因此認為新實驗已無法可靠估計當下整體 productivity effect。這些差異顯示：AI 對「速度」的影響高度依賴任務、熟悉度、工具世代與工作流程。

相比之下，一個更穩定的趨勢正在出現：軟體工程工作的瓶頸由 creation 向 verification、integration 與 supervision 移動。2026 年縱向研究將這類工作稱為 supervisory engineering work；DORA 2025/2026 研究也將 AI 描述為一種 amplifier——它可以提高 throughput，但若 delivery foundations 不成熟，也可能放大 instability。2026 年一項針對 304,362 個已驗證 AI-authored commits、6,275 個 GitHub repositories 的大型實證研究更指出，AI 引入的 code smells、bugs 與 security issues 中，有 24.2% 在追蹤到 repository 最新版本時仍未消失；該研究仍屬近期 empirical preprint，數字不應被視為所有 AI 工具與所有專案的普世定律，但它已直接證明「AI 生成問題可以在真實 codebase 中形成持久維護負擔」。

本文因此提出「AI 原生結構負擔（AI-Native Structural Burden）」與「生成—治理缺口（Generation–Governance Gap）」。本文不把「AI 寫的 code」本身視為新型技術債，而是主張 AI 會改變負擔的生成速度、分布方式與可見性。當：

V_{\text{generation}} > V_{\text{verification}}

以及：

V_{\text{change}} > V_{\text{governance}}

持續成立時，AI 可能將原本的人類 coding bottleneck 轉化為 verification backlog、context debt、provenance debt、integration debt、specification debt 與 agent-orchestration debt。

本文進一步提出：

\rho_{AI}(t) = \frac{ V_{\text{AI-assisted change}}(t) }{ V_{\text{verification}} + V_{\text{architecture}} + V_{\text{governance}} }

作為概念性的 AI 生成—治理比率。真正的 AI-native engineering 不應追求最大化 generated code，而應同時提高治理吞吐量，使 AI 成為結構代謝加速器，而不是結構負擔放大器。

**關鍵詞：**AI coding、coding agents、technical debt、verification debt、software quality、DORA、supervisory engineering、Dynamic MSSP、FPL、生成—治理缺口

1. 問題不是 AI 會不會寫 code，而是人類會突然得到多少 code

傳統軟體工程的一個天然限制是：

V_{\text{human coding}}

有限。

一個工程師一天只能：

寫有限程式；
開有限 PR；
修改有限模組；
建立有限服務。

這個限制雖然降低產出速度，

也意外形成一種：

Natural Change Throttle

亦即天然變更節流。

但 coding agent 改變了這一點。

同樣時間內，AI 可以：

生成多個 implementation；
修改大量檔案；
建立測試；
產生 migration；
寫 adapter；
補文件；
重構；
建立全新服務。

因此：

V_{\text{generation}}\uparrow

可能非常快。

真正問題是：

架構理解、驗證、整合與治理速度有沒有一起提高？

2. AI 生產力研究沒有單一答案

目前不同研究得到不同結果。

Microsoft 2025 年研究結合：

Microsoft；
Accenture；
一家匿名 Fortune 100 公司；

三個 randomized field experiments，

總計：

N=4,867

名開發者。

合併分析觀察到：

+26.08\%

的 completed tasks，

而較缺乏經驗的開發者有更高 adoption 與 productivity gains。

這說明：

\text{AI Assistance} \rightarrow \text{Higher Throughput}

在某些真實工作環境中確實成立。

3. METR：在熟悉大型 codebase 的資深開發者身上，早期 2025 AI 反而更慢

METR 的 2025 RCT 研究：

16 名 experienced open-source developers；
246 個真實 tasks；
開發者平均對自己的 repositories 有約 5 年經驗；
repositories 大型且成熟；
主要使用 Cursor Pro 與 Claude 3.5／3.7 Sonnet。

結果是：

開發者原本預測：

24\%

加速。

做完後仍主觀認為：

20\%

加速。

但實際測得：

19\%

slower。

這是一個非常重要的提醒：

\text{Perceived Productivity} \neq \text{Measured Productivity}

但它也不能被泛化成：

AI coding 一定變慢。

因為研究只描述一個特定時期、特定人群、特定任務環境。

4. 2026 METR 更新：AI 進步太快，連實驗設計都開始失效

METR 在 2026 年公布後續實驗狀況時指出：

他們原本從 2025 年 8 月開始使用更新 AI 工具、更多開發者重新測試。

但後來發現：

愈來愈多開發者不願意參加「不能使用 AI」的 control tasks。

這造成：

Selection Bias

因而使新實驗難以可靠估計當下的 productivity uplift。

這本身就很有意思。

它表示：

AI coding 已從可選工具逐漸變成部分開發者工作流的一部分。

因此研究問題已開始由：

「有 AI vs 沒 AI」

轉向：

不同 AI-native workflow 之間有什麼差異？

5. 所以本文不使用「AI 一定讓 coding 更快」作為前提

本文需要的前提其實更弱：

\boxed{ \text{AI reduces marginal cost of producing candidate changes} }

即：

AI 降低「提出一個候選 implementation」的邊際成本。

這不等於：

候選一定正確；
integration 更快；
delivery 更穩；
專案總工時下降。

只表示：

C_{\text{candidate generation}}\downarrow

而這已足以改變整個軟體工程結構。

6. Creation → Verification：瓶頸正在移動

2026 年 Vella 與 Blincoe 的 longitudinal mixed-methods study 觀察到：

82% 參與者表示花在 writing code 的時間下降；
工作重心由 creation 向 verification activities 移動。

研究因此提出：

Supervisory Engineering Work

包括：

directing AI；
evaluating output；
correcting output。

所以：

C_{\text{creation}}\downarrow

但：

C_{\text{supervision}}\uparrow

這正是第七篇「複雜度轉移」的 AI 版本。

7. AI 不是消滅工程，而是改變工程負擔的分布

可以將傳統工程粗略表示為：

\mathbf{W}_{human} = [ W_{\text{design}}, W_{\text{code}}, W_{\text{review}}, W_{\text{test}}, W_{\text{integration}}, W_{\text{operations}} ]

AI 進入後：

W_{\text{code}}\downarrow

但可能：

W_{\text{review}}\uparrow

W_{\text{verification}}\uparrow

W_{\text{context}}\uparrow

W_{\text{governance}}\uparrow

因此：

\boxed{ \text{Less Human Typing} \neq \text{Less Software Engineering} }

8. DORA：AI 更像 amplifier，而不是 repair system

DORA 2025 State of AI-assisted Software Development 研究涵蓋近 5,000 名技術專業人士與超過 100 小時 qualitative data。

其核心描述是：

AI as an Amplifier

也就是：

AI 放大高效組織的優勢，也放大低效組織的問題。

DORA 2026 對研究的回顧進一步指出：

AI adoption 與更高 throughput 同時出現，

但在基礎不穩時也可能伴隨：

\text{Delivery Instability}\uparrow

這和本系列第八篇的：

\rho_g = \frac{V_{\text{change}}}{V_{\text{governance}}}

完全可以連接。

如果 AI 主要提高：

V_{\text{change}}

而：

V_{\text{governance}}

沒提高，

則：

\rho_g\uparrow

9. AI 技術債：真正需要避免概念濫用

很容易直接說：

AI-generated code = technical debt。

這是不正確的。

AI 生成的 code 可以：

很好；
很差；
比人類更簡單；
比人類更安全；
或具有完全不同的 defect profile。

因此：

\text{AI Authorship} \nRightarrow \text{Technical Debt}

technical debt 仍然需要：

\text{Future Cost Relation}

才能成立。

10. 但 AI 的確可以生成長期維護負擔

2026 年 Liu 等人研究：

304,362

個 verified AI-authored commits，

來自：

6,275

個 GitHub repositories，

涵蓋五種常見 AI coding assistants。

研究以 static analysis 比較 commit 前後，

辨識 AI change 新增的：

code smells；
bugs；
security issues。

結果辨識出：

484,606

個 distinct issues。

其中：

89.1\%

為 code smells。

而每一種研究中的 AI assistant 都有超過：

15\%

的 commits 至少引入一項 issue。

更重要的是：

24.2\%

被追蹤的 AI-introduced issues 在 repository 最新 revision 仍存在。

這是目前很重要的 real-world signal。

但它仍是近期 empirical preprint，

不能被直接外推成：

24.2% 的所有 AI code 都是永久 technical debt。

合理解讀是：

AI 引入的問題確實可以在真實 repository 中持續存在，而不是全部在下一輪 review 自動消失。

11. AI code 具有不同 defect profile

2025 IEEE ISSRE 的大規模研究比較：

human-written；
ChatGPT；
DeepSeek-Coder；
Qwen-Coder；

超過：

500,000

份 Python／Java code samples。

其結果顯示：

AI-generated code 整體：

結構較簡單；
更重複；
更容易出現 unused constructs；
更容易出現 hardcoded debugging；

而 human-written code：

structural complexity 更高；
maintainability issues 更集中。

研究同時觀察到 AI-generated code 有較多 high-risk security vulnerabilities。

因此：

\boxed{ \text{AI Code Risk} \neq \text{Human Code Risk} }

AI 不只是：

比人類好／比人類差。

而可能形成：

不同種類的品質負擔。

12. 第一種 AI 原生負擔：Verification Debt

本文提出：

Verification Debt

當生成變更的速度：

V_g

高於可靠驗證速度：

V_v

則形成：

Q_v(t)

即未充分驗證的變更佇列。

若：

V_g>V_v

持續，

則：

\frac{dQ_v}{dt}>0

這不一定是傳統 technical debt。

但如果這些未充分驗證的 change 被 merge、部署並成為後續依賴，

它就可能轉化成：

D_{\text{technical}}

13. 第二種：Context Debt

AI Agent 通常不是在「完整世界模型」中工作。

它可能只看到：

current files；
retrieved docs；
selected tests；
prompt；
current branch。

但真正有效架構還包括：

A_e = \Psi( A_C,A_R,A_D,A_O,A_H,A_X,A_K )

如果 AI 看不到：

historical reason；
external consumer；
manual workflow；
hidden compatibility；
runtime traffic；
incident history；

就可能生成：

\text{Locally Correct}

但：

\text{Globally Misaligned}

的修改。

本文稱：

Context Debt

即：

系統必要上下文沒有被持續外部化、索引與提供給生成者，因此每次 AI change 都需要重新猜測架構。

14. Context Debt 不是 AI 的 hallucination 問題而已

如果一個系統的重要規則只存在於：

「老王知道。」

那麼人類新人也會犯錯。

AI 只是把這個問題放大。

因此：

D_{\text{context}}

真正表示：

K_{\text{required}} - K_{\text{available}}

的差距。

AI-native system 越依賴 agents：

D_{\text{context}}

越重要。

15. 第三種：Provenance Debt

AI 生成大量 artifact 後，

如果系統無法回答：

這段 code 為什麼改？
根據哪個 requirement？
哪個 Agent 產生？
使用哪個 context？
哪些 tests 通過？
哪些 evidence 支持？
哪個 human review？

就形成：

Provenance Debt

記為：

D_p

它不一定影響今天執行，

但會提高：

C_{\text{future understanding}}

與：

C_{\text{incident reconstruction}}

因此非常符合 technical debt 的跨時間成本性質。

16. 第四種：Specification Debt

AI 很擅長：

根據 prompt 寫一個東西。

但如果 prompt 本身只有：

幫我做登入系統

AI 可以產生大量 implementation。

真正缺少的是：

authority；
state；
failure；
security；
recovery；
data ownership；
lifecycle；
verification criteria。

因此：

C_{\text{implementation}}\downarrow

會讓：

C_{\text{underspecification}}

變得更明顯。

本文稱：

Specification Debt

即：

系統要求沒有被形式化到足以支持大規模自動生成，卻已經開始大量生成 implementation。

17. 第五種：Integration Debt

AI 可以同時生成：

service A
service B
service C

每個看起來都合理。

但整合需要處理：

contract；
version；
retry；
transaction；
state；
permission；
deployment；
observability。

因此：

N_{\text{generated components}}\uparrow

可能使：

N_{\text{integration surfaces}}\uparrow

更快。

如果 component generation：

O(n)

而 pairwise integration surface 在最壞情況：

O(n^2)

那麼：

AI 可以非常快地生成比團隊能整合更多的組件。

這就是：

Integration Debt

18. 第六種：Orchestration Debt

Agentic development 不只產生 code。

它還引入：

planner；
coding agent；
test agent；
review agent；
security agent；
deployment agent。

如果這些 Agent：

權限不清；
responsibility overlap；
context 不一致；
retry rule 不一致；
output authority 不清；

則：

C_{\text{agent coordination}}\uparrow

本文稱：

Orchestration Debt

這是 AI-native software 才特別突出的負擔。

19. 第七種：Supervision Debt

如果組織說：

AI 產生的 code 全部要人工 review。

但 AI generation throughput：

10\times

增加，

human review capacity：

1.5\times

增加，

則：

Q_{\text{review}}\uparrow

最後會出現兩個可能：

merge queue 越來越長；
review quality 下降。

因此：

Supervision Debt

不是：

人類懶得 review。

而是：

監督能力沒有跟 generation capacity 同步擴張。

20. AI 原生結構負擔向量

因此本文提出：

\boxed{ \mathbf{B}_{AI} = [ D_v, D_c, D_p, D_s, D_i, D_o, D_{sup} ] }

其中：

$D_v$ ：Verification Debt；
$D_c$ ：Context Debt；
$D_p$ ：Provenance Debt；
$D_s$ ：Specification Debt；
$D_i$ ：Integration Debt；
$D_o$ ：Orchestration Debt；
$D_{sup}$ ：Supervision Debt。

這些不是全部都已經是既有標準 technical-debt taxonomy。

它們是本文為 AI-native engineering 提出的分析維度。

21. 這些負擔會轉化成傳統 technical debt

例如：

D_v

未驗證 change 長期存在後，

可能：

D_v\rightarrow D_t

Context Debt 造成錯誤 architecture assumption：

D_c\rightarrow E

Provenance Debt 造成未來理解成本：

D_p\rightarrow D_t

Integration Debt 造成 adapter proliferation：

D_i\rightarrow L_c

所以 AI 原生負擔不是與舊世界完全分離。

它們會流入前九篇建立的結構動力系統。

22. AI 可能加速「補償凝固」

以前一個 workaround 要長成 subsystem，

可能需要：

T=6\text{ months}

現在 AI Agent 可以：

script
→ API
→ UI
→ database
→ deployment

在幾天內完成。

因此：

T_{\text{solidification}}\downarrow

如果業務立刻使用：

\operatorname{Dependents}\uparrow

那麼：

\Gamma_C

可以非常快上升。

所以 AI 不只加快 coding。

它也可能加快：

Architectural Solidification

23. AI 可能加速 Historical Residue 的產生

AI 讓：

C_{\text{new artifact}}\downarrow

因此團隊較容易：

不刪舊的，再做新的。

例如：

old parser
+
new parser
+
adapter

因為新增成本變便宜。

如果：

C_{\text{addition}}\ll C_{\text{removal verification}}

則組織自然偏向新增。

因此：

G_H

即 historical residue generation rate 可能提高。

這是非常值得警惕的 AI-native asymmetry。

24. 生成比刪除容易，會形成新的沉積偏差

在成熟系統裡本來就有：

C_{\text{delete}} > C_{\text{add}}

AI 又進一步讓：

C_{\text{add}}\downarrow

所以：

\frac{ C_{\text{delete}} }{ C_{\text{add}} } \uparrow

這意味：

AI 越會生東西，系統越需要專門的淘汰機制。

否則：

|Artifacts(t)|

會快速增長。

25. 生成—治理缺口

本文正式提出：

Generation–Governance Gap

令：

V_{AI} = V_{\text{AI-assisted change}}

而：

V_G = V_{\text{verification}} + V_{\text{architecture}} + V_{\text{governance}}

則：

\boxed{ G_{AI} = V_{AI} - V_G }

如果：

G_{AI}>0

持續，

則未治理 change backlog 具有累積壓力。

26. AI 生成—治理比率

進一步定義：

\boxed{ \rho_{AI}(t) = \frac{ V_{\text{AI-assisted change}}(t) }{ V_{\text{verification}}(t) + V_{\text{architecture}}(t) + V_{\text{governance}}(t) } }

當：

\rho_{AI}<1

表示 governance capacity 足以吸收 AI 生成速度。

當：

\rho_{AI}\approx1

可能達到動態穩態。

當：

\rho_{AI}>1

長期成立，

則：

\frac{dB_{AI}}{dt}>0

的風險增加。

27. AI-native Big Ball of Mud 的形成路徑

傳統泥巴可能是：

需求
→ 人類 patch
→ 新需求
→ 新 patch
→ coupling

AI-native 版本可能變成：

需求
→ Agent generates solution
→ tests pass
→ merge
→ next Agent sees local code
→ generates another solution
→ local tests pass
→ merge
→ hidden architecture divergence
→ more adapters
→ more generated fixes

這形成：

\text{Local Correctness} + \text{High Change Velocity} \rightarrow \text{Global Structural Drift}

如果沒有 architecture-aware governance。

28. 「測試都過了」也不保證 AI change 沒有架構問題

Test 通常回答：

observable behavior 是否符合某些 cases？

但前幾篇已經指出：

I_o\nRightarrow I_s

所以：

\text{Tests Pass} \nRightarrow \text{Architecture Healthy}

AI 特別容易優化：

讓當前 test pass。

但可能同時：

增加 hidden dependency；
複製 state；
bypass authority；
增加 compatibility burden；
破壞未来 evolvability。

因此 AI QA 不能只增加 tests。

還需要：

Structural Verification

29. Agentic Refactoring：AI 也可以是治理工具

這一篇不能只談風險。

2025 年 Agentic Refactoring 研究分析：

15,451

個 AI-agent-generated refactoring instances，

來自：

12,256

個 pull requests。

研究發現：

agentic refactoring 很常見；
26.1% commits 明確以 refactoring 為目標；
agent 偏好低階、一致性導向的 refactoring；
maintainability 與 readability 是主要動機；
部分 structural metrics 有小幅但顯著改善。

所以：

V_{\text{governance}}

也可以由 AI 提升。

AI 不只能：

G_{\text{burden}}\uparrow

也可以：

R_{\text{governance}}\uparrow

30. 真正問題不是「要不要 AI」，而是 AI 在分子還是分母

第八篇定義：

\rho_g = \frac{ V_{\text{change}} }{ V_{\text{governance}} }

AI 可以同時作用在 numerator 與 denominator。

如果主要用 AI 生成：

V_{\text{change}}\uparrow

則：

\rho_g\uparrow

如果同時用 AI 做：

architecture recovery；
impact analysis；
test generation；
security analysis；
dependency analysis；
documentation sync；
deprecation detection；
compensation discovery；

則：

V_{\text{governance}}\uparrow

可能讓：

\rho_g\downarrow

因此：

AI 是讓屎山長更快，還是讓系統代謝更快，取決於它主要被放在哪一側。

31. AI-native engineering 的真正競爭可能是治理吞吐量

當 frontier coding agents 都能快速產生 implementation 後：

V_{\text{generation}}

可能逐漸商品化。

真正區分團隊的能力會轉向：

V_{\text{trusted integration}}

即：

Trusted Integration Throughput

它包括：

specification；
verification；
architecture；
security；
provenance；
migration；
observability；
rollback。

所以 AI 時代真正珍貴的不是：

誰一天產生最多 code。

而是：

誰一天能安全吸收最多經過驗證的有效變更。

32. 從 Lines of Code 轉向 Verified State Transition

Program Ontology 的視角在這裡尤其重要。

如果：

Program\neq SourceCode

那麼 AI coding 的真正產物也不應該只算：

LOC

更合理是：

\text{Intent} \rightarrow \text{Structured Change} \rightarrow \text{Verification} \rightarrow \Delta W

所以產能應該衡量：

Verified State Transitions

而不是：

Generated Tokens

33. Dynamic MSSP 的 AI Gate

未來 Dynamic MSSP 可以在 AI Agent change 後輸出：

ai_change:
  agent: coding-agent-17
  task: add_payment_retry_policy

  provenance:
    prompt_ref: task-8831
    context_snapshot: ctx-a29d

  verification:
    unit_tests: pass
    integration_tests: pass
    architecture_checks: warning

  structural_effects:
    new_dependencies:
      - payment-core -> retry-policy
    authority_change: none
    compensation_added:
      - retry-on-timeout

  risks:
    retry_amplification: medium
    compatibility_impact: low

  governance:
    review_required: true
    evidence_confidence: 0.86

這代表：

AI 生成的不是「code」。

而是：

一個有來源、有證據、有結構影響的 architecture transaction。

34. AI Change Budget

如果：

V_{\text{generation}}

可以無限上升，

一個成熟組織反而可能需要：

AI Change Budget

也就是每個時間窗口只允許：

N_{\text{AI changes}}

在：

review capacity；
test capacity；
incident capacity；
architecture capacity；

能吸收的範圍內。

這與 SRE 的 error budget 很像，

但作用在：

Change Absorption Capacity

而不是 availability。

35. 不是限制 AI，而是避免治理系統飽和

因此 Change Budget 的目的不是：

讓 AI 少做事。

而是：

V_{\text{accepted}} \le V_{\text{trusted absorption}}

即：

不要讓 change ingestion rate 長期高於組織可以可靠吸收的速度。

如果治理能力提升：

V_{\text{trusted absorption}}\uparrow

budget 就能提高。

36. AI 也可能第一次讓大型系統做到高頻結構治理

傳統 architecture review 的問題是：

C_{\text{review}}

太高。

所以：

半年一次

甚至：

出事再看

很常見。

但 AI 可以每個 PR：

recover architecture；
compare FPL；
inspect dependency；
check authority；
search historical reason；
estimate impact。

於是：

f_{\text{architecture review}}\uparrow

可能接近：

f_{\text{code change}}

這會是 Dynamic MSSP 最有價值的用途之一。

37. AI 時代真正的新架構不是「AI 幫你寫 code」

更強的 AI-native stack 應該是：

\text{Intent}

↓

\text{Architecture Context}

↓

\text{Agent Generation}

↓

\text{Deterministic Validation}

↓

\text{AI Structural Review}

↓

\text{Runtime Evidence}

↓

\text{Governed Commit}

而不是：

prompt
→ generate
→ tests pass
→ merge

38. 命題 10：AI 生成—治理不對稱命題

本文提出系列第十命題。

AI 生成—治理不對稱命題

AI coding systems 降低 candidate change 的產生成本：

C_{\text{generation}}\downarrow

但並不自動同比降低：

C_{\text{verification}}

C_{\text{integration}}

C_{\text{architecture}}

C_{\text{governance}}

因此若：

\boxed{ V_{\text{AI-assisted change}} > V_{\text{trusted governance}} }

持續成立，

則：

\boxed{ \frac{dB_{AI}}{dt}>0 }

的風險上升。

39. 強版本：AI 是結構放大器

結合 DORA 的 amplifier framing，可得到：

\boxed{ \text{AI} \approx \text{Structural Amplifier} }

如果系統已有：

清楚 architecture；
tests；
observability；
ownership；
versioning；
governance；

AI 可以放大：

V_{\text{good change}}

如果系統已有：

hidden dependencies；
vague requirements；
weak review；
poor documentation；
unclear authority；

AI 也可以放大：

V_{\text{structural disorder}}

40. 結論：AI 不一定讓屎山長更快，但它讓「長多快」第一次變成治理問題

回到標題：

AI 寫得越快，屎山會長得越快嗎？

答案是：

不必然。

如果 AI 同時提高：

V_{\text{generation}}

與：

V_{\text{governance}}

而且：

\rho_{AI}\le1

它甚至可能讓大型 legacy system 第一次擁有足夠高頻的：

refactoring；
architecture recovery；
impact analysis；
testing；
documentation；
migration。

但如果組織只提高：

V_{\text{generation}}

則：

\rho_{AI}>1

會形成新的結構負擔累積壓力。

所以真正的問題不是：

AI 會不會寫壞 code。

而是：

我們產生可信變更的速度，能不能追上產生候選變更的速度？

最終，AI-native engineering 的核心指標不應是：

\text{Lines of Code per Day}

甚至不只是：

\text{Tasks Completed}

而更接近：

\boxed{ \text{Verified, Governed, Reversible State Transitions per Unit Time} }

只有當這個數量真正提高，

AI 才不只是：

更快地寫軟體。

而是：

更快地演化軟體，同時沒有比過去更快失去對它的理解與控制。

下一篇將直接把這些命題落回 MSSP：

〈從靜態 MSSP 到動態 MSSP：讓架構角色成為可觀察狀態〉

正式建立：

R_d(M) \neq R_o(M,t) \neq R_e(M,t)

以及 Dynamic MSSP 如何利用 runtime、dependency、data flow、history、incident 與 AI evidence 進行持續架構判斷。

參考文獻

Cui, Z. (K.), Demirer, M., Jaffe, S., Musolff, L., Peng, S., & Salz, T. (2025). The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers. Microsoft Research / preprint.
Becker, J., Rush, N., Barnes, E., & Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv:2507.09089; METR.
Becker, J., Rush, N., Cunningham, T., Rein, D., & Mahamud, K. (2026). We are Changing our Developer Productivity Experiment Design. METR, February 24, 2026.
Vella, A., & Blincoe, K. (2026). The Impact of AI Coding Assistants on Software Engineering: A Longitudinal Study. arXiv:2605.23135.
DeBellis, D., Storer, K., Harvey, N., Beane, M., Edwards, R., Fraser, E., et al. (2025). DORA 2025 State of AI-assisted Software Development Report. Google / DORA.
DORA. (2026). Balancing AI tensions: Moving from AI adoption to effective SDLC use. DORA Insights.
Liu, Y., Widyasari, R., Zhao, Y., Irsan, I. C., & Lo, D. (2026). Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild. arXiv:2603.28592.
Cotroneo, D., Improta, C., & Liguori, P. (2025). Human-Written vs. AI-Generated Code: A Large-Scale Study of Defects, Vulnerabilities, and Complexity. IEEE ISSRE 2025. DOI: 10.1109/ISSRE66568.2025.00035.
Butler, J., Suh, J., Haniyur, S., & Hadley, C. (2025). Dear Diary: A Randomized Controlled Trial of Generative AI Coding Tools in the Workplace. ICSE-SEIP 2025.
Horikawa, K., Li, H., Kashiwa, Y., Adams, B., Iida, H., & Hassan, A. E. (2025). Agentic Refactoring: An Empirical Study of AI Coding Agents. arXiv:2511.04824.
Stray, V., Brandtzæg, E. G., Wivestad, V. T., Barbala, A., & Moe, N. B. (2025). Developer Productivity With and Without GitHub Copilot: A Longitudinal Mixed-Methods Case Study. arXiv:2509.20353.
Neo.K / EveMissLab. 《表觀完好系統》系列第 1–9 篇，以及 MSSP / FPL / Program Ontology 既有研究。