加速鞭梢效應

資料來源#

• 5 takeaways from the State of Software Delivery Q2 Pulse report
• AI accelerates output, not innovation
• AI Engineering Report 2026: The Acceleration Whiplash
• Characterizing the Quality Profile of AI-Generated C++ in Production
• Not All Agents Are Equal: Code Quality and Post-Merge Maintenance Across Five Autonomous Coding Agents in the Wild
• The Speed Trap: 8 takeaways from our latest AI engineering research
• The State of AI Impact in Engineering: Q2 2026
• When Review Alone No Longer Scales: Layered Supervision in AI-Assisted Software Engineering

摘要#

Faros AI《AI Engineering Report 2026》的核心發現（涵蓋 22,000 名開發者、4,000 個團隊的遙測資料，分析截至 2026 年 3 月）：AI 將大量輸出灌入一套以人類開發速度和人類品質程式碼為基礎、從未設計來消化這些輸出的系統。 吞吐量大幅上升，品質卻在下游惡化；而報告最關鍵的主張是，採用越深入，兩者的差距就越大，而非趨於穩定。 Faros 將此命名為加速鞭梢效應：「加速確實存在，但具有欺騙性——它掩蓋了每個下游階段逐漸累積的壓力。」

證據說明。 這是 vendor-claim 來源——Faros 銷售工程情報平台，而報告提出的建議（第 10 項「情境引擎」）也對應到其產品類別。底層資料是真實遙測資料（Spearman ρ、p<0.05、公司內部隨時間比較），因此測量結果屬於實證資料，但資料選取與論述框架服務於商業敘事。以下主張均歸於 Faros，不視為定論。它也直接與DORA 2025 年調查結果矛盾——詳見該頁。

兩個面向，量化呈現#

吞吐量上升（公司內部比較：AI 採用程度低→高）：

• 每位開發者的任務吞吐量 +33.7%；每位開發者完成的 epic +66.2%
• 每個團隊完成的程式碼相關任務 +210%（約為一般任務速率的 6 倍）
• PR 合併率 +16.2%（但低於 Faros 2025 年報告的 +98%——Faros 將這個差距解讀為審查瓶頸正在限制合併速度）
• 每週部署數 −11.7%（資料集的 10%）；程式碼 churn +861%（刪除行數與新增行數的比率）

品質全面下滑，涵蓋每個下游階段：

• 認知負荷（見 AI Brain Fry）：每日 PR 情境／開發者 +67.4%、工作重新開始 +13.8%、進行中任務停滯（7 天以上沒有活動）+26%
• 複雜度／更廣的變更爆炸半徑：PR 平均大小 +51.3%、每個 PR 編輯的檔案數 +59.7%、每位開發者每月觸及的檔案數 +149.9%
• 合併前品質：審查留言 +25%、完全未經審查便合併的 PR +31.3%（「最急迫的發現」）
• 流程：進行中時間 +225.2%、PR 審查中的中位時間 +441.5%、從提交到正式環境的前置時間 +480.4%（資料集的 10%）
• 正式環境：每個 PR 的事件 +242.7%（每次合併發生事件的機率增逾三倍）、每月事件 +57.9%、每位開發者的錯誤 +54%（高於 2025 年的 +9%）、重新開啟的工單 +12.6%

與成熟度無關的發現#

Faros 最引人注目的主張是：無論基準工程成熟度如何，都會出現鞭梢效應。 AI 出現前表現出色的組織——DevOps 成熟度高、DORA 分數高、交付紀律嚴謹——下游惡化程度與其他組織相同。「即使是最穩固的基礎，也正被 AI 生成輸出的雪崩壓垮。」這是明確的實證論點，反駁了 DORA 2025 認為穩固基礎能抵禦 AI 負面影響的結論。

核心論點：問題出在撰寫，而非審查#

報告的重點重新界定了解方。直覺上會想增加審查者、加嚴閘門、延長 QA，但這「只是在處理症狀」。Faros 主張必須從源頭著手，也就是程式碼生成階段：「目標應該是減少送到審查階段的錯誤，而不是派更多人去抓錯。」AI 生成的程式碼表面上很有說服力（符合慣用寫法、命名良好、風格一致），但結構性問題藏在底層，因此會對資深工程師造成不成比例的負擔——只有他們有能力發現意圖層級的錯誤，如今卻耗在拆解那些看似合理、實際上「根本還沒準備好」的程式碼。

這是對驗證成為新瓶頸的一項有用補充：Faros 同意驗證是主要限制，但主張紓解之道是提升撰寫品質（生成時提供更豐富的情境），而非擴大驗證層。其建議的機制——讓代理程式取得程式碼庫標準、架構意圖、安全限制，以及一個根據程式碼庫演進過程而非當前狀態建立的「情境引擎」——就是將持續情境紀律擴大到產業規模的做法。

為何稱為「鞭梢效應」，而非「悖論」#

Faros 2025 年 7 月的報告名為 AI Productivity Paradox（投資增加，交付效益卻未實現）。2026 年報告稱這個悖論「加劇成危機」：採用速度加快，消化能力的落差擴大，吞吐量雖有實質提升，卻集中在前期——這些提升「掩蓋了壓力」，而壓力要到數週至數月後才在下游浮現。鞭梢效應描述的是時間上的結構：快速可見的加速，延遲而不可見的成本。請注意，這只能比較方向——2025 與 2026 年的資料集是彼此獨立的橫斷面資料，並非縱向追蹤樣本。

近期的邊界條件#

Faros 強調，這些數字反映的是 AI 作為主要撰寫工具、而人類仍在迴圈中的情況——代理式撰寫在這份資料集中占 PR 的 <1%（見 AI as Primary Author）。「若讓人類完全退出迴圈，這裡的每項指標都會承受大一個數量級的壓力。這個產業尚未準備好迎接那種轉變。」依 Faros 的說法，這種鞭梢效應還是輕微版本。

分歧的結果：一項由人類控制的正式環境測量結果不一致，但並非各方面都不同（2026-08）#

Tran et al. (Google, arXiv 2608.06640)是本資料庫中第一個能用相同標準與本頁對照的來源：屬於 empirical，而非 vendor-claim；規模達正式環境層級（2025 年 4 月至 2026 年 4 月，共 352 萬筆提交變更）；而且具備 Faros 所缺少的一項條件——人類撰寫的對照組，並依變更大小、月份和組織切片分層呈現結果。

它印證的部分。 審查摩擦確實存在，也支持本頁的論述方向。AI 生成的變更引發的阻擋型審查討論串是人類撰寫變更的 1.92 倍，留言數 1.39 倍、審查者迭代次數 1.24 倍、合併所需時間 1.19 倍。建置失敗約為人類組別的 1.3 倍，sanitizer 發現也約為 1.3 倍，這就是Fung 所說的 CI／建置壅塞的比率化呈現。AI 變更在結構上也符合本頁描述：變更行數中位數為 89 行，相較之下人類為 33 行；觸及 3 個檔案，相較之下人類為 2 個。

與本頁衝突的部分。 本頁最令人警惕的數字都出現在部署後——每位開發者的錯誤 +54%、每個 PR 的事件 +242.7%。Google 的部署後訊號方向相反：還原率約 0.9 倍，低於持平水準。 AI 程式碼通過審查與提交前檢查後，被回滾的可能性比人類程式碼更低。其 Correctness-and-Safety 靜態檢查結果也低於持平水準（0.94 倍），生命週期／所有權風險亦然。超額部分集中在效率與耦合，而非故障。

（以上沒有任何內容取代 Faros 的數據——兩者測量項目不同，均按報告原樣保留。以下是如何權衡。）

如何調和兩者，以及哪些問題仍真正存在爭議。 可比較性的四個面向足以解釋大部分差距：

• 依變項不同。 還原是特定的補救行動；事件是正式環境中發生的狀況。若事件透過向前修正處理，程式碼庫可能同時出現更多事件和更少還原——這正是 Google 所描述的 monorepo 常見做法。
• Faros 這一側沒有對照組。 Faros 比較同一家公司內 AI 採用程度低與高的季度；Google 則在同一時間範圍內比較 AI 撰寫與人類撰寫的程式碼。Faros 的設計無法區分「AI 程式碼品質較差」與「AI 採用最積極的組織也在其他方面有所改變」；Google 的設計能做到，也確實如此。
• 母體成熟度正是爭議所在。 Google 的 monorepo 有集中式審查、成熟的靜態分析和提交前閘門，而論文對其分歧結果的解讀是，這些閘門抓住了致命錯誤。這是直接支持DORA「穩固基礎能保護你」、反對本頁「成熟度無關」主張的一筆資料——而且來自遙測資料而非調查，恰好是 Faros 批評 DORA 時採用的比較軸線。
• 方向一致時的幅度。 Faros 的 PR 審查中位時間是 +441.5%；Google 的合併時間是 +19%。兩者都高於持平水準，但相差一個數量級。母體與單位差異大到彼此都無法推翻對方；但讀者若把 +441.5% 套用到企業 monorepo 情境，也應一併參考 1.19 倍。

權衡。 Google 的證據層級較高（empirical、有控制組、正式環境資料），而且是更直接檢驗「AI 撰寫的程式碼是否更容易出問題」的資料。但其利益衝突方向與 Faros 相反，同樣具有方向性：Google 工程師測量 Google 自家 AI 程式碼工具的輸出，並發布討論，將觀察到的弱點歸因於「歷史沿用的預設系統配置」，而非模型。兩種供應商誘因指向相反方向，其中一方還有對照組。誠實的結論是：關於品質下降的主張，在審查負擔與合併前不穩定性方面仍成立；但若限於審查閘門成熟的組織，部署後穩定性就不如原主張所述。

四分之一後的另一組供應商資料：形狀相同，省下的時間卻不見了（2026-08）#

DX 的 State of AI Impact in Engineering: Q2 2026（Justin Reock，vendor-claim，500 多家客戶組織）是本資料庫中與本報告結構最相近的資料：一家工程指標供應商檢視自己的客戶群，透過電子報解讀一份設有存取門檻的 PDF，建議也指向該供應商的產品類別。這是同一市場中第二種具商業利益的測量工具，不是獨立複現；以下所有數字都是摘要數值，資料庫無法取得其方法細節。

第三種對照方式，也印證大小是驅動因素。 DX 指出，2026 年第 1 季到第 2 季的 PR 大小中位數幾乎翻倍，並基於與本頁相同的理由，將 PR 大小上升視為技術債的早期指標——每次變更的複雜度增加，也有更多內容需要審查。目前有三個來源在方向上取得共識，但測量的是三種不同事物：

來源	對照方式	結果
Faros（本頁）	公司內部，低與高 AI 採用度比較	PR 平均大小 +51.3%，每個 PR 的檔案數 +59.7%
Tran et al.	同一 monorepo 內，AI 與人類撰寫的變更比較	中位數 89 行對 33 行，3 個檔案對 2 個
DX（vendor-claim）	2026 年第 1 季與第 2 季比較，面板內依日曆時間計算	PR 大小中位數 約 2 倍

DX 是唯一以日曆時間測量、而非橫斷面比較的來源，也是變化最快的：短短兩季，中位數就翻倍。這不但沒有回答本頁第一個開放問題（對 PR 大小進行標準化後，品質效應是否仍然存在），反而讓問題更迫切——DX 完全沒有發布按大小標準化的結果。

新發現關乎預算，而非品質。 DX 估計 AI 使用者每週省下 4 到 6 小時，並指出同期的創新比例——用於打造新功能的時間占維護與額外負擔時間的比率——持平不變。因此，時間確實省下了，但投資組合沒有改變。

本頁與這項發現合在一起，形成一個兩個來源都未能證實的假說：省下的時間被同一波吞吐量所產生的下游工作消耗了。 更大的 PR 需要審查、更長的佇列、更多事件、更多重工——本頁列出的每個數量都以工程師工時計算，而創新比例持平，正是生產力提升被拿去支付自身成本時會呈現的樣子。DX 沒有拆解時間流向，因此這只是對兩組供應商資料的解讀，不是測量結果。從組織層面來看，這也回應了 Ng 的晉升故事——QA 負擔下降，本應釋放注意力並向上轉移；但從面板整體來看，釋出的注意力並沒有落在新功能上。

DX 用自家組成資料執行迴歸分析，結果大致無法解開謎團（2026-09-22）。 AI accelerates output, not innovation（Grace Fu，DX 研究分析師，2026-09-09，vendor-claim；明確以 Q2 報告為基礎的後續研究，涵蓋 500 多家 DX 客戶——DX 沒有說明是否為同一個面板）更新了省下的時間數據，接著用 15 項工作流程指標對創新比例進行迴歸。按日曆時間計算，省下的時間翻倍：自我回報的省時幅度從 2025 年第 3 季每週 3.0 小時增至 2026 年第 2 季每週 6.1 小時；而「AI 輸出」綜合指標（AI 撰寫程式碼的占比、代理程式交付的工作、PR 吞吐量）可解釋省時幅度中 63% 的變異。相較於創新比例，同一綜合指標的標準化 β 為 0.16（p < 0.01）；模型中係數最大的是資訊搜尋摩擦，β 為 −0.19（p < 0.01）——也就是花時間搜尋情境、文件或答案所造成的損失。部署頻率（+0.06）和會議密集日（+0.04）是 DX 顯示的另外兩個係數，但只出現在圖表中；完整的 15 項指標模型可解釋創新比例變異的 13%。DX 自己的解讀是：沒有任何單一指標能可靠預測該比例，應將創新視為需要獨立管理的目標，而非 AI 策略的副產品；與其相信整體係數，不如用自己的資料重新執行迴歸分析。

這項研究對上述假說有三個支持之處與限制。它證實了形狀——能強烈預測省時幅度的輸入，只能微弱預測投資組合轉移；若依照「省下的時間被用來支付自身成本」的解讀，這正是預期的結果。現在這個證據來自同一家供應商自己的測量工具，而非將兩家供應商的結果並置比較。它沒有提供前段要求的時間流向拆解，而且從結構上就無法提供：預測變項是工作流程指標，而非時間流向分類，因此，87% 無法解釋的殘差可能代表時間被審查、QA 與事件消耗（本頁提出的機制），也可能流向其他地方——而 DX 點出的時間流失來源「資訊搜尋」，並不在本頁的下游成本清單中；它反而更接近 Faros 後續報告根據工作重新開始數據所推論的情境匱乏。最後，最像支持證據的數字，也是最需要打折看待的數字：AI 輸出 → 省下時間的 63% 解釋力，來自一個預測變項；其中程式碼占比在 Q2 報告中以自我回報呈現（迴歸綜合指標有哪些成分來自遙測，並未說明），而預測結果也是由同一批受訪者自我回報，因此，共同方法變異是這種高度吻合最可能的解釋。相較之下，創新比例是另一項自我回報，與工作流程指標沒有這種共同來源——恰好就是模型無法解釋的結果（見遙測與調查測量）。將兩者合併解讀：詢問開發者自身狀況的測量工具，彼此高度吻合；對他們詢問投入心力占比時，吻合度就不高。本頁的推論仍是解讀而非測量結果，而 DX 的 R² 大致就是這個落差的規模。

還有一項認知測量結果，也朝本頁預測的方向移動。 DX 的開發者體驗指數在四季內從 67 降到 65；最引人注目的是自 2026 年第 1 季起，其兩項構成指標出現分歧：程式碼可維護性 +3.8%，變更信心 −6.1%。 DX 的說法是，兩項過去相關的指標如今分道揚鑣——AI 讓眼前程式碼更容易理解，卻讓你推送出去的內容更難信任。

先看測量工具，再看發現。依照文章自己的定義，這些屬於認知——可維護性是「開發者理解程式碼庫的容易程度」，變更信心則是「他們相信修改不會導致正式環境故障的程度」——因此這是 DX 測量工具中的調查部分，而非遙測。這對本頁有利，而非不利：認知落後於現實的論點恰好預測這種先後順序：在 Faros 測得的系統結果出現後幾季，主觀信心才逐漸下降。吞吐量上升期間，信心指數卻下滑，正是認知追上現實的樣子。但這並不能獨立證實事件和錯誤數字；這些數字仍只有 Faros 提出。

DX 的第六項發現是包住整體情況的預算框架：四季內，組織每季 AI 支出中位數從 約 1,500 美元增至約 44,000 美元，科技業支出接近增加 28 倍；其警告是，領導者若無法將支出與功能速度、創新比例或品質連結起來，「可能會面臨越來越棘手的預算討論」。請見企業 AI 支出強度與人數成長，了解這項數據在本資料庫其他支出測量中的位置。

一個團隊如何描述鞭梢效應，並附上機制（2026 年 9 月）#

本頁的每個數字都是對多家客戶的彙整。Stolze & Strässle（ESEM 2026 SEIP，case-study）提供本資料庫第一個針對單一專案失效模式的第一手說明，來自能源公用事業公司前端團隊的一名工程經理（P2）。數月間，AI 生成的變更持續累積，卻沒有相應增加審查能力；等到架構問題浮現時，一項重要功能不得不整個捨棄並從頭重做。他自己提出的反事實，正是本頁主張的機制，由親身經歷者親口說明：

「如果當時沒有使用 AI 系統，我們就不會產生那麼多程式碼……也許我們會更早發現。」

這項研究樣本為 n = 5，其中一個案例是 n = 1；儘管如此，仍有兩點值得納入。它具體指出偵測延遲這條路徑——問題不在於 AI 程式碼比較差，而是產量讓問題浮現的時間延後，因此同一個缺陷會更晚顯現，代價也從修正變成重寫。作者也沒有採取顯而易見的解讀：P2「將此視為一種失效模式，而非固有特性」，並指出教訓是「生產力提升和驗證基礎設施必須同步擴大——這是組織選擇，而非純粹的技術最佳化。」這與本頁從遙測資料得出的結論相同，但出自單一專案的內部經驗。整篇論文對壓力的回應是結構性的，而非補救性的——將監督分散到三個層級，而不是擴大審查規模（分層監督）。

第二項由人類控制的測量，來自 monorepo 之外（2026 年 9 月）#

Kraishan (arXiv 2609.17598)是第一個在 Faros 客戶實際相似的母體中，檢驗本頁部署後主張的來源——審查閘門較弱且各異的公開 GitHub 程式碼庫，而非由中央管理審查的 Google monorepo。共有 37,623 個標註來源的 PR、2,807 個程式碼庫，也具備本頁要求兩次的對照條件：4,027 個人類 PR 僅取自同時含有代理程式 PR 的 810 個程式碼庫，時間範圍相同，且每個程式碼庫有數量上限。

結果與 Google 站在同一邊，而且差距更大。 合併後 90 天內，人類 PR 的還原率為 11.5%；Codex PR 為 6.1%（OR 0.50）、Devin 為 14.5%（OR 1.31）；經 BH 校正後，Copilot、Cursor 與 Claude Code 的結果在統計上與人類無法區分。依表 2 各列加權，代理程式的合併還原率約為 7.7%，OR 約為 0.64 （依表格計算，不是論文公布的數字）。因此，低於持平水準的還原結果並不仰賴 Google 的提交前閘門——母體改變後結果依然成立，而且差距更大。每行程式碼的合併後 churn 方向相同：五家供應商中有四家不高於人類水準，Claude Code 是所有組別中最低的（δ = −.33；每 100 行變更的後續提交中位數為 0.5，而人類為 5.3）。

有三個理由說明這並不能直接推翻 Faros，而且與先前的三項理由相同。 依變項是由提交訊息標記、發生在 PR 變動最多檔案上的還原；作者表示這會漏掉沒有標記的重寫——透過向前修正處理的事件無法被記錄，與 Google 資料中的情況完全相同。母體是星數逾 100 的開源程式碼庫，涵蓋三種語言，以及通過公開專案審查的 PR；Faros 的資料則是整個組織層級的企業 SDLC 遙測。作者也提出一種與程式碼本身無關的機制：「引導這些代理程式的人可能會指派範圍明確、規格完整的任務」——這種選擇效應，無論代理程式品質如何，都可能造成低於持平水準的還原率。

真正有所改變之處。 現在有兩個 empirical 來源各自以人類對照組，在審查閘門成熟度相反的兩種母體中，都發現代理程式程式碼的合併後故障率不高於持平水準；然而，本頁供應商遙測報告的每個 PR 事件數為 +243%。本資料庫所有受控測量結果都將品質下滑主張逼至流程中的合併前與審查負擔兩部分。（以上沒有任何內容取代 Faros 的數據；這些數據仍按報告原樣保留，但依變項與母體均不同。）

本頁完全看不到的新變項。 Faros 將所有 AI 工具合併計入「AI 採用」。Kraishan 的整體結果則是，供應商之間的差距大於代理程式與人類之間的任何差距——相同基準下，還原勝算從 0.50 到 1.31 相差甚大；安全異味出現率相差六倍，憑證異味相差四倍。若以一個工具組合不明且不斷變動的客戶群，進行 AI 採用深度的橫斷面平均，便會掩蓋這種差距；這是報告從未納入的變異來源，也可能解釋「成熟度無法保護你」的模式：採用 Devin 的群體與採用 Codex 的群體，並非同一個實驗。

Faros 自家後續報告：衝擊緩和，壓力轉移至下游（2026 年 9 月）#

The Speed Trap（Faros Research，2026-09-18，vendor-claim）是本頁來源的續篇——2026 年第 3 季 AI Engineering Report，仍採用涵蓋 22,000 名開發者、4,000 個團隊的同一面板，現在觀察最近 12 個月。這是本資料庫唯一重新執行本頁測量工具的來源；由於出自同一家有相同商業利益的供應商，它是第二次測量，而非複現。

解讀數字前先看測量概念。 貼文中的每個百分比都是期間對期間的增幅——將這份資料集與前一份（約 2026 年 4 月）報告比較——而且兩個期間的團隊都已高度採用 AI。沒有 AI 與非 AI 群體的比較、沒有定義哪些變更算是「AI 輔助」、沒有抽樣說明、沒有顯著性檢定，而且完整報告須透過潛在客戶開發表單才能取得。先前的報告比較同一家公司採用程度低與高的季度；這次則是比較深入採用與更深入採用。因此，它無法回答本頁任何需要對照組的問題，以下數據反映的是變化率的變化，而非 AI 的影響。

各項增幅並列比較。 數據轉錄自報告 2026 年第 3 季「Key Findings」資訊圖表（直接檢視；正文僅列出其中部分數字）。以下內容均不取代本頁上述數據——那些是前一段期間的增幅，對該期間仍然成立。

指標	2026 年第 3 季報告	前一份（約 2026 年 4 月）報告
每週部署數	+13.8%	−11.7%
程式碼刪除比率	+71.6%	+861%
每個 PR 的事件	+14.5%	+242.7%
完全跳過審查的 PR	+76.3%（見注意事項）	+31.3%
每位開發者重新開始工作的次數	+66.7%	+13.8%
QA 中的平均任務時間	+300.6%	+33.7%
每月事件	+125.4%	+57.6%（本頁依前一份報告本身的數字記錄為 +57.9%）

正文還補充了一個圖表未列出的指標：PR 平均大小 +71.8%，比「前一份資料集更高」（前次為 +51.3%）。儘管數字接近，這是不同統計量，不可與圖表中的程式碼刪除比率 +71.6% 混為一談。+57.6%／+57.9% 是兩份 Faros 出版品之間，唯一一項針對同一個 Faros 數字出現分歧之處；差異幅度雖小，卻是讀者唯一能用來檢查右欄整體準確性的依據。

「無審查」數字的測量概念注意事項——引用時務必一併附上。 正文寫道：「六個月前……增加 31.3%；現在這個數字已上升到76.3%。」資訊圖表則呈現為「+76.3% 的 PR 完全跳過審查，比前一份資料集 +31.3%」，格式與圖表上所有其他增長列相同。根據這些證據，本資料庫將 76.3% 解讀為未經審查 PR 指標的期間對期間增長率，而非未經審查便合併的 PR 占比。單看正文確實有歧義，定義則藏在需通過存取門檻才能取得的報告裡。請勿聲稱 76.3% 的 PR 未經審查便合併。

採用情況，以及前沿焦點轉向代理程式。 79% 的開發者每週至少使用一種 AI 工具；86% 的團隊每週活躍使用者滲透率超過 50%；AI 程式碼接受率為 65%（前一份報告的 AI as Primary Author 為 60%）。許多公司如今有 50–80% 的 PR 使用代理程式進行審查（前份報告為 0%→25%）；領先群體的代理程式則開啟 13–14% 的 PR，而前一份資料集為「PR 的 <1%」。這兩項撰寫相關數字的分母不同（一項是面板彙整占比，另一項是未具體說明的領先群體切片），因此不能合併成「整個面板從 <1% 跨入兩位數」；這點會影響本頁相鄰文章提出的預測。

這些趨勢實際呈現的內容。 三項「初期衝擊」指標都大幅放緩；四項下游指標都加速上升。Faros 自己的調和說法是，每次變更的品質不再崩跌，但產量持續增加，因此整體營運成本繼續上升：每個 PR 的事件 +14.5%，相較於每月事件 +125.4%。這是對本頁論點的實質補充，而非撤回——鞭梢效應從變更本身轉移到整個系統——也首次有作者指出，本頁最驚人的數字（每個 PR 的事件 +242.7%）只是採用轉型期間的暫時現象。

標準化缺口仍未補上，後續報告讓它更明顯。 貼文完全沒有將每個 PR 的事件數與 PR 大小連結起來。它提供的資訊是，兩者在這段期間朝相反方向移動：每次變更事件的增幅從 242.7% 降至 14.5%，而 PR 大小的增幅則從 51.3% 加速到 71.8%。若 PR 變大是事件增加的原因，兩者理應同步變化。這項資訊值得參考，但不構成標準化——兩個未受控制的期間對期間增幅，沒有聯合模型，也沒有依大小分層的事件數據。見本頁第一個開放問題。

折騰的樣態變了，建議卻沒變。 前一份報告的主要壓力源是並行性（太多同時進行的 PR 情境）；目前這種情況有所緩解，重新開始工作——放棄進行中的工作，從頭再試——以 +66.7% 取而代之，幾乎是前次 +13.8% 的五倍。Faros 將此解讀為代理程式缺乏足夠情境，無法第一次就把工作做好；這與前一份報告第 10 項建議的診斷和解方相同（情境引擎）。失效模式改變了，但所指向的產品類別沒有改變；在將這種機制視為已證實發現前，值得先注意這點。

第 8 項重點是唯一具指示性的主張，卻沒有數字佐證。 大量採用代理程式審查的團隊出現「更快的首次審查和更低的變更失敗率」——兩者都沒有百分比，Faros 明確標為相關性，也坦承即使在高度採用代理程式審查的地方，未經審查就合併的情況仍持續增加。這是本資料庫第一個帶有結果意味的訊號，指出代理程式審查與品質結果有關；但依目前證據強度，它沒有觸及審查作為控制點所爭論的核心。Faros 仍然認為主要著力點在撰寫，審查是第二道防線——與本頁論點相同。

有一項發現稍微有利於這家供應商。 一家以「危機不斷加深」為敘事的供應商，公布自家最受矚目的警訊指標減速約十七倍。這個方向會讓賣方有所損失，因此可作為反駁本頁第三個開放問題中「純粹由誘因驅動」解讀的弱證據。相對的觀察是，如今領頭警訊的是 QA 時間 +300.6%——整份報告中，這項數字在本資料庫其他來源得到的佐證最少。

相關連結#

• Layered Supervision — 面對這種壓力的領域回應，也是這種失敗的具體案例：一個團隊讓 AI 生成的變更累積到超出審查能力，最後在重寫時失去了一項功能。該文的說法是，解方既不是增加審查，也不是改善撰寫，而是將監督功能重新分配到預防、可執行與人工等層面；而它拒絕使用「成熟度」一詞，也從第三個方向反駁本頁所稱的成熟度無關論
• Community Smells Under AI Adoption — 從調查而非遙測探討同一個組織規模問題，且結論方向相反：在 AI 採用下，團隊自評的社交健康度有所提升，而 Faros 測得的品質卻在惡化。兩者衡量的是不同構念、使用不同工具，因此並非直接矛盾；但該研究自由文字回答中的少數意見，聽起來更像遙測資料，而非其係數所呈現的結果
• AI as Primary Author — 前提條件：助理→作者的門檻（接受 60% 的程式碼）造成系統被大量輸出淹沒；「AI 現在是主要作者」則是該報告對於誰產生這些被吸收輸出的描述
• Systems Thinking Over Specialization — 一種明確提出的反制策略：Netflix 的鋪設路徑與設計系統，試圖透過將防護欄編入基礎設施來提高吸收能力，而不是依賴流程關卡
• Excellence as an Operating System — 本頁資料所挑戰的文化賭注：Stone 認為「增加流程從未帶來更好的結果」，而 Faros 的證據顯示，即使成熟度高的組織，也無法吸收代理程式規模的吞吐量。人才密度加上編碼於系統中的防護欄，能否取代流程，是兩頁都記錄的開放問題
• Verification as the New Bottleneck — Faros 以遙測資料佐證瓶頸，但也進一步調整解方：改善撰寫，不要只擴大審查。該頁現在也收錄了 CircleCI's Q2 2026 Pulse（vendor-claim，超過 2,000 萬個 CI 工作流程），這是第二組方向一致的獨立廠商遙測資料：功能分支吞吐量年增 7.7%，主分支吞吐量則持平；頂尖與中位數的速度差距在一季內從 8 倍擴大到 9 倍——這正是本頁所主張的差距擴大趨勢，只是由銷售不同產品的廠商使用不同工具測得。不過，CircleCI 的主分支成功率在同一期間從 70.8% 升至 76.7%，這項品質指標朝正確方向移動。兩者所處層面不同（CI 通過率與正式環境事故），且樣本僅涵蓋 CircleCI 客戶，因此它是界定適用範圍的標記，而非反證——管線可以變得更綠，交付的成果卻可能變差
• AI Brain Fry — 認知負荷途徑：情境切換與審查不足，是組織規模的速度衝擊在人身上造成的壓力
• Psychological Costs of AI Adoption — 同樣的審查負荷，只是以人而非 PR 為單位計算。 Faros 測得 PR 審查時間中位數增加 441.5%，卻無法指出誰承受了這項負擔、付出什麼代價；該案例研究則在變革開始一年後訪談承受者，受訪公司正經歷同樣的轉變，並揭露遙測資料沒有欄位記錄的內容——審查負擔來自責任仍由人承擔，而非輸出量（「如果我們不必為它產生的程式碼負責，速度會快很多」）；負擔因職務而分配不均（軟體工程師的責任焦慮為 10/10，架構師則為 0/3）；而組織密切追蹤採用進展時，卻沒有衡量這些負擔。該研究也說明了為何模型進步後負擔仍未減輕：委派撰寫工作，會把驗證從寫作過程中交錯進行的活動，轉變為獨立的事後階段，而這個階段必須重新建立原本因撰寫而自然形成的理解
• Agentic Technical Debt — 品質惡化就是以工業規模複利累積的債務；Faros 的「情境引擎」（建議第 10 項）則是擴展至組織規模的 CLAUDE.md 機制
• Telemetry vs. Survey Measurement — 成熟度無關論的方法論基礎，以及明確提出的 DORA 反方觀點
• Vibe Coding vs. Agentic Engineering — 反面鏡像：組織未能維持 Karpathy 品質標準時，資料呈現的就是這種樣貌
• Blast Radius (Agentic) — Faros 所說的「每次變更的影響範圍更廣」是指程式碼變更（更大的 PR 涉及更多程式碼庫範圍），不同於安全性遭入侵的影響範圍
• Harness Shrinkage as Models Improve — 一項反向壓力的資料點：即使模型進步，組織層級的品質仍在惡化，因為 harness（情境提供、品質關卡）未能跟上能力發展
• Outsource Your Thinking, Not Your Understanding — 資深工程師承受的代價，是理解債務在審查時兌現：必須有人重建作者從未掌握的意圖
• Agentic Coding Work-Composition Shift — 並列比較的遙測資料：Anthropic 同期研究發現，互動式工作階段層級的工作階段價值增加約 27%、除錯工作減少；本研究則發現組織 SDLC 層級的品質下降——衡量單位不同（工作階段成功與下游事故），研究性質也不同：empirical 研究遙測與此處的 vendor-claim 報告
• Organizational Complements to AI — 速度衝擊下的診斷：吞吐量提高但品質下降，是組織採用 AI 的速度快於重新設計審查／QA 配套時，生產力悖論所呈現的失敗模式；遙測資料捕捉到的正是缺少的配套
• AI Investment Story, Not Efficiency Story — 財務指標的相關研究：吞吐量提高，但實際的人均效率未能跟上，因為組織配套落後於採用速度——這和速度衝擊是同一種落差，只是衡量指標從 SDLC 品質換成了每位員工的營收
• The Three Loops of AI-Native Building — 這項遙測資料的證據力高於 Andrew Ng 的自述：他聲稱自我測試代理程式「大幅」降低開發者的 QA 負擔，但 PR 審查時間中位數增加了 441.5%；可能的調和因素是範圍不同（個人從零到一的建置與正式環境組織）
• Security Debt of Agent-Generated Code — 非廠商的 empirical 研究，從安全面佐證品質問題的一半（38.9% 的代理程式 PR 帶有安全異味，集中於 CI／容器檔案），也是本頁第一個開放問題所要求的依 PR 大小分層資料來源
• Agent-Generated Test Quality — 以測試套件為範圍衡量撰寫品質論點的非廠商 empirical 研究：代理程式撰寫的測試，未模擬的檔案 I/O 和非決定性情形約為人類撰寫測試的 1.4 倍，這是吞吐量上升導致 CI／建置阻塞的一條具體途徑。它也使本頁對 Ng 的質疑更複雜——自我測試代理程式確實擴大了涵蓋範圍（邊界案例多樣性為 0.62，相較於 0.32），只是也讓測試執行環境變得不穩定，因此爭論雙方都各有一部分成立
• Risk-Tiered Auto-Approval — 本報告建議的風險分級關卡已在正式環境中運作：PostHog 的 StampHog 在拒絕清單與 <500 行／<20 個檔案上限的限制下，自動核准了合併至其主程式碼庫的 PR 中約三分之一。這是審查層級的槓桿，而本頁主張那不是正確的切入點；但其大小上限直接處理了「每次變更的影響範圍更廣」這個成因，配套做法（拆解為每個少於 400 行的堆疊式 PR）則屬於撰寫端的變更
• Agent-Vendor Heterogeneity — 第二份在部署後結果上與本頁主張相左的人為控制 empirical 研究，也是第一份來自企業單體式程式碼庫以外的研究。 在超過 100 星的公開 GitHub 程式碼庫中，代理程式彙總還原率約為 7.7%，同一程式碼庫的人類對照組為 11.5%；五家廠商中有四家的逐行變動率不高於人類。這排除了「Google 的關卡攔截了 Tran 研究所發現的問題」這種說法。它也指出本頁彙總遙測在結構上無法觀察到的一項變異來源：相對於單一基準，各廠商間的還原勝算介於 0.50 至 1.31，因此，對工具組成未知的客戶依採用深度做橫斷面分析，等於把一個比所報告效果還大的差異範圍取平均。詳見上方 2026 年 9 月一節
• Efficiency Debt of AI-Generated Code — 以人為控制組的對照研究，也是唯一在同一份資料集中衡量本頁兩個面向的來源（見上方章節）。它以較小幅度佐證審查負擔面向，反駁部署後面向（還原率約為 0.9 倍），並補充本頁未曾計算的下游成本：AI 比重高的函式，運算量相對增加約 5%、記憶體用量相對增加約 8%，原因是明確迴圈取代了標準函式庫呼叫。該文的 #oq 關於較弱的預先提交關卡，正好映照本頁的成熟度問題
• Agent Review Comment Resolution — 本報告資料中自動化速度最快的層面，是否真的產生了成果。Faros 記錄代理程式審查占 PR 的比例從 0% 升至 25%，而代理程式撰寫仍低於 1%；該研究則衡量這一層的產出，分析 54,713 則評論，發現約十之七獲得解決（Copilot 72.9%、Cursor 67.2%、Codex 54.8%）。這稍微削弱了速度衝擊的說法——自動化監督層正在被使用，並未遭到忽視——但有兩項限制：彙總數據中 Copilot 占 83.5%，且研究沒有將評論採用情形與任何下游品質結果連結，因此未觸及本頁的事故與錯誤數據
• The Committed-Artifact Chain — 提出相同診斷，卻以主張而非測量呈現，並提出本頁論點所反對的解方。 Anthropic 的 Applied AI playbook（vendor-claim，2026-08-21）開篇即指出完全相同的發現——建置時間縮短至數小時，但前後階段仍由人力速度決定，控制措施不再符合現況，治理成本上升——接著建議建立一條以審查與關卡機制為主體的產物鏈，而本頁論點正認為那是錯誤方向。十一項做法中有兩項從撰寫端著手（以 CLAUDE.md／技能限制生成；透過回饋迴圈讓工作階段在交由人類檢視前先行驗證），因此兩者在比例上有分歧，原則上則一致。兩者直接衝突之處在於審查時間：playbook 預期首次審查所需時間會「縮短至幾分鐘」，而測試攔截過去由審查者發現的問題後，每個 PR 的審查時間也會下降；相較之下，本頁測得 PR 審查時間中位數增加 441.5%。兩者衡量的數值不同，可以同時發生——代理程式審查者幾分鐘內就能留言，卻不會縮短人類閱讀的時間——但只有一方實際做過測量，而那一方是本頁
• Review as the Control Point — 非廠商對照研究。 Faros（vendor-claim）主張差距隨採用增加而擴大，成熟度無法提供保護；CMU 這份非廠商理論研究（empirical）則主張 AI 不會改變影響方向，團隊專業能力與流程才會，且其自身 GitHub 遙測發現，代理程式不經審查的比率在 2025 年年中至 2026 年初逐漸下降並趨近人類基準，而非擴大。雙方都有保留條件（開源與企業樣本不同；兩者都沒有在品質結果上勝過另一方）
• The Code-Quality Payoff Is Token-Indexed — 足以讓人接受這種品質下降的論點，以及它實際依據的前提：DHH 認為，只有在 token 稀缺時，架構一致性才值得付出成本
• Open Source Under Agent Contributions — 未能吸收輸出的單一維護者版本：開源 PR 積壓每週翻倍，因應方式是委派審查，而非增加人手
• Does the Augmentation/Automation Split Govern Skill at Work? — PR 合併時未經審查的比例為 31.3%，這被視為職場中的第三種使用模式：隨機學習實驗中的自動化模式使用者仍會自行處理輸出；放棄處理則移除了原本能帶來學習的審查步驟——這是產量所造成的失敗模式，而受監督的實驗階段則將產量固定為一
• Experimental Learning Impact of Generative AI — 本頁吸收故事在學習面向上的界限：隨機實驗中的自動化組仍將輸出交由人類處理（移除 AI 後，成效就會落空，但短期內確實存在）；相較之下，31.3% 的 PR 在未經審查下合併，代表審查步驟直接消失——輸出未被吸收，吸收輸出原本能帶來的學習也同樣沒有發生

尚待解答的問題#

• Faros 自己延後處理的問題：若依 PR 大小正規化，錯誤／事故增加的現象是否仍然持續？還是品質惡化主要來自較大的 PR？（若屬後者，嚴格限制 PR 大小就是最具槓桿效益的解方。）Security Debt of Agent-Generated Code 提供了部分解答（empirical，非廠商）：在安全面向，PR 層級的標記率會隨變更大小單調上升——從 1–9 行 PR 的 16.2% 升至 1,000 行以上 PR 的 53.6%，相差 37.4 個百分點。這就是問題所要求的依大小分層證據，也支持嚴格限制 PR 大小確實是可行槓桿。兩項缺口讓問題仍未解答：該研究衡量的是新增的異味，而非 Faros 統計的錯誤與事故；此外，這是橫斷面關聯，無法判斷限制大小究竟降低了問題密度，還是只把相同變更重新分散到更多 PR。Tran et al. 在 2026-08-12 提供了進一步的部分解答，使用人類對照組：Tran et al.（empirical，含人類控制組）。其中 AI 變更確實較大（行數中位數 89 對 33，檔案數 3 對 2），而下游比較也依變更大小等其他共變量分層——因此，分層後仍存在的比率差異並非大小效應。依結果而異的部分是：阻擋討論串為 1.92 倍、建置失敗約 1.3 倍，仍高於人類基準；還原率約為 0.9 倍，仍低於人類基準。因此，大小無法解釋品質惡化，而品質惡化也沒有單一方向。嚴格限制 PR 大小所處理的是審查負擔，而非正式環境穩定性；因此，這項槓桿的適用理由比本項原先假設的範圍更窄。第三份部分證據於 2026-09-22 出現，取自公開 GitHub 樣本： Not All Agents Are Equal: Code Quality and Post-Merge Maintenance Across Five Autonomous Coding Agents in the Wild（Kraishan，empirical，非廠商，採用同一程式碼庫的人類對照組）以兩種方式檢驗大小問題，結果都顯示大小並非關鍵。其依大小分層的敏感度檢查發現，代理程式與人類的彙總安全異味密度差異完全集中在 XL PR 組（δ = −.08，p =.025），四個較小組別則沒有差異——這與安全研究從相同趨勢得出的解讀恰好相反：安全研究中，較大的 PR 帶有更多異味；此處則是代理程式在較大的 PR 上勝過人類。其合併後變動指標則依定義已按大小正規化（後續提交數 ÷ 變更行數），五家廠商中有四家正規化後不高於人類水準；未正規化的排名則不同（Copilot 在所有組別中最低，Codex 稍高於人類），因此正規化改變了勝出者，卻沒有在任何設定下造成代理程式的劣勢。但它仍無法提供本項真正要求的數據：它統計還原與變動，而非 Faros 統計的錯誤與事故；其還原偵測器依據提交訊息，會漏掉未明言的重寫。這項槓桿如今有兩個來源支持其能減輕審查負擔，卻沒有來源支持其能提升正式環境穩定性。Faros 後續報告也被問到這個問題，卻沒有回答（2026-09-22）： The Speed Trap 對同一組樣本在六個月後重新分析，文章仍未在任何地方將每個 PR 的事故數與 PR 大小連結——沒有依大小分層的事故數據，也沒有正規化說明，什麼都沒有。它提供的只是一項意味深長的未回答：在兩個觀察期間中，每次變更的事故成長從 +242.7% 降至 +14.5%，而 PR 大小成長則從 +51.3% 加速至 +71.8%，因此本項要求連結的兩個數值朝著相反方向移動。如果大小是事故增加的主因，兩者應該同步變動。這項證據不支持「大小是主因」的強版本假設，而且這並未經過正規化：它只是同一組高採用率樣本在兩個未受控期間的變化量，沒有聯合模型、沒有控制組，而方法論藏在表單限制的報告中。所需資料依然不變——任何來源提供按 PR 大小區分、每個 PR 的事故數即可。
• 程式碼變動增加 861% 確實有多種解讀（Faros 列出三種解釋：重做 AI 程式碼、有效率地重構舊程式碼，或加速潤飾）。跨客戶指標無法釐清這點——這是真實缺口，不是研究發現。2026-07-29 新增一項部分代理指標：5 takeaways from the State of Software Delivery Q2 Pulse report（vendor-claim）：CircleCI 的合併效率比率衡量功能分支在合併至主分支前所需的驗證週期數（中位數 3.9、前 5% 為 2.6、精英群體為 1.3），計算了相同重做工作的合併前形式，且可按團隊計算，而非跨客戶彙總。它只從一個方向縮小歧義：合併前因驗證失敗而耗費的週期，很難解讀成「有效率地重構舊程式碼」，因此高 MER 比變動量更明確地代表重做工作。但它無法拆解 Faros 的指標，因為兩者衡量不同項目——MER 統計嘗試次數，變動量統計刪除行數與新增行數；而第一次就通過 CI 的乾淨重構對 MER 毫無影響，卻可能主導變動量。2026-09-22 再新增一項來自合併後另一端的部分證據： Not All Agents Are Equal: Code Quality and Post-Merge Maintenance Across Five Autonomous Coding Agents in the Wild 使用同一程式碼庫的人類對照組衡量合併後變動量——在 90 天內，PR 中變更最多的檔案後續提交數除以變更行數。五家代理程式中有四家不高於人類水準（Claude Code δ = −.33，中位數 0.5 對人類的 5.3；Copilot −.16；Cursor −.08；Codex 和 Devin 持平）。這也無法拆解 +861%，而且衡量構念仍然不同——90 天內每個變更行數所對應的提交數，對照短期窗口內刪除行數與新增行數；此研究還是以每個 PR 一個檔案作為整個 PR 變動量的成本代理指標。這項研究在其樣本中排除了 Faros 三種解釋中的第一種：如果變動量代表重做 AI 程式碼，那麼相同程式碼庫中的代理程式撰寫變更，後續每行提交數應高於人類撰寫的變更；實際上卻更低。剩下兩種解釋（有效率地重構舊程式碼、加速潤飾）都涉及無法歸因至特定 PR 的工作，而這正是逐 PR 設計無法看見的部分。指標發布者自行重新衡量後，仍無法區分兩者（2026-09-22）： The Speed Trap 報告相同數值，現在將其稱為**「程式碼刪除比率」而非「程式碼變動量」；相較於前一期間的 +861%，此數值增加 +71.6%。成長率下降超過一個數量級，與 Faros 提出的三種解釋都相符（團隊熟悉工具後，轉型期的重做工作減少；逐步消化重構舊程式碼的積壓；潤飾恢復常態），因此無法在三者之間做出區分，報告也未提供拆解結果。它確定了兩件事，兩者適用範圍都很窄。+861% 是採用轉型期的暫時現象，而非新的常態水準**——因此不再支持變動量持續失控累積的解讀。另外，Faros 在兩份報告中對可能是同一項指標使用兩個不同名稱，卻都未公開定義；這是另一個獨立理由，說明外界無法拆解此構念。要解決問題，要求仍然不變：按團隊拆解已刪除的程式碼行，並註明這些程式碼是否由 AI 近期撰寫。
• 「成熟度無法提供保護」這項主張，有多少是廠商基於自身利益，才會主張正是這一點（也就是「你現有的做法救不了你——你需要我們的平台」）？Review as the Control Point 提供了部分解答（非廠商，empirical）：該文的核心論點恰好相反——AI 不會改變影響方向，團隊專業能力與流程會——這與 DORA 的「基礎做得好就能保護你」一致，並反對 Faros 的決定論。但它主張調節因素確實存在，卻沒有測量成熟度的效果，因此廠商利益問題並未解決，只是有一份不同意其說法的非廠商來源作為平衡。第三種觀點，2026-09-22——When Review Alone No Longer Scales: Layered Supervision in AI-Assisted Software Engineering（case-study、五次訪談、非廠商、學術研究）拒絕採用這個判別軸，沒有選邊站。五個團隊在三項明確維度上有所差異——治理立場、系統關鍵性與同質性，以及團隊組成——作者也明確拒絕使用成熟度一詞，「因為它暗示線性進程，而我們的資料不支持這種說法」。這直接挑戰了本主張與 DORA 共通的前提，也就是組織可以用單一量尺排列；如果實際情況確實是多維空間，那麼「成熟度無法提供保護」與「基礎做得好就能保護你」都是在回答一個設問不當的問題。這無法解決廠商利益問題，也不可能做到：拒絕以五個質化觀察點排序，是一種建模選擇，而非測量；支撐這些維度的調查採便利抽樣，也未經試測。這項研究的作用，是留下非廠商來源的紀錄，指出真正值得懷疑的是這套階梯。2026-09-22，來自自身利益一方的一項薄弱數據： Faros 在 The Speed Trap 報告自家最重要的警訊指標——每個 PR 的事故數——從 +242.7% 降至 +14.5%，並明確表示每次變更的品質「已不再崩跌」。主張「你的做法救不了你」的廠商，公開其最嚇人的數字大幅下降了十七倍，這個方向會讓銷售方付出代價，因此是反對將成熟度主張視為純粹敘事的一項微弱證據。證據力有限：警訊並未消失，而是轉移到同一產品所能處理的其他指標（QA 時間 +300.6%、月事故數 +125.4%、未經審查的合併）；而且後續報告使用相同工具，方法也同樣未公開，因此無法從外部稽核先前報告的論述。問題仍需要非廠商對成熟度效果的測量，而資料庫中沒有任何來源提供這類資料。

已解決的問題#

• Faros 將審查不足視為一場正在擴大的危機；CMU 的非廠商 GitHub 遙測資料則發現，隨著組織學會審查代理程式程式碼，代理程式未經審查的比率正趨近人類基準（超過 50% → 約 14%）。這種差異是真的嗎（企業與開源樣本不同、採用深度橫斷面分析與日曆時間趨勢不同），還是只有 PR 量最高的地方才會出現速度衝擊所帶來的審查不足壓力？已解答：審查不足的分歧：Faros 的擴大危機與 CMU 的趨近趨勢——差異大致上並不真實：Faros 的 +31.3% 是依採用深度計算的未審查 PR 數量變化（企業、所有 PR），而 CMU 衡量的是依日曆時間計算、逐步下降的未審查代理程式 PR 比例（開源）——在 Faros 所記錄的數量成長下，比率下降和數量上升可以同時發生。數量效應的說法有資料支持（每個專案的未審查比例中位數約為 0%，彙總值卻超過 50%；可依 PR 類型分流），而 Faros 自己提出的風險分級關卡補救方案，正是 CMU 觀察到正在形成的分流行為。剩餘的分歧關乎一項預測：當代理程式撰寫占比從 <1% 跨升至兩位數時，分流紀律能否維持——兩份資料都尚未檢驗。

資料來源#

• When Review Alone No Longer Scales: Layered Supervision in AI-Assisted Software Engineering — Stolze & Strässle（OST Eastern Switzerland UAS / smartive AG，arXiv 2608.26316，2026-08-26，ESEM 2026 SEIP），case-study：§5.5（P2 已捨棄並重新實作的功能，以及各項工作應一同擴展的經驗）與 §4.5（三種配置維度，以及明確拒絕「成熟度」一詞）。五次訪談、一份便利抽樣調查，沒有測量結果——證據說明見 Layered Supervision
• Not All Agents Are Equal: Code Quality and Post-Merge Maintenance Across Five Autonomous Coding Agents in the Wild — Obada Kraishan（Texas Tech），arXiv 2609.17598，2026-09-12，empirical，非廠商，唯一作者且尚未發表於任何場域：§3.1（配對的 810 個程式碼庫人類基準組）、§4.1（依 XL 組別分層的大小敏感度檢查）、§4.3 + Table 2（依大小正規化的合併後變動量與 90 天還原結果）、§5（設計無法區分的兩種機制）、§6（依提交訊息偵測還原會漏掉未明言的重寫；代理程式會自行選擇任務）。Table 1 與 Table 2 已依 pdftotext -layout 逐格核對。完整分析與出處限制見 Agent-Vendor Heterogeneity
• AI Engineering Report 2026: The Acceleration Whiplash — 執行摘要、發現 #1–7、「工程組織應採取的做法」
• The Speed Trap: 8 takeaways from our latest AI engineering research — The Speed Trap: 8 takeaways from our latest AI engineering research，Faros Research（企業署名），2026-09-18，vendor-claim——上一項來源的後續報告，來自同一廠商，沿用相同的 22,000 位開發者／4,000 個團隊樣本。八項重點以及「AI Engineering Report Q3 2026 | Key Findings」資訊圖表皆已直接查看並轉錄至原始資料；七項繪製成圖的變化量中，有四項（每週部署數、程式碼刪除比率，以及每個 PR 事故數和月事故數的兩個前期報告欄位）只出現在圖片中。每項數據皆附有構念警語：每個百分比都是本資料集與約 2026 年 4 月報告間的期間對期間變化，兩者的樣本都是 AI 採用率已偏高的團隊——沒有 AI 與非 AI 組別對照，也沒有「AI 輔助」的定義、抽樣方式說明或顯著性檢定；完整報告（「10 項建議」）設有 HubSpot 表單，未填寫。「76.3%」解讀為未經審查 PR 指標的成長率，而非 PR 比例——圖表將其格式化得和其他成長指標相同，文字說明則語意模糊；詳見上方警語方框。另外兩項解析說明：圖表中的「程式碼刪除比率 +71.6%」與內文的「平均 PR 大小 +71.8%」是不同統計數據；圖表前期報告欄位記載月事故數為 +57.6%，但前一份報告寫的是 +57.9%
• 5 takeaways from the State of Software Delivery Q2 Pulse report — Jacob Schmitt，CircleCI 部落格（2026-07-08），vendor-claim：發現 1、2、4——速度差距從 8 倍擴大至 9 倍、功能分支與主分支吞吐量差異、主分支成功率從 70.8% 升至 76.7%，以及合併效率比率
• Characterizing the Quality Profile of AI-Generated C++ in Production — Tran et al.（Google，arXiv 2608.06640，2026-08-06），empirical：§4.2 Table 2（變更結構）、§4.3 與 Figure 4（還原／消毒器／建置失敗比率及五項審查摩擦比率）、§6（效度威脅）。完整分析、證據說明與 COI 見 Efficiency Debt of AI-Generated Code
• AI accelerates output, not innovation — Grace Fu（DX 研究分析師），AI accelerates output, not innovation（DX Engineering Enablement 電子報，2026-09-09；vendor-claim，與其採用的 Q2 報告屬於相同等級，且有相同 COI）。每週節省時間從 3.0 小時增至 6.1 小時（2025 Q3 → 2026 Q2）；AI 輸出解釋了節省時間變異的 63%；以 500 多個 DX 客戶的 15 項工作流程指標進行創新比率多變量迴歸，標準化 β：AI 輸出 +0.16（p < 0.01）、資訊搜尋 −0.19（p < 0.01）、部署頻率 +0.06、會議密集日 +0.04（僅見於圖表，已檢視）；模型 R² 為 0.13。原始資料是轉述摘要，不是逐字剪錄——數值與模型規格均保留，但沒有引用原文。文中未說明是否使用相同的 Q2 樣本；未提供各指標的 n 值、除圖表中四項之外的係數表，也未說明哪些綜合指標由遙測資料構成
• The State of AI Impact in Engineering: Q2 2026 — Justin Reock，The State of AI Impact in Engineering: Q2 2026（DX，Engineering Enablement 電子報，2026-07-22）。編輯時將證據等級從 empirical 更正為 vendor-claim——這是開發者生產力廠商針對自行選定的 500 多家客戶組織樣本所做的分析，並作為閘門限制報告與研討會的潛在客戶開發材料發布；完整理由見 Sources 項目。發現 1–6：自述程式碼占比從 34% 升至 52%、PR 大小中位數近乎翻倍、DXI 從 67 降至 65、Code Maintainability 與 Change Confidence 的分歧、節省 4–6 小時但創新比率持平，以及每季支出中位數從約 1,500 美元升至約 44,000 美元。方法論表格位於閘門限制的 PDF 中，不在知識庫內，因此此處沒有任何數值附帶樣本數、信賴區間、各指標的明確測量期間，或調查數值與遙測數值的區分說明。網頁文章，沒有 docling 解析；頁面上的圖表以圖片呈現，引用的每個數字都出現在電子報原文中。控制組主張的討論見 Telemetry vs. Survey Measurement

資料來源#