# 生成—治理缺口與 AI 原生結構負擔 v0.2 ## ——從候選變更爆發到可信狀態轉換吞吐量 **English Title:** *The Generation–Governance Gap and AI-Native Structural Burden: From Candidate-Change Explosion to Trusted State-Transition Throughput* **系列：**《綠燈錯置：AI 操作意圖不對齊與完成失真》06 / 08 **作者：** Neo.K × AI 協作 **版本：** v0.2 **日期：** 2026-09-16 **文件性質：** AI Engineering／Software Architecture／Agentic Coding／Verification Governance／Technical Debt／Delivery Throughput **承接：** A01〈綠燈錯置〉、A03〈局部正確與全域失敗〉、A04〈流程代理錯置〉、A05〈驗證義務膨脹與 Completion Drift〉 **核心前序：**〈AI 寫得越快，屎山會長得越快嗎？AI 原生開發的新技術債〉 **後續接口：** A07〈能力—視角啟動不對稱〉、A08〈同質綠燈〉、Series B〈宏觀個體導向的動態全域觀察方法論〉 **機構：** EveMissLab／一言諾科技有限公司 --- ## 摘要 生成式 AI 與 coding agents 最重要的工程變化，未必是「AI 能不能寫程式」，而是： $$ \boxed{ C_{\mathrm{candidate\ generation}}\downarrow } $$ 亦即候選變更、候選實作、候選修復、候選測試、候選重構與候選架構方案的邊際產生成本快速下降。 但可信軟體變更的成本並不只有生成。任何實際可被接受、合併、部署並成為未來依賴的變更，至少還需要經過不同程度的： $$ \text{Verification}, $$ $$ \text{Integration}, $$ $$ \text{Architecture Reasoning}, $$ $$ \text{Governance}, $$ $$ \text{Provenance}, $$ $$ \text{Runtime Observation}, $$ $$ \text{Recovery / Reversibility.} $$ 因此 AI coding 的真正吞吐量問題不是： $$ V_{\mathrm{generation}} $$ 有多高，而是： $$ \boxed{ V_{\mathrm{trusted\ absorption}} } $$ 能否同步提高。 本文將此前提出的「生成—治理缺口（Generation–Governance Gap）」正式推進成一套**變更流體／佇列式工程模型**。令： $$ V_g = \text{candidate generation throughput}, $$ $$ V_v = \text{verification throughput}, $$ $$ V_i = \text{integration throughput}, $$ $$ V_a = \text{architecture-assessment throughput}, $$ $$ V_{gov} = \text{governance throughput}. $$ 則真正可以進入可信產品狀態的吸收率，不應直接寫成各項總和，而更接近受最慢必要 stage 約束的： $$ \boxed{ V_T = \min \left( V_g, V_v, V_i, V_a, V_{gov}, V_{runtime} \right) } $$ 其中 $V_T$ 可稱： # **Trusted Change Throughput** 如果： $$ V_g \gg V_T, $$ 則系統並沒有獲得等比例軟體演化能力，而是開始累積： $$ Q_v, Q_i, Q_r, Q_p,\ldots $$ 等 backlog。 本文沿用既有研究中的 AI 原生結構負擔向量： $$ \mathbf B_{AI} = [ D_v, D_c, D_p, D_s, D_i, D_o, D_{sup} ], $$ 分別表示： - Verification Debt； - Context Debt； - Provenance Debt； - Specification Debt； - Integration Debt； - Orchestration Debt； - Supervision Debt。 v0.2 進一步加入： - Elimination Debt； - Observability Debt； - Closure Debt； - Substrate Compensation Burden； 並將它們理解成**候選變更速度與可信吸收速度之間的不對稱沉積物**。 外部研究目前並不支持「AI-generated code 必然更差」這種簡單敘事。2025–2026 的研究呈現高度混合結果：部分研究顯示 LLM 生成 code 在某些 maintainability / reliability 指標上優於人類基準；另一些大型研究則觀察到不同的 defect profile、較高的某些高風險弱點、真實 repository 中持續存在的 AI-introduced issues，以及 copy/paste、duplication、churn 等 maintainability signals 的惡化。這些結果不能被壓成單一品質結論。 相對穩定的共同訊號是： > **生成速度上升後，verification、review、integration、supervision 與 governance 會成為新的瓶頸。** DORA 2025 將 AI 描述為 amplifier；DORA 2026 明確指出 AI 加速 initial code generation，但創作端節省的時間經常被重新投入 auditing 與 verification。2026 年一項針對 33,707 個 agent-authored PR 的研究更發現 review effort 具有高度不均勻分布，並能以 PR 結構特徵在建立時預測高 review-effort PR；在其資料中，以 20% review budget 可攔截 69% 總 review effort。這表示 governance capacity 本身已可被建模、預測與路由。 本文的核心主張不是「降低 governance」，而是： $$ \boxed{ \text{Scale governance throughput with generation throughput.} } $$ 最終，AI-native engineering 更合理的核心產能指標不是： $$ LOC/day, $$ 也不是： $$ Tokens/day, $$ 甚至不只是： $$ Tasks/day, $$ 而是： $$ \boxed{ \textbf{ Verified, Integrated, Governed, Reversible State Transitions per Unit Time } } $$ 亦即： > **一個系統每單位時間究竟能吸收多少「真的理解、真的驗證、真的整合、真的可治理」的有效變更。** --- # 1. 問題不是 AI 能寫多少，而是系統能吸收多少 傳統軟體工程具有一個經常被忽略的天然限制： $$ V_{\mathrm{human\ change}} $$ 相對有限。 工程師一天只能： - 改有限檔案； - 開有限 PR； - 設計有限 service； - 寫有限 adapter； - 跑有限實驗； - 建有限 test。 這個限制固然降低 velocity， 但它也形成： # **Natural Change Throttle** ## 天然變更節流 候選變更的供給不會遠大於： - review； - integration； - architecture reasoning； - release engineering； 可以處理的量。 AI coding agent 打破的第一件事，就是這個天然節流。 --- # 2. Candidate Change Explosion 令： $$ C_g = \text{cost of generating one plausible candidate change}. $$ AI 使： $$ C_g\downarrow. $$ 因此同一時間窗： $$ N_{\mathrm{candidate}}\uparrow. $$ 而 candidate 不只包含 code。 它還包含： - implementation； - test； - migration； - API； - adapter； - refactor； - documentation； - architecture alternative； - review finding； - security concern； - patch； - workaround。 因此： $$ \boxed{ \text{AI Generation} \neq \text{Code Generation Only}. } $$ AI 是： $$ \boxed{ \text{Candidate-State Generator}. } $$ --- # 3. Candidate 不等於 Accepted Change 令候選變更： $$ \Delta X_c. $$ 它進入 product world 之前需要： $$ \Delta X_c \rightarrow \Delta X_v \rightarrow \Delta X_i \rightarrow \Delta X_g \rightarrow \Delta X_{accepted}. $$ 粗略對應： ```text candidate → verified → integrated → governed → accepted ``` 因此： $$ \boxed{ \text{CandidateChange} \neq \text{TrustedChange}. } $$ 這與 A01 / A02 的核心分離完全一致。 --- # 4. 五種核心吞吐量 本文定義五種核心工程 throughput。 ## 4.1 Generation Throughput $$ V_g = \frac{ N_{\mathrm{candidate\ changes}} }{ \Delta t }. $$ ## 4.2 Verification Throughput $$ V_v = \frac{ N_{\mathrm{changes\ with\ sufficient\ correctness\ evidence}} }{ \Delta t }. $$ ## 4.3 Integration Throughput $$ V_i = \frac{ N_{\mathrm{changes\ with\ closed\ required\ boundaries}} }{ \Delta t }. $$ ## 4.4 Architecture Throughput $$ V_a = \frac{ N_{\mathrm{changes\ with\ understood\ structural\ impact}} }{ \Delta t }. $$ ## 4.5 Governance Throughput $$ V_{gov} = \frac{ N_{\mathrm{changes\ with\ authority,\ provenance,\ risk,\ closure}} }{ \Delta t }. $$ 這些量不是彼此獨立，但必須概念分離。 --- # 5. Pipeline Bottleneck 若可信變更必須依序通過： $$ G \rightarrow V \rightarrow I \rightarrow A \rightarrow \text{Gov}, $$ 則 steady-state throughput 更接近： $$ \boxed{ V_T = \min( V_g,V_v,V_i,V_a,V_{gov} ). } $$ 這與 pipeline / queueing system 的基本直覺相同： > 最慢的必要 stage 限制整體吞吐量。 因此： $$ V_g\uparrow10\times $$ 如果： $$ V_v\uparrow1.2\times, $$ 不會得到： $$ V_T\uparrow10\times. $$ 而會先得到： $$ Q_v\uparrow. $$ --- # 6. Generation–Governance Gap 既有研究定義： $$ V_{AI} = V_{\text{AI-assisted change}}, $$ 以及治理能力： $$ V_G = V_{\mathrm{verification}} + V_{\mathrm{architecture}} + V_{\mathrm{governance}}. $$ 並提出： $$ \boxed{ G_{AI} = V_{AI} - V_G. } $$ v0.2 將其修正成兩種版本。 ## 6.1 Capacity Gap $$ \boxed{ G_C = V_g - V_T. } $$ 如果： $$ G_C>0, $$ 表示 candidate supply 大於可信吸收能力。 ## 6.2 Ratio $$ \boxed{ \rho_{GG} = \frac{V_g}{V_T+\epsilon}. } $$ 其中： - $\rho_{GG}<1$：治理／吸收能力有餘裕； - $\rho_{GG}\approx1$：接近飽和； - $\rho_{GG}>1$：backlog 持續累積； - $\rho_{GG}\gg1$：大量 candidate 必須被丟棄、延遲或低品質吸收。 --- # 7. Backlog Conservation 令： $$ Q(t) $$ 為尚未被可信吸收的 candidate queue。 則最簡模型： $$ \boxed{ \frac{dQ}{dt} = V_g - V_T. } $$ 若： $$ V_g>V_T $$ 長期成立， 則： $$ Q(t)\uparrow. $$ 系統最終只能做三件事： 1. 增加 $V_T$ ； 2. throttle $V_g$ ； 3. 降低 acceptance / evidence bar。 第三種最危險。 --- # 8. Governance Saturation 當： $$ Q(t) $$ 超過 governance capacity， 組織可能開始： - review 變淺； - test 被跳過； - PR queue 延長； - architecture impact 不再看； - provenance 遺失； - warnings 被大量忽略； - merge criteria 放寬。 因此： $$ \boxed{ \text{GovernanceSaturation} \rightarrow \text{QualityGateDegradation}. } $$ 不是因為團隊突然不專業， 而是 queue 超過 service capacity。 --- # 9. DORA：AI 是 Amplifier DORA 2025 State of AI-assisted Software Development 的核心 framing 是： # **AI as an Amplifier** AI 不會自動把弱 delivery system 變成熟。 它更接近： $$ \boxed{ \text{ExistingSystem} \times \text{AIAcceleration}. } $$ 如果： - version control； - platform； - feedback loops； - team alignment； - delivery practice； 本來成熟， AI 可以放大好處。 如果本來存在： - large batch； - weak feedback； - poor internal platform； - unclear process； - unstable delivery； AI 也會放大 problem surface。 因此： $$ \boxed{ \text{AI} \neq \text{AutomaticGovernanceLayer}. } $$ --- # 10. 2026 DORA：Creation 的時間省下來，常被 Verification 吃掉 DORA 2026〈Balancing AI tensions〉指出： > AI 確實加速 initial code generation，降低 task-start friction，但 creation 節省的時間常被重新投入 auditing 與 verification。 這非常接近本文的核心： $$ W_{\mathrm{creation}}\downarrow $$ 但： $$ W_{\mathrm{verification}}\uparrow. $$ 因此： $$ \boxed{ \text{Less Creation Cost} \neq \text{Equal Reduction in Total Engineering Cost}. } $$ --- # 11. Tokenmaxxing：生成活動量可以成為新的假生產力 DORA 在 2026 年又專門討論： # Tokenmaxxing 即組織用 token usage leaderboard 促進 AI adoption。 其核心警告是： > raw token consumption 是 input / activity metric，而不是 outcome metric。 所以： $$ \boxed{ \text{TokensConsumed} \neq \text{SoftwareValueCreated}. } $$ 甚至： $$ \text{Tokens}\uparrow $$ 可能只表示： - more agent loops； - more speculative generation； - more abandoned candidates； - more duplicated implementation； - more review burden。 這與本文的生成—治理缺口形成直接對照。 --- # 12. Activity Metric Goodhartization 若組織獎勵： $$ \text{TokenCount}, $$ 則 Agent / developer 會自然優化： $$ \text{TokenCount}. $$ 若獎勵： $$ \text{PRCount}, $$ 會優化： $$ \text{PRCount}. $$ 若獎勵： $$ \text{GeneratedLOC}, $$ 會優化： $$ \text{GeneratedLOC}. $$ 但真正需要的是： $$ \boxed{ \text{TrustedStateTransition}. } $$ 因此： $$ \boxed{ \text{Generation Activity} } $$ 不應成為： $$ \boxed{ \text{Primary Productivity Target}. } $$ --- # 13. Review Effort 已經成為可預測資源 2026 年一項針對 AI-generated PR 的研究分析： $$ 33,707 $$ 個 agent-authored PR， 來自： $$ 2,807 $$ 個 repositories。 研究觀察到兩個 regime： 1. 約 28.3% PR 幾乎瞬間 merge； 2. 其餘一部分進入 iterative review cycle，甚至 stall / abandon。 研究建立 structural triage model， 在其實驗中： $$ 20\% $$ review budget 可以攔截： $$ 69\% $$ 總 review effort。 這個數字不能直接外推所有 repository， 但它證明一件很重要的事： $$ \boxed{ \text{Review Load} } $$ 本身可以被： - modeling； - prediction； - routing； - budget allocation。 所以 governance 不是「人類最後看一下」。 它是一個正式 capacity system。 --- # 14. Review Agent 也不是免費 Governance 2026 年另一項 empirical study 分析 code review agents。 在其樣本中，CRA-only reviewed PR 的 merge rate 低於 human-only review group，且被分析的 closed CRA-only PR 中，大量 feedback 落在低 signal-to-noise range。 這不能推出： > AI reviewer 沒用。 它反而支持： $$ \boxed{ \text{Automating Review} \neq \text{Automatically Increasing Trusted Review Throughput}. } $$ 如果 AI reviewer 本身產生大量 noise， 則： $$ V_{\mathrm{review\ messages}}\uparrow $$ 但： $$ V_{\mathrm{useful\ review}}\not\uparrow. $$ --- # 15. Governance Throughput 要算 Signal，不是 Message 因此： $$ N_{\mathrm{review\ comments}} $$ 不是 governance throughput。 更合理的是： $$ \boxed{ V_{\mathrm{useful\ governance}} = \frac{ N_{\mathrm{decision\ relevant\ verified\ findings}} }{ \Delta t }. } $$ 同理： $$ \text{TestCount} $$ 不是 verification throughput。 而是： $$ \boxed{ N_{\mathrm{material\ claims\ closed\ by\ evidence}}. } $$ --- # 16. AI-generated Code 的品質不是單向結論 本文避免： $$ \text{AI Code} = \text{BadCode}. $$ 2025–2026 的研究結果高度混合。 例如一項比較 LLM 與 human-written code 的研究，在特定 Python coding-task dataset 與 SonarQube 指標下，觀察到 LLM-generated code 在部分 bug / repair-effort 指標上較好，但高難度題可能出現 human baseline 沒有的 structural issues。 另一項超過 500,000 code samples 的研究則觀察到： - AI code 結構通常較簡單； - repetition 較多； - unused constructs / hardcoded debugging 較多； - human code 結構複雜度較高； - maintainability issue profile 不同； - AI samples 中觀察到更多 high-risk security vulnerabilities。 因此： $$ \boxed{ \text{AI DefectProfile} \neq \text{Human DefectProfile}. } $$ --- # 17. 非功能品質是 Green Closure 的重要盲區 2025 年一項研究綜合： - 108 篇文獻； - industry workshops； - real-world issue patching experiments； 指出 LLM code evaluation 長期過度集中： > tests 是否通過。 但 functional pass 並不能代表： - security； - maintainability； - performance； - reliability； 同步成立。 研究中也觀察到： > 改善一個 non-functional dimension 有時會傷害另一個。 因此： $$ \boxed{ \text{FunctionalGreen} \nRightarrow \text{QualityClosure}. } $$ 這直接與 A01 / A03 相接。 --- # 18. 真實 Repository 中的 AI Issue 可以持續存在 2026 年〈Debt Behind the AI Boom〉分析： $$ 304,362 $$ 個 verified AI-authored commits， 來自： $$ 6,275 $$ 個 GitHub repositories， 識別： $$ 484,606 $$ 個 distinct issues。 其中： $$ 89.1\% $$ 是 code smells。 研究並追蹤 issue 到 repository 最新 revision， 觀察到： $$ 24.2\% $$ 仍然存在。 這是一篇近期 empirical preprint，因此不能被解讀成： > 24.2% 所有 AI code 都是 technical debt。 合理的結論是： $$ \boxed{ \text{AIIntroducedIssue} } $$ 並不必然在後續 review / maintenance 中自動消失。 --- # 19. Vendor Observational Signal：Maintainability Gap GitClear 2025 / 2026 發表大型 observational code-change analysis。 其 2026 報告聲稱分析： $$ 623\text{ million} $$ changes， 並在 2023–2026 window 中觀察到： - refactoring / moved code activity 下降； - legacy maintenance 下降； - duplication / copy-paste 上升； - error-masking constructs 上升； - short-term churn 上升。 這是**供應商自有度量與 observational dataset**， 因此不能作為： $$ \text{AI causes technical debt} $$ 的因果證明。 但它提供一個值得治理系統持續監測的 signal： $$ \boxed{ \text{Throughput}\uparrow } $$ 可能同時伴隨： $$ \boxed{ \text{StructuralMaintenanceSignals}\downarrow. } $$ --- # 20. AI Authorship 不等於 Technical Debt 技術債需要： $$ \boxed{ \text{FutureCostRelation}. } $$ 所以： $$ \text{AIAuthorship} \nRightarrow \text{TechnicalDebt}. $$ 同樣： $$ \text{HumanAuthorship} \nRightarrow \text{GoodArchitecture}. $$ 本文使用「AI 原生結構負擔」是因為： > AI 改變負擔的生成速度、分布、可見性與治理需求。 不是因為： > AI 寫的東西天生比較差。 --- # 21. Verification Debt 若： $$ V_g>V_v, $$ 則未充分驗證變更 queue： $$ Q_v(t) $$ 滿足： $$ \frac{dQ_v}{dt}>0. $$ 本文稱： # Verification Debt 它本身不一定已經成為傳統 technical debt。 但若： $$ Q_v $$ 中的 change 被： - merge； - deploy； - downstream depend； 就可能轉成真正 future-cost-bearing debt。 --- # 22. Verification Debt 與 A05 不同 A05 的問題是： $$ \text{too many obligations}. $$ A06 的 Verification Debt 是： $$ \text{too many changes awaiting trustworthy evidence}. $$ 兩者可以互相放大： $$ \text{CandidateChanges}\uparrow $$ 造成： $$ \text{VerificationQueue}\uparrow. $$ 而 reviewer 再產生： $$ \text{ObligationExpansion}\uparrow. $$ 於是： $$ \boxed{ \text{GenerationBacklog} + \text{ObligationBacklog} } $$ 形成雙重擁塞。 --- # 23. Context Debt Agent 生成時通常只看到： $$ K_{\mathrm{available}} $$ 而完成正確變更真正需要： $$ K_{\mathrm{required}}. $$ 因此： $$ \boxed{ D_c = K_{\mathrm{required}} - K_{\mathrm{available}}. } $$ 這就是 Context Debt。 它可以包括缺失的： - historical reason； - hidden dependency； - incident history； - external consumer； - manual workflow； - runtime behavior； - compatibility contract。 結果是： $$ \text{LocallyCorrect} $$ 但： $$ \text{GloballyMisaligned}. $$ --- # 24. Context Debt 是治理負擔，不只是 hallucination 如果 architectural truth 只存在： > 某位資深工程師記憶裡， 那新人也會犯錯。 因此 Context Debt 更接近： $$ \boxed{ \text{Unexternalized Effective Knowledge}. } $$ AI 只是因為： $$ V_g\uparrow $$ 讓這個缺口被更高頻觸發。 --- # 25. Provenance Debt 若大量 artifact 無法回答： - why changed； - requirement ref； - agent / human actor； - context snapshot； - validation evidence； - model / tool version； - review / authority； - parent state； 則： $$ D_p\uparrow. $$ 這會提高： $$ C_{\mathrm{future\ understanding}} $$ 與： $$ C_{\mathrm{incident\ reconstruction}}. $$ 因此： $$ \boxed{ \text{ProvenanceDebt} } $$ 具有很強的 technical-debt 性質。 --- # 26. Provenance 不等於把所有 Chat 全存下來 真正 provenance 需要： $$ \boxed{ \text{salient causal receipt}. } $$ 不是： $$ \boxed{ \text{all tokens ever generated}. } $$ 理想記錄： ```yaml change: intent_ref: requirement_ref: parent_version: author_agent: model/tool: context_refs: files_changed: tests: structural_impact: authority: accepted_by: ``` 而不是： ```text full 400k-token transcript ``` --- # 27. Specification Debt AI 降低 implementation 成本後， underspecification 會變得更危險。 因為： ```text 做一個登入系統 ``` 就可以快速展開成： - frontend； - backend； - DB； - session； - recovery； - email； - auth logic。 但真正未定義： - authority； - state semantics； - threat boundary； - failure； - recovery； - data ownership； - lifecycle； - acceptance criteria。 因此： $$ \boxed{ C_{\mathrm{implementation}}\downarrow } $$ 可能暴露： $$ \boxed{ D_s\uparrow. } $$ 不是 spec 真的變少， 而是 implementation 跑得比 spec closure 更快。 --- # 28. Integration Debt AI 可以獨立生成： $$ A,B,C,\ldots,N. $$ 每個 component 都： $$ \text{LocalPass}=1. $$ 但 integration surface： $$ E $$ 可能隨 component 增加更快增長。 最壞情況 pairwise： $$ |E|=O(n^2). $$ 所以： $$ \boxed{ \text{ComponentGeneration} } $$ 可以快速超過： $$ \boxed{ \text{RelationClosure}. } $$ 這就是 A03 的吞吐量版本。 --- # 29. Integration Debt 的核心不是 Merge Conflict Integration debt 不只： ```text Git conflict ``` 而包括： - contract mismatch； - retry mismatch； - transaction mismatch； - permission mismatch； - state ownership mismatch； - observability gap； - version skew； - deployment dependency； - timing mismatch。 也就是： $$ \boxed{ \text{Unclosed Effective Boundaries}. } $$ --- # 30. Orchestration Debt Agentic workflow 引入： - planner； - implementer； - reviewer； - test agent； - security agent； - deploy agent； - memory agent。 如果： - responsibility overlap； - context inconsistent； - authority unclear； - retry semantics differ； - completion definition differs； - ownership unclear； 則： $$ C_{\mathrm{coordination}}\uparrow. $$ 這就是： # Orchestration Debt Agent 越多不一定： $$ V_T\uparrow. $$ 甚至可能： $$ V_g\uparrow, \qquad V_{gov}\downarrow. $$ --- # 31. Supervision Debt 如果 AI generation capacity： $$ 10\times $$ 而 trusted review capacity： $$ 1.5\times, $$ 則： $$ Q_{\mathrm{review}}\uparrow. $$ 結果可能： 1. merge queue 變長； 2. reviewer fatigue； 3. review depth 下降； 4. AI review 取代 human review，但 signal quality 不足； 5. low-risk / high-risk change 沒有 routing。 這就是： $$ \boxed{ \text{SupervisionDebt}. } $$ --- # 32. Elimination Debt v0.2 新增： # Elimination Debt AI 讓： $$ C_{\mathrm{add}}\downarrow. $$ 但刪除成熟 code 需要： - dependency analysis； - compatibility check； - migration； - replay； - deprecation； - user impact； - rollback。 因此： $$ C_{\mathrm{delete}} $$ 不一定同比下降。 所以： $$ \frac{ C_{\mathrm{delete}} }{ C_{\mathrm{add}} } \uparrow. $$ 結果組織偏向： ```text don't remove old → add new → add adapter ``` 形成： $$ \boxed{ \text{EliminationDebt}. } $$ --- # 33. 沉積偏差 當： $$ C_{\mathrm{addition}} \ll C_{\mathrm{removal\ verification}}, $$ 最便宜策略是： $$ \boxed{ \text{Add, don't consolidate.} } $$ 因此： $$ |\text{Artifacts}(t)|\uparrow $$ 且： $$ \text{HistoricalResidue}\uparrow. $$ 這是 AI 時代很重要的非對稱。 --- # 34. AI 越會生成，越需要 Garbage Collection 如果： $$ \text{Generation} $$ 是 memory allocation， 則成熟 AI-native engineering 還需要： $$ \boxed{ \text{Structural Garbage Collection}. } $$ 包括： - duplicate detection； - dead artifact detection； - obsolete adapter removal； - deprecated path cleanup； - consolidation； - migration completion； - compatibility retirement。 否則系統只會： $$ \text{Allocate} $$ 不會： $$ \text{Collect}. $$ --- # 35. Observability Debt v0.2 再新增： # Observability Debt 如果 AI change speed 上升， 但： - traces； - metrics； - state introspection； - change lineage； - runtime evidence； 沒有同步提高， 則： $$ \boxed{ V_{\mathrm{change}}\uparrow \quad \land \quad Visibility(\Delta X)\downarrow. } $$ 此時 incident response 會更依賴猜測。 所以 observability 是 governance capacity 的一部分。 --- # 36. Closure Debt A01–A05 已指出： - tests pass 不等於 intent closed； - local pass 不等於 global pass； - finding 不等於 obligation； - process 不等於 progress。 若大量 change 處於： ```text implemented but not semantically closed ``` 則形成： # Closure Debt 形式上： $$ D_{cl} = N_{\mathrm{implemented}} - N_{\mathrm{intent\ closed}}. $$ 這比 Verification Debt 更高階。 --- # 37. Substrate Compensation Burden 若目前 technology substrate 不提供某種 required guarantee， 系統可能反覆加入： - wrapper； - validator； - retry； - runtime guard； - extra reviewer； - compatibility layer。 這些都可以局部有效。 但若： $$ C_{\mathrm{compensation}} $$ 持續上升， 則真正問題可能位於： $$ \boxed{ \text{Substrate}. } $$ 因此 Global-First v2.1 提出： $$ \text{Instance} \rightarrow \text{Pattern} \rightarrow \text{Architecture} \rightarrow \text{Substrate}. $$ 重複 structural defect 應提高 diagnostic level， 而不是： > 再多派一個 reviewer。 --- # 38. Stay Cost / Move Cost 定義： $$ C_{\mathrm{stay}} = C_{\mathrm{implementation}} + C_{\mathrm{recurring\ compensation}} + C_{\mathrm{verification}} + C_{\mathrm{retry}} + C_{\mathrm{integration}} + C_{\mathrm{review}} + C_{\mathrm{expected\ failure}}. $$ 另一方案： $$ C_{\mathrm{move}} = C_{\mathrm{migration}} + C_{\mathrm{adaptation}} + C_{\mathrm{new\ integration}} + C_{\mathrm{new\ verification}} + C_{\mathrm{ecosystem\ transition}}. $$ 如果： $$ C_{\mathrm{stay}} > C_{\mathrm{move}} $$ 且 remaining lifecycle 足夠長， 就應重新評估。 不是因為： > 新語言比較漂亮。 而是因為： > governance cost 已在替 substrate 的缺失保證付租金。 --- # 39. AI-native Structural Burden Vector v0.2 本文將負擔向量擴充： $$ \boxed{ \mathbf B_{AI} = [ D_v, D_c, D_p, D_s, D_i, D_o, D_{sup}, D_e, D_{obs}, D_{cl}, D_{sub} ] } $$ 其中： - $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； - $D_e$：Elimination Debt； - $D_{obs}$：Observability Debt； - $D_{cl}$：Closure Debt； - $D_{sub}$：Substrate Compensation Burden。 --- # 40. 這些 Debt 不是互斥類別 一個 change 可以同時： $$ D_c>0, $$ $$ D_p>0, $$ $$ D_i>0. $$ 例如 Agent 不知道歷史 contract： $$ \text{ContextDebt} $$ 產生新 adapter： $$ \text{IntegrationDebt} $$ 又沒留下 rationale： $$ \text{ProvenanceDebt}. $$ 所以： $$ \boxed{ \mathbf B_{AI} } $$ 是多維狀態，不是單一 label。 --- # 41. Debt 會互相轉換 可能有： $$ D_c \rightarrow D_i, $$ $$ D_s \rightarrow D_v, $$ $$ D_o \rightarrow D_{sup}, $$ $$ D_e \rightarrow D_i, $$ $$ D_{obs} \rightarrow D_{sup}, $$ $$ D_v \rightarrow D_t. $$ 其中： $$ D_t $$ 代表傳統 technical debt / future maintenance cost。 所以 AI-native burden 是： $$ \boxed{ \text{Pre-Debt and Debt-Flow System}. } $$ --- # 42. AI 可以加速 Compensation Solidification 以前 workaround 變成 architecture 可能需要數月。 現在 Agent 可以快速： ```text script → service → API → UI → database → deploy ``` 幾天內完成。 如果 downstream 立刻依賴： $$ Dependents\uparrow, $$ 則： $$ T_{\mathrm{solidification}}\downarrow. $$ 因此 AI 可以加速： # Architectural Solidification 壞處是： > 臨時東西更快變成不能拆的東西。 好處是： > 健康 primitive 也可以更快被制度化。 關鍵仍是 governance。 --- # 43. AI 也可以提高 Governance Throughput 這篇不能把 AI 固定放在 numerator。 AI 也可以做： - architecture recovery； - dependency graph； - impact analysis； - test generation； - invariant check； - provenance generation； - doc sync； - observability analysis； - deprecation detection； - duplicate detection； - migration planning； - runtime anomaly triage。 所以： $$ V_{gov}^{AI}\uparrow $$ 完全可能。 --- # 44. Agentic Refactoring 是重要反例 2025 年 Agentic Refactoring 研究分析： $$ 15,451 $$ 個 agent-generated refactoring instances， 跨： $$ 12,256 $$ 個 PR。 研究發現： - refactoring 並不少見； - 26.1% commits 明確以 refactoring 為目的； - maintainability / readability 是主要動機； - 部分 structural metric 有小幅但顯著改善。 因此： $$ \boxed{ AI \neq \text{OnlyGenerationAccelerator}. } $$ AI 也可以： $$ \boxed{ \text{GovernanceAccelerator}. } $$ --- # 45. 但 Refactoring Throughput 也需要 Closure AI refactor： $$ RefactorGenerated=1 $$ 仍不表示： $$ RefactorAccepted=1. $$ 需要驗： - behavior preservation； - architecture impact； - tests； - compatibility； - performance； - runtime。 因此 governance automation 本身也需要 governance。 這是 recursive governance 問題。 --- # 46. AI 在分子還是分母？ 生成—治理比率： $$ \rho_{GG} = \frac{V_g}{V_T}. $$ 如果 AI 只用在： $$ V_g\uparrow, $$ 則： $$ \rho_{GG}\uparrow. $$ 如果 AI 同時提高： $$ V_v, V_i, V_a, V_{gov}, $$ 則： $$ V_T\uparrow $$ 可能讓： $$ \rho_{GG}\downarrow. $$ 所以： $$ \boxed{ \text{AI is not inherently numerator or denominator.} } $$ --- # 47. Trusted Integration Throughput 本文把舊文的： # Trusted Integration Throughput 正式化成： $$ \boxed{ V_{TI} = \frac{ N_{\mathrm{changes}} [ \text{Verified} \land \text{Integrated} \land \text{Governed} ] }{ \Delta t }. } $$ 若再加入： $$ \text{Reversible} $$ 與： $$ \text{RuntimeObserved}, $$ 則得到更強版本。 --- # 48. Verified, Governed, Reversible State Transition 令一個 change： $$ \tau: W_t\rightarrow W_{t+1}. $$ 可信 transition 至少滿足： $$ Verified(\tau)=1, $$ $$ Integrated(\tau)=1, $$ $$ Governed(\tau)=1, $$ 且高風險變更需要： $$ ReversibleOrExplicitlyAuthorized(\tau)=1. $$ 因此： $$ \boxed{ VGRT(\tau)=1. } $$ 其中： # VGRT ## Verified, Governed, Reversible Transition --- # 49. 核心產能指標 定義： $$ \boxed{ \Theta_{VGRT} = \frac{ N_{VGRT} }{ \Delta t }. } $$ 這就是： # Verified, Governed, Reversible State Transitions per Unit Time 比： $$ LOC/day $$ 更接近真實 AI-native engineering productivity。 --- # 50. 為什麼不只用 Tasks Completed？ 因為兩個「task completed」可以具有完全不同： - scope； - risk； - change radius； - integration surface； - evidence quality； - reversibility。 所以： $$ \text{TaskCount} $$ 仍然太粗。 狀態轉換至少要求： $$ \text{what changed} $$ 可被明確表達。 --- # 51. Architecture Transaction 本文沿用既有概念： > AI 生成的不是 code，而是一個有來源、有證據、有結構影響的 architecture transaction。 可表示： ```yaml change: intent: parent_state: actor: context: artifact_diff: dependency_diff: authority_diff: state_ownership_diff: tests: runtime_evidence: structural_review: provenance: rollback: acceptance: ``` 這樣： $$ \Delta X $$ 才可治理。 --- # 52. AI Change Budget 如果： $$ V_g $$ 可近乎無限擴張， 但： $$ V_T $$ 有限， 則成熟組織可以設定： # AI Change Budget 要求： $$ \boxed{ V_{\mathrm{accepted}} \le V_{\mathrm{trusted\ absorption}}. } $$ 這不是： > 限制 AI。 而是： > 不讓 ingestion rate 永遠高於 absorption capacity。 --- # 53. Change Budget 類似 SRE Error Budget，但不是同一概念 SRE error budget 管： $$ \text{AvailabilityRisk}. $$ AI Change Budget 管： $$ \boxed{ \text{ChangeAbsorptionRisk}. } $$ 其 budget 可以由： - review capacity； - test capacity； - incident capacity； - architecture capacity； - release stability； - rollback readiness； 動態決定。 --- # 54. Adaptive Change Budget 可寫： $$ B_{\mathrm{change}}^\ast = f( V_v, V_i, V_a, V_{gov}, \text{Risk}, \text{Stability}, \text{Backlog} ). $$ 當： $$ Q_v,Q_i,Q_{sup} $$ 上升， budget 應下降。 當 governance automation 改善： $$ V_T\uparrow, $$ budget 可以提高。 --- # 55. Circuit Breaker 當： $$ \rho_{GG} $$ 超過閾值： $$ \rho_{crit}, $$ 可以觸發： ```text pause low-priority generation prioritize backlog closure increase targeted verification cluster repeated defects consolidate duplicates recover architecture ``` 這是一種： # Governance Circuit Breaker 不是 failure punishment。 而是 capacity protection。 --- # 56. Queue Prioritization 不是所有 candidate 都值得同樣 governance cost。 可依： $$ Priority(\Delta X) = f( \text{Value}, \text{Risk}, \text{Urgency}, \text{DependencyCentrality}, \text{Reversibility}, \text{EvidenceGap} ). $$ 高價值低風險： $$ \text{fast lane}. $$ 高風險： $$ \text{deep gate}. $$ 低價值高 review cost： $$ \text{drop / defer}. $$ --- # 57. 33,707 AI PR 研究對本文的啟示 review effort 高度不均勻意味： $$ \boxed{ \text{Uniform Review Policy} } $$ 可能很浪費。 如果 structural feature 能在 PR creation 時預測： $$ \text{HighReviewCost}, $$ 則： $$ \boxed{ \text{Risk/Cost Routed Governance} } $$ 比： $$ \text{ReviewEverythingEqually} $$ 更合理。 --- # 58. Review Budget 也應 APR 化 這與 APR 的： $$ \text{Minimum Necessary Observation} $$ 同型。 Review 也可以問： > 為了決定這個 change 是否可接受，最少需要什麼 evidence？ 所以： $$ \boxed{ \text{Minimum Sufficient Governance} } $$ 不是最少治理， 而是： > 足以支持當前 consequential decision 的最小治理集合。 --- # 59. Generation / Governance 的雙向調度 成熟 runtime 不只： $$ Generation\rightarrow Governance. $$ 還需要： $$ GovernanceState\rightarrow GenerationPolicy. $$ 例如 backlog 高： $$ Q_v\uparrow $$ 則 generation policy： $$ \pi_g $$ 轉向： - fix existing； - consolidate； - refactor； - document； - test； - remove； - migrate。 而不是繼續： > new feature generation。 --- # 60. Structural Metabolism 本文提出： $$ \boxed{ \text{SoftwareEvolution} = \text{Creation} + \text{Assimilation} + \text{Repair} + \text{Removal}. } $$ 這像結構代謝。 如果只提高： $$ \text{Creation}, $$ 系統會肥大。 如果： $$ \text{Assimilation}, \text{Repair}, \text{Removal} $$ 同步提高， 系統才是真正： $$ \boxed{ \text{Evolving}. } $$ --- # 61. Metabolic Balance 定義： $$ V_{create}, V_{assimilate}, V_{repair}, V_{remove}. $$ 可建立概念性平衡： $$ \boxed{ M_B = \frac{ V_{assimilate}+V_{repair}+V_{remove} }{ V_{create}+\epsilon }. } $$ 若： $$ M_B\ll1, $$ 表示偏生成。 若： $$ M_B\approx1, $$ 表示結構代謝較平衡。 --- # 62. AI-native Big Ball of Mud 形成路徑 可能是： ```text intent → agent solution → local tests pass → merge → next agent sees local state → new local solution → local tests pass → adapter → duplicated state → more hidden dependencies → more local repair ``` 最終： $$ \boxed{ \text{LocalCorrectness} + \text{HighChangeVelocity} \rightarrow \text{GlobalStructuralDrift}. } $$ 這就是 A01 / A03 / A06 的合流。 --- # 63. Green Closure 與 Generation–Governance Gap 的關係 如果 governance throughput 不足， 系統很自然會選便宜 validator： - unit test； - lint； - CI； - local snapshot。 於是： $$ V_{\mathrm{green}} $$ 可以保持很高， 但： $$ V_{\mathrm{global\ closure}} $$ 跟不上。 因此： $$ \boxed{ \text{GenerationGovernanceGap} \rightarrow \text{PressureTowardCheapGreenSignals}. } $$ 這是一個非常重要的因果橋。 --- # 64. 為什麼「全部加更多 tests」不是完整答案 如果： $$ V_g>V_v, $$ 第一反應可能： > generate more tests。 AI 確實可以提高 test generation。 但如果 tests： - 同一 projection； - 同一 spec； - 同一 fixtures； - 同一 model blind spot； 則： $$ TestCount\uparrow $$ 但： $$ \text{IndependentEvidence}\uparrow $$ 有限。 這會接到 A08： # Homogeneous Green --- # 65. Structural Verification 因此治理層除了 functional tests， 還需要按 change class 選： - dependency diff； - state ownership； - authority change； - lifecycle； - runtime； - visual / interaction； - performance； - compatibility； - architecture residual。 不是每次全部開。 而是： $$ \boxed{ Risk\text{-} and\ Causal\text{-}Routed\ Structural\ Verification. } $$ --- # 66. Architecture Review Frequency 可以被 AI 提高 以前 architecture review： $$ C_a $$ 太高， 所以可能： ```text quarterly ``` 或： ```text incident-driven ``` 未來 Agent 可以每個 PR： - recover dependency； - compare declared / effective； - inspect structural delta； - detect ownership drift； - query historical rationale。 因此： $$ f_{\mathrm{architecture\ review}} \uparrow. $$ 如果品質足夠， 甚至接近： $$ f_{\mathrm{change}}. $$ 這正是 AI 提高 denominator 的例子。 --- # 67. 但 Architecture Review 也需要 Stop Discipline A05 已證明： $$ \text{Review} $$ 不能成為 infinite obligation generator。 所以： $$ V_a\uparrow $$ 不應靠： > 每個 PR 寫更多 architecture comments。 而應靠： $$ \boxed{ \text{Higher signal / lower cost structural judgment}. } $$ --- # 68. Provenance Automation Provenance 是很適合 AI 自動化的治理項。 因為： - task ref； - diff； - tests； - model； - tool； - branch； - timestamp； - dependency impact； 大多可以機械取得。 所以： $$ C_p\downarrow $$ 可以顯著提高： $$ V_{gov}. $$ 這類 automation 比： > 再產生一段 free-form review prose 更可能提高 trusted throughput。 --- # 69. Deterministic Evidence Preference 對可機械驗證的東西： $$ \text{Compiler}, \text{Schema}, \text{Hash}, \text{ExactDiff}, \text{UnitTest}, \text{IntegrationTest}, \text{StaticInvariant} $$ 應優先於： $$ \text{another LLM opinion}. $$ 原因不是 LLM reviewer 沒價值。 而是： $$ \boxed{ \text{DeterministicEvidence} } $$ 通常： - 成本較低； - reproducible； - lower correlation； - easier caching； - easier closure memory。 --- # 70. Governance Cache 如果同一 artifact / state： $$ X_v $$ 已經有有效 evidence： $$ E(X_v), $$ 那麼沒有 relevant change 時： $$ E(X_v) $$ 應可重用。 不需要： $$ \text{ReviewEverythingAgain}. $$ 因此： # Governance Cache 可提高： $$ V_T. $$ --- # 71. Evidence Invalidation Governance cache 不能永遠有效。 若 change： $$ \Delta X $$ 影響： $$ Cone(E_i), $$ 則： $$ Invalidate(E_i)=1. $$ 所以： $$ \boxed{ \text{Cache} + \text{Causal Invalidation} } $$ 比： $$ \text{Always Reverify All} $$ 更 scalable。 --- # 72. Backlog 分層 不要只有： ```text PR queue ``` 而應分： ```text candidate verification integration architecture governance release ``` 才能知道 bottleneck 位於哪。 例如： $$ Q_g=0, Q_v=500, Q_i=20. $$ 真正問題顯然不是： > 產碼不夠快。 --- # 73. Little's Law 視角 對穩定 queue： $$ L=\lambda W. $$ 因此 backlog： $$ L $$ 上升可能來自： - arrival rate $\lambda$ 上升； - waiting time $W$ 上升。 AI 最直接提高： $$ \lambda_g. $$ 如果 service rate 不變， 則： $$ W_{\mathrm{review}}\uparrow. $$ 這提供一個非常直觀的工程量化框架。 --- # 74. Governance Lead Time 可以測： $$ T_{gov} = t_{\mathrm{accepted}} - t_{\mathrm{candidate}}. $$ 如果 AI 後： $$ T_{\mathrm{coding}}\downarrow $$ 但： $$ T_{gov}\uparrow, $$ 那 end-to-end lead time 未必改善。 因此： $$ \boxed{ \text{CodingLatency} \neq \text{DeliveryLatency}. } $$ --- # 75. Candidate Rejection Rate 如果 candidate generation 很便宜， 高 rejection rate 本身不一定壞。 定義： $$ R_c = \frac{ N_{\mathrm{rejected\ candidates}} }{ N_{\mathrm{generated\ candidates}} }. $$ 只要： $$ C_g $$ 很低， 探索性 generation 可以合理。 真正問題是： $$ \boxed{ \text{RejectedCandidateCost} + \text{GovernanceCost}. } $$ 如果每個垃圾 candidate 都耗大量 review， 則不值得。 --- # 76. Governance-Adjusted Candidate Value 可定義： $$ \boxed{ V_c^\ast = ExpectedValue(c) - ExpectedGovernanceCost(c) - ExpectedIntegrationCost(c). } $$ 只有： $$ V_c^\ast>0 $$ 的 candidate 才值得深入。 這可降低： $$ Q. $$ --- # 77. Agent 不該把所有想法都變 PR 候選方案可以先存在： $$ \text{cheap latent space}. $$ 不一定立刻： - edit repo； - open PR； - trigger full CI； - trigger reviewers。 因此： $$ \boxed{ \text{Idea} \neq \text{RepositoryMutation}. } $$ 這也是 governance cost control。 --- # 78. Proposal Layer 可以有： ```text hypothesis → candidate plan → cheap static evaluation → selected candidate → repo mutation ``` 而不是： ```text every idea → code → PR → CI → review ``` 這能把 expensive governance 放到後面。 --- # 79. Global-First 對 Generation–Governance Gap 的意義 Global-First Completion 並不是： > 先生成更多。 它真正的優勢是： $$ \boxed{ \text{reduce repeated local validation and integration rediscovery}. } $$ 例如： ```text global implementation → first global validation → failure clustering → batched repair ``` 比： ```text tiny edit → full validation → tiny edit → full validation ``` 降低： $$ C_v. $$ 因此提高： $$ V_T. $$ --- # 80. A06 與 A04 的區別 A04： $$ \boxed{ \text{Process Activity} \neq \text{Mission Progress}. } $$ A06： $$ \boxed{ \text{Generation Throughput} \neq \text{Trusted Absorption Throughput}. } $$ A04 主要研究： > 流程是否在浪費。 A06 研究： > 即使所有流程都有必要，capacity 是否跟得上生成速度。 --- # 81. A06 與 A05 的區別 A05： $$ \lambda_{\mathrm{obligation}} > \mu_{\mathrm{closure}} $$ 造成 completion drift。 A06： $$ \lambda_{\mathrm{candidate}} > \mu_{\mathrm{trusted\ absorption}} $$ 造成 structural backlog。 所以兩篇形成對偶： $$ \boxed{ \text{Too Many Things To Do} } $$ 與： $$ \boxed{ \text{Too Many Things To Trust}. } $$ --- # 82. A06 與 A07 的橋 若 governance capacity 不足， Agent 會依賴： - prior； - local tests； - text-only context； - default role。 所以： $$ \boxed{ \text{CapacityPressure} \rightarrow \text{ObservationNarrowing}. } $$ 這會接到 A07： # Capability–Perspective Activation Gap 即： > 模型可能有能力，但 runtime 沒有啟動該視角／模態。 --- # 83. A06 與 Series B 的橋 第二系列會提出： $$ \text{GlobalAwareness} + \text{DynamicObservation} + APR. $$ 其一個直接經濟理由就是： > governance 不可能對所有 change 永遠使用 maximum observation。 需要： $$ \boxed{ \text{Minimum Sufficient Observation} } $$ 提高： $$ V_T $$ 同時保持： $$ \text{EvidenceQuality}. $$ --- # 84. 治理吞吐量不等於治理步驟越少 提高： $$ V_{gov} $$ 可以靠： 1. automation； 2. better routing； 3. deterministic evidence； 4. causal reuse； 5. architecture memory； 6. stronger observability； 7. better specs； 8. reviewer specialization； 9. elimination / consolidation。 不是單純： > skip review。 --- # 85. Governance Compression 成熟系統追求： $$ \boxed{ \text{Same or Better Assurance} \quad / \quad \text{Lower Governance Cost}. } $$ 可稱： # Governance Compression 例如： - one exact schema validator 取代多輪文字 review； - cached dependency graph 取代每次重新閱讀； - targeted visual replay 取代全站人工巡查； - provenance receipt 取代完整 chat reconstruction。 --- # 86. Trusted Absorption Efficiency 定義： $$ C_{\mathrm{total}} = C_g+C_v+C_i+C_a+C_{gov}. $$ 可信吸收效率： $$ \boxed{ \eta_T = \frac{ N_{\mathrm{trusted\ accepted\ changes}} }{ C_{\mathrm{total}} }. } $$ 這比： $$ \frac{LOC}{Token} $$ 更有工程意義。 --- # 87. Rework-adjusted Throughput 如果 accepted change 很快又被 revert / rewrite， 那 nominal throughput 會高估。 定義： $$ V_T^\ast = V_T ( 1-R_{\mathrm{rework}} ). $$ 因此： $$ \boxed{ \text{Durable Trusted Throughput} } $$ 更值得觀察。 --- # 88. Stability-adjusted Throughput 再加入 escaped incident cost： $$ V_T^{**} = V_T^\ast ( 1-R_{\mathrm{critical\ escape}} ). $$ 這能避免： > 快速 merge 一切 看起來 throughput 很高。 --- # 89. AI Change Health Dashboard 可以監測： ```yaml generation: candidates_per_day: files_changed_per_day: queues: verification: integration: architecture: review: release: throughput: verified: integrated: governed: deployed: quality: rework_rate: rollback_rate: escaped_defects: duplicated_code: churn: burden: context_debt: provenance_debt: integration_debt: supervision_debt: elimination_debt: ratio: generation_governance_ratio: ``` 這比： ```text tokens consumed ``` 更接近治理現實。 --- # 90. 早期警報 以下 signal 出現時： - PR queue 快速上升； - review latency 上升； - review comment noise 上升； - duplicate adapters 上升； - short-term churn 上升； - architecture warnings 長期未處理； - provenance missing； - reopened defects 上升； - same structural failure family 重複； 應判斷： $$ \boxed{ \rho_{GG}>1 } $$ 的可能性。 --- # 91. 反例：High Generation 可以是好事 如果： $$ V_g\uparrow $$ 同時： $$ V_T\uparrow $$ 而且： $$ \rho_{GG}\le1, $$ 則 AI 可以讓： - refactor； - test； - migration； - cleanup； - documentation； - architecture recovery； 都高頻化。 因此本文不是反對： $$ \text{HighGeneration}. $$ 而是反對： $$ \boxed{ \text{UngovernedGeneration}. } $$ --- # 92. 反例：Low Generation 也不等於健康 一個團隊： $$ V_g\downarrow $$ 可能只是： - legacy 太難改； - review 太慢； - fear-driven process； - no automation； - low capability。 所以： $$ \text{LowChangeRate} \nRightarrow \text{GoodGovernance}. $$ 真正目標是： $$ \boxed{ \text{HighTrustedThroughput}. } $$ --- # 93. 反例：Governance 很多也可能是壞事 如果： $$ V_{gov} $$ 用「review steps」計算， 可能被 A04 的 process proxy 騙。 所以治理吞吐量必須用： $$ \boxed{ \text{closed material uncertainty / accepted trusted transitions} } $$ 衡量， 而不是： $$ N_{\mathrm{governance\ actions}}. $$ --- # 94. 核心命題 本文 v0.2 收束為十八條命題。 ## P1 — Candidate-Cost Reduction $$ \boxed{ AI\rightarrow C_{\mathrm{candidate\ generation}}\downarrow. } $$ 這比「AI 一定讓專案變快」更弱也更可靠。 ## P2 — Candidate / Trusted Change Separation $$ \boxed{ \text{CandidateChange} \neq \text{TrustedChange}. } $$ ## P3 — Pipeline Bottleneck $$ \boxed{ V_T = \min(V_g,V_v,V_i,V_a,V_{gov},\ldots). } $$ ## P4 — Generation–Governance Gap $$ \boxed{ G_C=V_g-V_T. } $$ ## P5 — Backlog Accumulation 若： $$ V_g>V_T, $$ 則： $$ \boxed{ \frac{dQ}{dt}>0. } $$ ## P6 — AI Authorship Non-Debt $$ \boxed{ \text{AIAuthorship} \nRightarrow \text{TechnicalDebt}. } $$ ## P7 — Distinct Defect Profile $$ \boxed{ \text{AI RiskProfile} \neq \text{Human RiskProfile}. } $$ ## P8 — Verification Debt $$ \boxed{ V_g>V_v \Rightarrow Q_v\uparrow. } $$ ## P9 — Integration Debt $$ \boxed{ \text{ComponentGeneration} > \text{BoundaryClosure} \Rightarrow \text{IntegrationDebt}\uparrow. } $$ ## P10 — Context Debt $$ \boxed{ D_c = K_{\mathrm{required}} - K_{\mathrm{available}}. } $$ ## P11 — Elimination Asymmetry $$ \boxed{ C_{\mathrm{delete}} / C_{\mathrm{add}} \uparrow } $$ 會增加沉積偏差。 ## P12 — AI Can Increase Governance Too $$ \boxed{ AI \rightarrow V_g\uparrow \quad\text{and/or}\quad V_T\uparrow. } $$ ## P13 — Structural Amplifier $$ \boxed{ AI \approx \text{StructuralAmplifier}. } $$ 它放大的是既有 engineering system。 ## P14 — Activity Non-Productivity $$ \boxed{ \text{Tokens}, LOC, \text{PRCount} \neq \text{TrustedProductivity}. } $$ ## P15 — Trusted State Transition Metric $$ \boxed{ \Theta_{VGRT} = \frac{ \text{Verified}\land\text{Governed}\land\text{Reversible}\ \text{StateTransitions} }{ \text{Time} }. } $$ ## P16 — Change Absorption Budget $$ \boxed{ V_{\mathrm{accepted}} \le V_{\mathrm{trusted\ absorption}}. } $$ ## P17 — Governance Routing $$ \boxed{ \text{GovernanceDepth} = f( \text{Risk}, \text{ChangeRadius}, \text{Uncertainty}, \text{Reversibility}, \text{EvidenceGap} ). } $$ ## P18 — Structural Metabolism $$ \boxed{ \text{HealthyAIEngineering} = \text{Creation} + \text{Assimilation} + \text{Repair} + \text{Removal}. } $$ --- # 95. 結論 AI 時代的軟體工程很容易被一個表面現象欺騙： > AI 寫得越來越快，所以軟體工程也越來越快。 實際上，AI 首先做到的是： $$ \boxed{ \text{Candidate Production}\uparrow. } $$ 但軟體真正能演化，需要： $$ \boxed{ \text{Trusted Absorption}\uparrow. } $$ 如果只有前者： $$ V_g\uparrow $$ 而： $$ V_T $$ 不變， 那麼增加的不是等比例 productivity， 而是： $$ \boxed{ \text{Backlog} + \text{ReviewLoad} + \text{IntegrationSurface} + \text{ContextPressure} + \text{StructuralBurden}. } $$ 因此 AI-native engineering 的真正競爭力，不應是： > 哪個團隊每天產最多 code。 甚至也不只是： > 哪個團隊讓最多 Agent 同時跑。 真正稀缺的能力可能變成： $$ \boxed{ \textbf{ Trusted Change Absorption Capacity } } $$ 也就是： > **一個工程系統每天到底能可靠理解、驗證、整合、治理、部署並在必要時回滾多少有效變更。** 如果這個能力與 generation 一起提高， AI 可以成為： $$ \boxed{ \text{Structural Metabolism Accelerator}. } $$ 它可以讓： - legacy refactor； - architecture recovery； - migration； - cleanup； - observability； - testing； - documentation sync； 第一次高頻發生。 如果只有 generation 提高， AI 就可能成為： $$ \boxed{ \text{Structural Burden Amplifier}. } $$ 所以本篇留下的最終問題不是： > AI 一天可以寫多少 code？ 而是： $$ \boxed{ \textbf{ How many verified, integrated, governed, reversible state transitions can the system safely absorb per unit time? } } $$ 中文即： > **系統每單位時間究竟能安全吸收多少經驗證、經整合、可治理且可回復的真實狀態轉換？** 這才是 AI-native software engineering 更值得追求的產能。 --- # 參考文獻 ## A. 外部研究與最新工程資料 1. DeBellis, D., Storer, K., Harvey, N., Beane, M., Edwards, R., Fraser, E., et al. (2025). *DORA State of AI-assisted Software Development 2025*. Google / DORA. https://dora.dev/research/2025/dora-report/ 核心 framing：AI as an amplifier；AI 效果依賴既有 organizational / delivery system。 2. DORA. (2026-03-10). *Balancing AI tensions: Moving from AI adoption to effective SDLC use*. https://dora.dev/insights/balancing-ai-tensions/ 指出 AI 加速 initial code generation，但 creation 省下的時間經常轉移到 auditing、verification 與 integration。 3. Conaway, E. / DORA. (2026-06-02). *Finding balance in the era of tokenmaxxing*. https://dora.dev/insights/finding-balance-in-the-era-of-tokenmaxxing/ 將 raw token consumption 描述為 activity / vanity metric 風險，主張從 usage 指標轉向 outcome。 4. 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. 304,362 verified AI-authored commits、6,275 GitHub repositories、484,606 distinct static-analysis issues；24.2% tracked introduced issues 在 latest revision 仍存在。屬近期 empirical preprint，本文不將結果外推為所有 AI 工具的固定比例。 5. 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 / arXiv:2508.21634. 超過 500k Python / Java samples，顯示 AI 與 human code 具有不同 defect / vulnerability / complexity profile。 6. Molison, A. S., Moraes, M., Melo, G., Santos, F., & Assuncao, W. K. G. (2025). *Is LLM-Generated Code More Maintainable & Reliable than Human-Written Code?* arXiv:2508.00700. 在特定 coding-task / SonarQube 實驗下部分 LLM code 指標較佳，但複雜問題仍出現 structural risk，支持「品質結果依任務與評估域變動」。 7. Sun, X., Ståhl, D., Sandahl, K., & Kessler, C. (2025). *Quality Assurance of LLM-generated Code: Addressing Non-Functional Quality Characteristics*. arXiv:2511.10271. Systematic review + industry workshops + empirical patch evaluation；指出研究偏重 functional correctness / security，而 industry 更重 maintainability / readability；不同 non-functional quality 間可有 trade-off。 8. Geruslu, V., Aliyeva, Z., & Tüzün, E. (2026). *Factors Influencing the Quality of AI-Generated Code: A Synthesis of Empirical Evidence*. arXiv:2603.25146. Systematic literature review，24 primary studies；品質受 prompt、task specification、developer expertise、model / human interaction 共同影響，未形成單一好壞結論。 9. Minh, D. S. D., Kiet, H. T., Nguyen, T. C., Quy, N. L. P., Pham, P. H., Duong, N. D. H., & Tran, T. B. (2026). *Early-Stage Prediction of Review Effort in AI-Generated Pull Requests*. arXiv:2601.00753. 33,707 agent-authored PRs、2,807 repositories；研究顯示 review effort 可被結構特徵高度預測，在其設定下 20% review budget 可攔截 69% review effort。 10. Chowdhury, K., Banik, D., Ferdous, K. M., & Shamim, S. I. (2026). *From Industry Claims to Empirical Reality: An Empirical Study of Code Review Agents in Pull Requests*. arXiv:2604.03196. 研究 CRA feedback signal / merge outcomes；指出 automated reviewer 產生的 feedback 可能有大量 noise，支持「review automation 也需要 governance」。 11. Ogenrwot, D., & Businge, J. (2026). *How AI Coding Agents Modify Code: A Large-Scale Study of GitHub Pull Requests*. arXiv:2601.17581. 分析 24,014 merged agentic PRs 與 5,081 human PRs，顯示 agent-generated contribution 的 commit / files-touched pattern 與 human contributions 有實質差異。 12. 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. 15,451 refactoring instances、12,256 PRs；顯示 agents 也可以成為 maintainability / refactoring 工具，而非只能製造新 code。 13. GitClear. (2025). *AI Copilot Code Quality: 2025 Look Back at 12 Months of Data*. https://www.gitclear.com/ai_assistant_code_quality_2025_research Vendor observational analysis；本文僅把 duplicate / churn / refactor signal 當作 industry monitoring evidence，不當作 AI causality proof。 14. GitClear / GitKraken. (2026). *The Maintainability Gap: AI Code Quality in 2026*. https://gitkraken.gitclear.com/the_ai_code_quality_maintainability_gap Vendor observational dataset，聲稱分析 623M changes；本文只將其視為 maintainability signal，而非普遍因果結論。 15. Forsgren, N., Storey, M.-A., Maddila, C., Zimmermann, T., Houck, B., & Butler, J. (2021). *The SPACE of Developer Productivity: There’s More to It Than You Think*. ACM Queue. 對單一 activity metric / output metric 衡量 developer productivity 提供成熟外部地基。 ## B. Neo.K / EveMissLab 既有研究 16. Neo.K. 〈AI 寫得越快，屎山會長得越快嗎？AI 原生開發的新技術債〉，《表觀完好系統》10 / 12，2026-08-01. 建立 AI-Native Structural Burden、Generation–Governance Gap、Verification / Context / Provenance / Specification / Integration / Orchestration / Supervision Debt，以及 Verified, Governed, Reversible State Transitions per Unit Time。 17. Neo.K. 〈真正的系統在哪裡？宣告架構與有效架構的分離〉，2026. 建立 Effective Architecture / Effective Dependency，說明 code view 不是完整產品世界。 18. Neo.K. 〈從靜態 MSSP 到動態 MSSP：讓架構角色成為可觀察狀態〉，2026. 建立 Declared / Observed / Effective role separation 與 architecture observation / governance loop。 19. Neo.K. *Global Completion Theory*, 2026. 建立 Global Coverage Precedes Local Perfection、validation proportionality 與 completion / validation separation。 20. Neo.K. *Global-First Completion v2 / v2.1*, 2026. 建立 Instance → Pattern → Architecture → Substrate structural-defect escalation、review scope binding、technology-domain reassessment 與 Completion Supervisor。 21. Neo.K. 〈綠燈錯置——AI 時代「通過驗證」不等於「完成意圖」的新型不對齊〉，A01, 2026. 22. Neo.K. 〈局部正確與全域失敗〉，A03 v0.2, 2026. 23. Neo.K. 〈流程代理錯置〉，A04 v0.2, 2026. 24. Neo.K. 〈驗證義務膨脹與 Completion Drift〉，A05 v0.2, 2026. --- **End of A06 v0.2**