AI 作為主要作者

資料來源#

• AI Engineering Report 2026: The Acceleration Whiplash
• Characterizing the Quality Profile of AI-Generated C++ in Production
• The Speed Trap: 8 takeaways from our latest AI engineering research
• The State of AI Impact in Engineering: Q2 2026

摘要#

Faros AI 對其 2026 年遙測資料所記錄結構性轉變的描述：AI 已從助理跨越成作者——「多數組織並未刻意做出這項決策」。指標是接受率：被納入程式碼庫的 AI 生成程式碼比例，從 20% 升至 60%（Faros 的兩組資料），主要由 Cursor 和 Claude Code 在代理程式模式下運作所推動，代理程式會直接套用變更。「助理與作者的區別在實務中已經消失。不是助理，而是作者。」

vendor-claim 來源——證據上的但書請見 Acceleration Whiplash。60% 是關鍵數字，來源為 Faros 的平台遙測資料。

門檻，而非斜率#

這之所以是個概念而非指標，是因為轉變悄然且結構性地發生了。最初的承諾是「人類掌舵，AI 提議，人類決定。」隨著模型進步、供應商野心增長，「副駕駛成了同儕」，接受率也逐漸超過人類仍能稱得上在創作的程度。沒有任何組織召集會議決定「AI 應該寫我們大部分的程式碼」；使用率只是一路上升（授權早已買好——改變的是使用方式，不是席位），直到某天，60% 被接受的程式碼都有 AI 作者。轉變發生在誰／什麼在做這份工作，人類「愈來愈多地扮演審查與監督角色，而非創作角色」。

這與 Fiona Fung 在 Anthropic 內部描述的角色倒轉相同，也呼應 Karpathy 對代理式工程的描述——但 Faros 提供了整個產業層級的數字，說明這種轉變已經走多遠，並將其視為問題，而非能力。

「這是作者問題，而非審查問題」#

這是報告最尖銳的結論。既然 AI 是作者，品質落差就源自生成階段，無法靠審查彌補：

「品質落差並未在審查時被抓出……明確地說，問題不在於誰審查程式碼，而在於送交審查的程式碼原本就還沒準備好。這是作者問題，而非審查問題。」

這重新界定了整套補救策略（見 Acceleration Whiplash）：增加審查者或收緊關卡，處理的只是症狀。解方是提高作者產出內容的品質——在 AI 作者動筆之前，就提供程式碼庫標準、架構意圖、安全限制和測試要求，讓它從一開始就產出更接近可發布的內容。這是作者責任版的左移：將品質投資一路前移到創作行為本身。

作者身分／責任落差#

作者身分轉移給了 AI；責任卻沒有。「你的軟體仍由你負責」（Karpathy），但產出 60% 程式碼的實體無法被追究責任，沒有對意圖的持續記憶，而且是從「某個時間點」推斷架構，而非理解程式碼庫如何演進。結果就是工業規模的複利式債務機制：作者每次工作階段都得重新推導意圖。Faros 的建議 #10——提供歷史意圖的「脈絡引擎」——試圖給 AI 作者人類作者不言自明就擁有的東西。

界線：創作與代理式創作#

Faros 劃出明確界線。AI 已是主要作者，但人類仍在迴圈中——然而代理式創作（代理程式自行撰寫、提交並送出 PR，沒有任何人類發起）仍不到 PR 的 1%。Faros 認為目前「這是好事」，並警告若完全移除人類，所有品質壓力都會「放大一個數量級」。因此這裡的「主要作者」指的是人類接受大多數由 AI 撰寫的程式碼，而非代理程式不受監督地發布。同時，代理程式審查已從 0% 升至 25% 的 PR——監督層自動化的速度快於創作層走向自主的速度。

Faros 自己的後續報告在六個月後（2026-09-22）更新了這三個數字。The Speed Trap（The Speed Trap: 8 takeaways from our latest AI engineering research，vendor-claim，同一個 22,000 名開發者的樣本）報告 AI 程式碼接受率為 65%（上文的 20%→60% 是前一份報告的讀數，適用於該報告涵蓋期間），代理程式審查在許多公司涵蓋 50–80% 的 PR（由 0%→25% 上升），而在領先群體中，代理程式開啟 13–14% 的 PR——相較於本文所說的「不到 1% 的 PR」。使用最後一個數字前，先留意三點：

• 分母不同。「不到 1%」是整體樣本的合併比例；「13–14%」則來自未明確說明的領先群體切片。不能把兩者合併成「代理式創作在某個族群中已達兩位數」，這正是本文開放問題的核心區別。
• 所有數字都是兩個高採用率期間之間的前後期變化，沒有 AI 與非 AI 對照群，也沒有公布「AI 輔助」的定義。Acceleration Whiplash 有完整探討這個構念。
• **本節所說的先後次序仍然成立，而且差距擴大。**審查的自動化仍遠遠領先創作——前沿群體中為 50–80%，相較於 13–14%——因此「組織讓代理程式批評程式碼，比讓它撰寫程式碼更自在」是此處唯一獲得 Faros 兩次讀數共同支持的主張。

非供應商在生產規模下量測的數字（2026-08）#

上文的 60% 來自 Faros 對客戶的平臺遙測。Tran 等人（Google，arXiv 2608.06640） 則從單一企業內部提供相同轉變的數據，empirical，採用創作當下的位元組層級來源追蹤，而非接受事件——對這個問題而言，這是整個資料集中最有力的測量工具，因為它完全避開事後歸因問題（AI 程式碼偵測器「跨模型及設定的泛化能力不佳」；來源追蹤是創作工作階段中記錄下來的屬性）。

2025 年 4 月至 2026 年 4 月，共有 352 萬筆已提交變更：

• 主要語言中，已提交程式碼的 AI 生成比例：28.99% 升至 68.62%（2025 年 4 月至 2026 年 3 月）。
• 以 C++ 為主、由 AI 產生的變更：27.65% 升至 59.69%；以人類為主的變更則從 72.10% 降至 40.04%——交叉點出現在這段期間內。
• C++ 整體月度比例從 28.56% 升至 62.80%；各組織採用程度不一，在 Machine Learning & AI 達 70.19%，在 Consumer Products/Apps/Devices 達 67.45%，部分切片則在初期採用後進入平台期。

除了佐證程度之外，這份研究還補充兩點。首先是RQ1 摘要本身的但書：開發者「在生成文字進入已提交程式碼分析前，會大量過濾」，因此即使來源追蹤比例達 68.62%，衡量的仍是經人類篩選後留下的內容；就本文第一個開放問題而言，這是整個資料集中最接近對「接受」作出有原則解讀的做法。

**其次，也是影響更深的一點：互動模式的組合在這段期間反轉。**從圖 3 的堆疊面積圖讀取——這是約略值，誤差約為正負 3 個百分點，因為論文文字中沒有列出各模式的數字比例——代理式編輯約從歸因位元組的 4% 升至 55%；行內補全則從約 28% 降至約 13%，貼上／智慧貼上程式碼則從約 54% 降至約 20%。手動輸入在整段期間維持約 7%。

謹慎看待這項結果與本文界線一節的關係，因為兩者的構念不同，很容易誤讀成矛盾。Faros 的「不到 1% 的 PR」計算的是代理式創作——代理程式在沒有人類觸發的情況下自行發起、提交並送出 PR。Google 的「代理式工作流程」類別則涵蓋對話式生成、轉換式編輯、自動測試生成和 AI 驅動的重構，全部都由人類發起。因此兩者可以同時成立：人類仍幾乎發起並送出每一項變更，但位元組的撰寫模式在一年內已從「提出建議再接受」轉為「下達指示再審查」。這是助理跨越成作者門檻在更底層再次發生，而這正是「接受」不再是開發者能明確執行的單一事件的層次。

第三種測量工具：開發者自述的比例（2026-08）#

DX 的 2026 年第二季讀數（vendor-claim，500 多個客戶組織）提供了同一項數量的另一種測量方式，也是知識庫先前欠缺的唯一一種：自我回報。其主要發現是，目前超過 50% 的程式碼由 AI 生成，比例從 2026 年第一季的 34% 升至第二季的 52%——單季增加 18 個百分點。

測量工具	構念	數列
Faros（vendor-claim）	指標平臺上的接受事件	20% 至 60%
Tran 等人（empirical）	創作當下的位元組層級來源追蹤	28.99% 至 68.62%（2025 年 4 月至 2026 年 3 月）
DX（vendor-claim）	自我回報的比例	34% 至 52%（2026 年第一至第二季）

**先後次序就是研究發現。**在時間重疊的期間，自我回報數字是三者中最低的——2026 年第二季為 52%，而截至 2026 年 3 月的來源追蹤測量為 68.62%。由於族群差異很大（一個跨產業客戶樣本，對上一個 C++ 單體式程式碼庫），這並非嚴謹的測量工具比較；但這個方向值得記錄，因為它與對供應商調查數字的直覺疑慮相反。此處的自我回報低估了實際情況，正如 Kalff 與 Simbeck 所說的構念混淆所預測：人們只計算自己辨識為 AI 的內容，而這段期間成長最快的模式——由開發者引導、代理程式套用的編輯，以及未經特別操作便接受的行內補全——恰好最不容易被算作「AI 生成的程式碼」。

因此，知識庫中有三個數字描述同一項轉變，但各自測量的對象都不同；在同一時間點，最高與最低數字相差約 17 個百分點。DX 沒有公布該數字的方法（報告須付費取得），因此詢問了誰、如何詢問、以何種單位計算，都不得而知。

相關連結#

• Acceleration Whiplash — 下游後果：接受率達 60% 的 AI 作者，正是湧入人類步調系統的來源

• Vibe Coding vs. Agentic Engineering — Karpathy 所說的「你的軟體仍由你負責」，是作者身分／問責落差中責任的那一半

• Verification as the New Bottleneck — 人類成為審查者而非創作者，正是 Fiona Fung 指出的瓶頸轉移；Faros 補充：「但你無法在審查階段修正創作品質」

• Agentic Technical Debt — 沒有持續意圖記憶的作者每次工作階段都要重新推導架構；「脈絡引擎」就是組織規模的 CLAUDE.md

• Software 3.0 — 以英文程式設計，正是 AI 得以成為作者的典範

• Claude Code — 代理程式模式（直接套用變更）被列為接受率從 20% 升至 60% 的主要推力之一

• Printing Press Software Democratization — 作者身分轉移給機器，是同一場民主化的供給面

• Compute Allocator — 若人類不再是作者，剩下的角色就是決定作者該把心力花在哪裡

• Planning / Execution Division of Labor — 表面上的矛盾已有解釋：Faros 的 60% 行數創作比例與 Anthropic 約 70% 的人類規劃決策比例衡量的是不同層次——Claude 撰寫大多數行數（執行），人類仍掌握大多數規劃。「沒有刻意決策」與「人類仍決定要打造什麼」都成立

• Agentic Coding Work-Composition Shift — 更多端對端的代理程式使用（操作／分析／撰寫），反映作者身分在使用面轉向代理程式；作者改變，工作也隨之改變

• Conversation-to-Delegation Shift — 將產出委派出去，就是作者身分轉移給代理程式；Codex 的輸出 token 比例（16.5%／63.3%／99.8%）呈現這種轉移在不同族群中的程度

• Conversation Artifacts — 產物讓作者身分轉移給模型這件事可以按對話量測；閱讀程度提升（Claude 的回答比提示高約一個教育年級）是衡量模型產出占比的其中一種方式

• Security Debt of Agent-Generated Code — 從安全面衡量作者身分轉移，但有一個讓這種說法更複雜的轉折：在代理程式撰寫的 PR 中，人類協作者仍提交了 67.6% 的真實外洩憑證；因此「代理程式是作者」不代表代理程式就是最嚴重產物的來源

• The Solo-Authorship Rebound — 科學領域也發生相同的作者身分轉變，但可見度正好相反。本文能以接受率和 PR 來源追蹤量測；而在那裡，依其設計便不可見。Matsui 的推論 1 說明了原因：貢獻聲明與合作網絡是推斷誰做了什麼的兩種工具；但若單人論文的執行工作由 LLM 提供，「貢獻代理程式既不會出現在作者名單，也不會出現在合作網絡中。」署名落差從未列名的人類，轉移到根本無法列名的機器——而單人作者就像接受 AI 程式碼的工程師一樣，為所有內容簽字負責

• Efficiency Debt of AI-Generated Code — 本文數字的非供應商、以來源追蹤量測的版本（跨語言從 28.99% 升至 68.62%），以及上文所述的互動模式反轉和作者身分轉移的下游成本：AI 密集型生產函式中的相對運算量開銷約為 5%，相對記憶體開銷約為 8%

• Agent Review Comment Resolution — 本文提到的監督層，其自動化速度快於創作層（代理程式審查的 PR 比例由 0% 升至 25%，相較之下代理式創作不到 1%），並以自身尺度測量：54,713 則代理程式生成的審查留言，約七成獲得處理。這是首次從整體族群層面觀察監督的機器端產出是否促使人類採取行動，也提醒我們：作者身分轉移給代理程式時，審查工作也跟著轉移，形成一個結果雙方參與者都不負責的迴圈

• Review as the Control Point — 這套理論的驅動因素，就是從審查輸入角度觀察到的作者身分轉移：數量／速度、表面可信度和程式碼不透明（意圖流失）。其中「呼叫代理程式的開發者，究竟是獨立審查者，還是審查自己作品的作者？」這項模糊之處會反轉獨立審查趨勢的方向，是本文「代理程式直接套用變更時，接受代表什麼？」在審查端的對應問題

• Post-Acceptance Edit Behavior — 將接受視為持續變化的狀態來衡量。DECODE（CMU，empirical）追蹤 1,141 名開發者在 IDE 內對已接受 AI 補全所做的 5.36 萬次編輯，研究的是本文所有數字下方的一層：接受的補全中位數有 63% 留存至其編輯軌跡結束，留存率呈雙峰分布（幾乎完整保留或直接丟棄），而 31% 的軌跡包含意圖為移除內容的編輯。因此，即使在人類確實採納建議的最強情況下，「接受」也不是終止狀態。從另一個方向也佐證作者身分的主張——開發者只新增最終程式碼的 20%，而在 36% 的最終狀態中，新增比例不到 5%；因此只要補全內容留下來，留下的就是模型撰寫的文字。它與此處其他所有研究處於不同層次：提交前、IDE 內、使用 2024 年款模型的行內自動補全，而非代理程式撰寫的 PR

• The Committed-Artifact Chain — 作者身分在程式碼上游轉移給代理程式：工作手冊讓代理程式以已提交的 markdown 草擬規格和計畫，人類則被降為修正者，因此「作者問題」從規格階段就已開始

延伸#

• Is Human Review of AI-Authored Code Still a Real Control, or Already Rubber-Stamping? — 將本文的「接受」拆成三類（肯定採納／經審查但未撤回／單純未撤回），並指出監督弱化訊號只出現在第三類

開放問題#

• 60% 的數字混合了差異很大的工具和模式（接受自動補全與代理程式套用差異）。當代理程式直接套用變更，而人類的「接受」只是沒有撤回時，「接受」代表什麼？Review as the Control Point 進一步深化了這個問題：在 GitHub 上，代理程式 PR 最常只由呼叫代理程式的開發者檢查（僅作者審查占 40.1%，人類 PR 則為 21.5%）。這是否算審查，是一項定義選擇（若代理程式是作者 ⇒ 有第二雙眼睛；若代理程式是工具 ⇒ 自我審查），而這項選擇會直接反轉趨勢方向——因此「接受」與「審查」變得模糊，成為同一個尚未解決的構念。部分回答：Is Human Review of AI-Authored Code Still a Real Control, or Already Rubber-Stamping?——依誰採取行動、誰檢查，將構念分成三類：肯定採納（人類套用建議）、經審查但未撤回（代理程式套用，另一位人類檢查），以及單純未撤回（代理程式套用，沒有人檢查——唯一算得上橡皮圖章的類別）。60% 混合了三者，因此無法回答監督是否真實存在；建議的指標就是這項分類，只有單純未撤回才視為監督弱化。尚未測量：任何資料集中這三類的實際比例。再度部分回答，從更底層切入（2026-08-12）：DECODE 衡量肯定採納這一類——分類中最明確的一類——並發現它並非終點。在開發者接受補全的軌跡中，31% 包含移除編輯，留存率呈雙峰分布，而中位數補全在一小時內已刪去約三分之一。這沒有提供各類比例，也沒有觸及兩種「未撤回」類別（其單位是人類套用的建議，而非代理程式套用的差異）。它能確定的是更狹義但有用的一點：接受是軌跡上的一個點，因此任何對接受的分類都必須附上時間範圍；而能觀察軌跡的測量工具，是提交前的編輯器遙測，而非 PR 層級的任何資料。
• 如果代理式創作從不到 1% 跨向兩位數，脈衝式震盪會在脈絡引擎工具成熟前變得難以管理，還是工具會因為壓力而成熟？2026-09-22 部分回答；坦白說，「兩邊都不是，但震盪換了位置」：Faros 自己的後續報告（vendor-claim）是首個觀察到觸發條件的來源——在領先群體中，代理程式開啟 13–14% 的 PR——並指出「可管理性」的兩個面向朝相反方向發展。每筆變更變得更可管理：每個 PR 的事件增幅從 +242.7% 放緩至 +14.5%；Faros 也明確表示，單次變更的品質不再持續崩落。整體而言則變得更難管理：每月事件數 +125.4%、QA 平均任務時間 +300.6%（資料集中惡化最嚴重的指標）、PR 規模 +71.8%，未審查合併指標則成長 +76.3%，高於先前的 +31.3%。因此，震盪並未如這則問題所假設的那樣變得難以管理——它從單項變更轉移到整個系統的吞吐量。這仍不能讓問題退場，原因有四：13–14% 與不到 1% 的分母不同（領先群體切片與整體樣本），因此尚未證明任何單一族群的比例確實跨越；「難以管理」從未在此定義門檻，沒有任何數字能提供門檻；報告完全沒有測量脈絡引擎的採用情況，因此二選一的後半部根本未經檢驗；而 Faros 對新主要壓力來源的解釋——重新啟動 +66.7%，解讀為代理程式脈絡不足——與前一份報告指向同一診斷、同一產品建議，也就是供應商先前的說法，而非工具是否成熟的測量。要解決此問題，需要在兩個期間內，以同一分母計算整體樣本的代理式作者比例，並搭配任何脈絡提供工具的採用指標。

資料來源#

• AI Engineering Report 2026: The Acceleration Whiplash — 執行摘要；發現 #1（採用）；「AI 現在是主要作者」
• The Speed Trap: 8 takeaways from our latest AI engineering research — The Speed Trap，Faros Research，2026-09-18，vendor-claim，與上列來源使用同一樣本的後續報告。只涵蓋重點 1：79% 每週使用 AI 工具，86% 的團隊每週活躍使用者比例超過 50%，AI 程式碼接受率 65%，許多公司有 50–80% 的 PR 使用代理程式審查，在領先群體中代理程式開啟 13–14% 的 PR。作者比例來自分母未說明的領先群體切片，不能與上文整體樣本不到 1% 的比例相提並論。所有數字都是兩個高採用率期間之間的前後期變化，沒有對照群，也未公布方法；完整構念探討見 Acceleration Whiplash
• 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（見 Sources）。僅涵蓋發現 1——500 多個客戶組織中自我回報的程式碼比例從 34% 升至 52%。報告未附方法說明且須付費取得，因此問題措辭、計算單位、受訪者族群及每季樣本數，知識庫都無法取得
• Characterizing the Quality Profile of AI-Generated C++ in Production — Tran 等人（Google，arXiv 2608.06640，2026-08-06），empirical：§3.2（創作當下的來源追蹤與推估）、§4.1（採用趨勢、組織差異、互動模式脈絡、開發者篩選的但書）以及直接檢視的圖 3——上文引用的模式比例是從堆疊面積圖讀取，論文文字中並未列出。證據說明與利益衝突見 Efficiency Debt of AI-Generated Code