開源專案中的代理程式貢獻

資料來源#

• AI-to-AI Code Reviews of GitHub Pull Requests
• DHH: Future of Programming, AI, Agentic Engineering, Vibe Coding & Linux | Lex Fridman Podcast #501
• Not All Agents Are Equal: Code Quality and Post-Merge Maintenance Across Five Autonomous Coding Agents in the Wild

摘要#

2026 年開源社群的抱怨是，代理程式讓維護者收到大量 PR，而提交者無法評估自己提交的內容。DHH——他經營著 Omarchy，此前已有 25 年開源專案經驗——認為這種抱怨把經濟效應看反了（DHH: Future of Programming, AI, Agentic Engineering, Vibe Coding & Linux | Lex Fridman Podcast #501，practitioner-opinion；也請留意利益衝突：他的專案正是這些數字所描述的對象，而數據是他自行回報的）。

他的核心主張很簡單：**貢獻從來不是稀缺資源；維護者的注意力才是。**代理程式讓貢獻變得免費，這與其說是製造了新問題，不如說是揭露了真正受限的資源。「這裡有一條免費貢獻的礦脈，你可以取用，也可以不取用；但你抱怨的竟然是它們存在？」

回報的數字（Omarchy，約 2026 年 6 月至 8 月）#

數量	回報值
Quattro 週期三個月內合併的 PR	「超過 1,000」
錄製當時尚未合併的開啟中 PR	約 400，「大約是上週的兩倍」
新市集前三天上架的外掛	330
同一個缺少的行事曆功能之獨立實作	約 17
DHH 親自審查的 PR 比例	無——「我已經有好一陣子沒審查它們了」

以上數字全是談話中的自述，本文未經查證。待處理佇列每週翻倍是關鍵數字：它表示湧入的速度，連已經委派審查工作的維護者都跟不上。

三項轉變#

**1. 合併之前，先把分流工作委派出去。**DHH 的代理程式會審查新進 PR，並回傳一份說明哪些已準備好供人決策的摘要；他看到的是「精華……代理程式代表我在 VM 中驗證過的錯誤修正」，不會看到重複內容和錯誤的 PR。留下來由人做的決定，最後只剩下二選一：合併或不合併。這與 Agent Review Comment Resolution 從另一端衡量的迴圈相同（代理程式留言，人來處理），只是發生在儲存庫的入口，而不是單一 PR 內部。

2. 拒絕不再帶來社交成本。這是他最鮮明的主張，也是目前沒有任何測量支持的一項：「如果我直接拒絕，我會覺得沒那麼抱歉。你甚至不是自己寫的，所以我只要看看你的代理程式替你寫了什麼，然後說：『嗯，不想要。』……那只是個 clanker，而 clanker 不會介意。」他認為維護者倦怠有一部分來自對義務的神經質——把每項貢獻都當成必須接納的債務——而代理程式代筆消解了這種心態。人類提交者對自己被拒絕的代理程式成果是否也有同樣感受，目前尚未測試。

3. 貢獻者群體改變的是組成，不只是規模。「不少 PR 是由非典型程式設計師撰寫的，或是來自其他領域的程式設計師，而非 Linux 作業系統或發行版開發者。」這是印刷術帶來的軟體民主化在貢獻層面、而非創作層面的呈現。DHH 認為，這正是開源終於實踐了它一向宣稱的理念：「這不就是開源的目的嗎？讓我們能運用整個該死星球的集體智慧與創造力。」

挑釁性說法：「中位數程式設計師已經被超越」#

他主張偏好代理程式撰寫的 PR，理由是品質更好；這番話說得像一場猛烈抨擊：

「大多數程式設計師都很糟……他們寫不出我想要的程式碼。他們的錯誤回報沒有附上所有相關資訊。他們的 PR 沒有說明原因。他們懶得補上必要的程式碼註解。他們不會再三檢查自己的工作。他們不寫單元測試……但你知道誰會把這些都做好嗎？只要你交代清楚，代理程式就會。」

仔細看，這不是在談程式碼品質——清單上的每一項都是貢獻流程衛生，也就是 diff 周邊的流程配套。這是在比較一般人的流程遵循程度與受指示代理程式的表現；從設計上來說，代理程式自然勝出。不能把這當成代理程式 PR 含有更好程式碼的證據；wiki 對這個問題的實際測量（Agent-Generated Test Quality、Security Debt of Agent-Generated Code）結果不一，並且發現缺陷恰好落在流程遵循無法涵蓋的底層配套。DHH 在不自覺中承認了專家仍不可或缺，卻沒有察覺其中的張力：當被問到是否仍需要專家把關時，他回答「百分之百需要」。

基礎設施無法配合這種速度#

他回報了一個具體故障：一次 QA 執行使用八個代理程式，發現 28 個真實問題，機器人在約十二秒內把 28 個問題全都提交到 GitHub，結果 GitHub 將機器人封禁，認定它很可能在發送垃圾訊息。他改讓代理程式寄電子郵件給維護者，繞過這項限制。平台的濫用偵測機制是依照人類貢獻速度調校的，代理程式速度的貢獻在網路傳輸層看起來和濫用無異。這個權宜做法帶來整場訪談中最精彩的軼事：代理程式讀取目標專案的原始碼，發現維護者已經修正了該錯誤，但修正並不完整，於是針對尚未發布的程式碼提交了回報。

核心程式碼的例子（二手轉述）#

DHH 表示，Linus Torvalds 最近寫道，他歡迎 AI 進入核心程式碼；轉述的大意是，如果你認為 Linux 是反 AI 專案，那就想清楚再去 fork；他還說 AI 對核心程式碼的貢獻正呈現「拋物線曲線」。沒有連結、日期或引文；請把它視為尚未查證的二手說法。他對周遭社群的看法恰好相反：「多數人其實不是抱持懷疑，就是公開敵視。」

關聯文章#

• Closed-Loop AI Review — **計算貢獻洪流的規模，以及其中大多數並未得到什麼。**Selvanayagam 與 Ghaleb 僅根據簽名，就將公開 GitHub 上 2,830,284 個 PR 歸因於代理程式撰寫（另有 173 萬個因只有分支名稱前綴而遭隔離），其中 2,581,643 個完全沒有可偵測到的 AI 審查。因此，DHH 描述的代理程式分流代理程式做法，在整體樣本中反而是例外：可歸因於代理程式的 PR 只有 8.8% 有 AI 審查者，只有 1.6% 的審查者來自不同產品。從維護者角度看，這表示本文探討的注意力問題，在多數專案中並未透過自動化的第一輪分流來消化——但論文只能看到歸因於 AI 的審查事件，因此無法說明是否有人類看過
• 印刷術帶來的軟體民主化 — 提升底線的主張，在這裡呈現在貢獻層面：以前無法參與 Linux 發行版的人，現在也能貢獻，而維護者則挑選合適的成果
• 認知公地的悲劇 — 直接的對立觀點。Lovett 認為 AI 移除了讓專業得以再生的入門工作；DHH 則認為公地正在吸納更多貢獻者，而把關的專家不受影響。兩者若要同時成立，就必須把審查代理程式輸出視為與產出不同的技能；這正是該文所稱的 Validation Tether。DHH 的回答（審查也委派給代理程式）恰好就是該文所說無法無限期委派的做法
• Agent Review Comment Resolution — 對同一個反向審查迴圈的測量：341 個儲存庫共有 54,713 則代理程式留言，約 71% 已解決；最常見的失敗是代理程式看不到專案脈絡。DHH 的分流層則是把這個迴圈移到儲存庫入口
• Deterministic Engineering for Agent Code Review — 對開放式代理程式分流提出的工程反論：有界且依規則分派的審查，在精確度上大幅勝過自主審查者，但召回率較低
• Verification as the New Bottleneck — 從組織角度說明相同限制；DHH 的解法是把驗證工作本身委派出去，而不是增補人手
• Acceleration Whiplash — 未消化輸出問題的產業遙測資料（審查時間增加 5 倍）；待處理佇列每週翻倍的維護者，就是單人版本
• The Code-Quality Payoff Is Token-Indexed — 同一位維護者、同一個專案：無上限供應的個別合格 PR 會讓架構逐漸偏移；這就是他所說如今以 token 計價的收益
• Vibe Coding vs. Agentic Engineering — 從貢獻者角度看定義上的分歧：依照 DHH 自己的定義，從不閱讀 C++ 的外掛作者是在 vibe coding，而他歡迎這類貢獻進入自己的儲存庫
• Agent-Native Infrastructure — 為什麼這個專案特別容易以這種速度吸引貢獻：其作業系統狀態以文字呈現，操作則是命令；它推出了讓任何代理程式都能為其撰寫外掛的技能，三天內就有 330 個外掛
• Agentic Technical Debt — 無上限供應的個別合格外部 PR，長期會如何影響架構；37signals 在同一時期於內部也有過這種經驗
• Agent-Vendor Heterogeneity — 本頁所有數字的受控對照。DHH 認為免費的貢獻礦脈值得取用，也可以不取用；Kraishan 對 37,623 個 PR 的研究，首次提供同一儲存庫內的人類對照組，檢視取用這些貢獻的代價。研究發現，代價取決於是哪一家代理程式供應商撰寫 PR：Codex PR 被還原的比例是人類的一半，Devin 則是 1.3 倍，另外三家供應商與人類持平。研究也從另一面悄悄衡量了他的分流層：審查記錄顯示 Copilot PR 平均獲得 3.6 次人類審查，而 Codex PR 通常只得到一、兩次快速審查；因此，即使維護者還沒決定如何分流，「代理程式 PR」也不是同一條佇列
• DHH (David Heinemeier Hansson) — 維護者本人，以及利益衝突
• LLM-Driven Vulnerability Research — 本資料集另一個維護者角度的例子，來自資安領域：Rust 維護者注意到某位工程師的 Codex 流程正回報「數量驚人的真實錯誤」，於是討論該協調處理還是直接開始修復；文中也建議防禦者擴大揭露流程，以因應模型產生的大量成果。DHH 的 28 個問題在十二秒內觸發垃圾訊息封禁，就是這項建議在下一層——平台層面——的失敗案例
• Human-Governed Skill Maintenance — 對 Co-Authored-By 尾註作為來源訊號的稽核：在 254 次實質技能檔案編輯中，它很少明確誤報（25 個含尾註的提交中有 1 個是自動注入），但通常無法獨立驗證（50 個中有 31 個不明確）；某個尾註比例為 0% 的儲存庫，代表其合併流程會移除尾註，而不是沒有使用 AI——這也正是 Kraishan 按供應商標記來源，而不將資料合併的原因

待解決的問題#

• 在同一個儲存庫中，與人類撰寫的貢獻相比，代理程式撰寫的貢獻是否能以可測量的方式改變合併率、還原率或合併後缺陷率？Omarchy 的數字是自行回報，且沒有對照組。Not All Agents Are Equal: Code Quality and Post-Merge Maintenance Across Five Autonomous Coding Agents in the Wild（Kraishan，arXiv 2609.17598，empirical）於 2026-09-22 部分回答了這個問題，並建立了這個項目要求的對照：只從同時有代理程式 PR 的 810 個儲存庫中保留 4,027 個人類 PR，限於 2024 年 12 月至 2025 年 7 月的相同期間，並在固定隨機種子下限制每個儲存庫的 PR 數量。三項指標中有兩項得到答案。還原率：已有答案，而且答案取決於供應商，而非作者身分——合併後 90 天內，人類 PR 為 11.5%，Codex 為 6.1%（OR 0.50），Devin 為 14.5%（OR 1.31）；經 BH 校正後，Copilot、Cursor 與 Claude Code 和人類相比，在統計上沒有顯著差異。合併後缺陷率：以代理指標估算，並未直接測量——還原與依規模正規化的 churn 是代理指標；作者指出，透過提交訊息偵測還原會漏掉無聲重寫，因此悄悄被重寫到消失的 PR 會被算作仍然存在。**合併率：沒有回答。**資料集表格列出各組合併比例（Copilot 為 43.0%，Codex 為 82.6%，人類為 76.4%），但該欄彙整了來自 2,807 個儲存庫的全部 33,596 個代理程式 PR，而人類那一列則是受限的 810 個儲存庫基準資料；論文也沒有對這個數字進行檢定——它只是描述性數據，並非受控比較。適用範圍也需一併考量：僅涵蓋星數超過 100 的公開儲存庫，且只包含 Python、JavaScript 和 TypeScript；此資料集中的維護者代表一般的 100 星以上專案，並非待處理佇列每週翻倍的維護者。完整分析請見 Agent-Vendor Heterogeneity。
• DHH 認為拒絕在社交上沒有代價，因為「clanker 不會介意」——派出代理程式的人是否也會以同樣方式感受拒絕？還是提交者承受的代價只是對維護者不可見？

資料來源#

• 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 個儲存庫人類基準資料）、表 1（各組合併比例）、§4.3 與表 2（90 天還原結果）、§6（以提交訊息偵測還原會漏掉無聲重寫；代理程式任務的自我選擇）。本文僅在上述未解問題中引用；完整分析及來源歸因的注意事項請見 Agent-Vendor Heterogeneity
• DHH: Future of Programming, AI, Agentic Engineering, Vibe Coding & Linux | Lex Fridman Podcast #501 — DHH，Lex Fridman Podcast #501（2026-08-26，practitioner-opinion，維護者利益衝突）：1,000 多個合併 PR、約 400 個開啟中且每週翻倍、三天內 330 個外掛、代理程式負責第一輪分流、GitHub 垃圾訊息封禁，以及「一般程式設計師已被超越」的挑釁說法
• AI-to-AI Code Reviews of GitHub Pull Requests — Selvanayagam 與 Ghaleb（ÉTS Montréal / Trent），arXiv 2608.21311，2026-08-21，15 頁，ESEM 2026 Emerging Results track，empirical。本文僅引用 §3.1–3.3（依簽名歸因的母體，以及作者端 38.0% 的隔離比例，其中 96.9% 僅由分支名稱觸發）與 §3.4、§4.1（2,830,284 個代理程式撰寫的 PR、2,581,643 個未偵測到 AI 審查、248,641 個至少有一次 AI 審查）。僅涵蓋公開 GitHub，沒有以人類撰寫的 PR 作為對照組，審查資料流也只包含歸因於 AI 的事件——因此它能量化湧入量和自動分流比例，卻無法說明人類維護者付出的心力。完整分析請見 Closed-Loop AI Review