人們對 AI 可能對開源造成的影響有個普遍的恐懼。程式碼代理會搶走原本適合初學者的議題,這些議題本來是幫助新貢獻者入門的;它們產生的程式碼更難維護,最終導致新維護者的管道枯竭。這聽起來似乎合理。但根據最新研究,這似乎並不是實際發生的事。

北京大學於 7 月 2 日提交至 arxiv.org 的研究追蹤了 1,888 個採用 AI 程式碼代理(例如 Cursor 與 Claude Code)的 GitHub 儲存庫,觀察這些專案在 AI 進入工作流程後的變化。研究團隊將採用定義為專案首次提交代理設定檔(如 .cursorrules 或 CLAUDE.md)的時間點,然後將這些專案與一組從未採用的對照組進行比較。

他們使用了差異中的差異法(difference-in-differences),這基本上是用來區分工具實際造成的影響與專案在採用工具前就已存在的趨勢的最佳方法。而他們的發現是……沒有太大變化。新手參與度持平或略有上升。在最保守的統計規格下,他們發現的最壞情況是 1.5% 的下降,且未達到統計顯著性。

複雜度上升,貢獻者穩定

​​圈複雜度(Cyclomatic complexity,用來計算函式中獨立路徑的數量)在採用後所有語言皆上升 3% 至 4%。認知複雜度(Cognitive complexity,這項更嚴格的指標會懲罰高度巢狀邏輯與糾結的控制流程)在 Python 專案中上升約 11%。這聽起來不妙,但若與去年發布的卡內基美隆大學研究相比,該研究發現 Cursor 採用導致同一指標上升 41%。北京大學團隊因採用更大規模且更成熟的專案集,並使用更嚴格的統計控制,最後得出的估計值約為先前研究的四分之一。

但這項研究真正有趣的地方在於,研究團隊並未僅將複雜度與新手參與度視為兩個獨立的發現,而是將分析鎖定在 128 個 Python 專案(這些專案的複雜度確實上升)上。

在這些相同的儲存庫中,新手加入並未下降,留存率維持穩定,活躍貢獻者人數反而增加。這兩種效果都是真實的,但似乎並無關聯。AI 產生的程式碼變得有點複雜,但這種額外的複雜度似乎並未阻礙新手,至少在本研究發現的程度內是如此。

AI 產生的程式碼變得有點複雜,但這種額外的複雜度似乎並未阻礙新手,至少在本研究發現的程度內是如此。

研究排除的範圍

有一些重要的限制。最大的問題是這項研究聚焦於已建立的開源專案。採用 AI 程式碼工具的儲存庫中,近三分之二幾乎在專案建立後不久就採用了,因此研究人員無法取得有意義的 AI 前基線進行比較。這些儲存庫被排除在主要分析之外,分析改以 603 個在導入 AI 前至少有六個月歷史的專案為主。

研究人員也檢視了完整資料集,其中新手參與度似乎下降。但仔細觀察後發現,這些專案在採用 AI 前就已經流失貢獻者,因此無法將下降歸咎於工具本身。

測量採用的盲點

還有另一個限制。這項研究是透過尋找與 Cursor 等工具相關的設定檔來衡量 AI 採用,而非追蹤開發者實際使用這些工具的頻率。這意味著它可以告訴我們專案採用 AI 後發生了什麼,但無法得知 heavily 依賴 AI 的團隊與僅實驗性使用的團隊是否經歷不同結果。

GitHub 表示,平台上合併的 pull request 數量已從 2023 年初的每月約 2,500 萬筆,成長至今日的每月約 9,000 萬筆。

GitHub 也開始做出回應。該公司最近針對外部貢獻者同時開啟的 pull request 數量設下限制,並推出新工具幫助維護者整理日益增加的審核佇列。

排擠恐懼,目前已被暫時解除。

這帶給我們什麼啟示

排擠恐懼,目前已被暫時解除。在已建立的開源專案中,以目前的採用程度來看,AI 代理並未將新手推出門外。然而,pull request 數量已接近四倍成長。這些 PR 中送來的程式碼變得有點複雜。提交者可能無法完全理解自己提出的內容。而所有這些都落在維護者身上,他們的人數成長速度遠遠跟不上。

研究人員表示,未來研究應探討專案對 AI 程式碼工具的依賴程度,並找到更好的方法來研究那些實質上「與 AI 同時誕生」的儲存庫。這些都是重要的下一步。但目前最迫切的問題不是 AI 是否改變了誰來貢獻,而是它是否改變了長期維護開源專案所需付出的努力。

不是 AI 是否改變了誰來貢獻,而是它是否改變了長期維護開源專案所需付出的努力。

YOUTUBE.COM/THENEWSTACK

科技發展迅速,別錯過任何一集。訂閱我們的 YouTube 頻道,收看所有 podcast、訪談、示範與更多內容。

Group Created with Sketch.