AI 程式開發
5.5 萬則真實審查意見顯示：短而可直接套用的 AI 修補更容易被開發者採納
一項實證研究分析五種程式代理在 342 個 Python 儲存庫留下的 54,791 則審查意見，發現內嵌程式建議是意見獲得解決的最強預測因子。錯誤建議與忽略專案既有設計則是未解決討論的主要類型，但觀察性資料不能用來直接排名各家代理品質。
新研究不再只用人工建立的漏洞題測試 AI code review，而是追蹤開發者如何處理代理實際留在 GitHub pull request 裡的意見。研究者收集 Copilot、Cursor、Codex、Devin 與 Claude 在 342 個 Python 儲存庫產生的 54,791 則審查留言，比較意見是否被標記為 resolved、內容類型、留言形式，以及核心與周邊貢獻者的後續行動。
結果顯示，已解決留言中有 72.9% 來自 Copilot；這是樣本組成，不應解讀為 Copilot 有 72.9% 的解決率或必然優於其他工具。迴歸分析發現，附帶可直接套用的 inline code suggestion，是留言獲得解決的最強預測因素；篇幅較長、結構較複雜的意見反而較少被採取。核心開發者較常處理設計與可演進性問題，周邊貢獻者則更多回應功能缺陷，反映專案知識與權限位置會影響 AI 建議的落地方式。
團隊另對 470 段未解決討論進行開放式卡片分類，整理出十種模式，其中錯誤建議及開發者刻意維持既有設計最常見。這對建置審查代理的啟示是：最佳化目標不該只是「找出更多問題」，還要控制噪音、提供最小可套用修補，並取得 issue、測試與架構決策等專案脈絡。
限制在於研究只涵蓋 Python 公開儲存庫，resolved 狀態也不等於建議正確或已合併。不同代理的上線時間、使用量、預設介面與儲存庫選擇可能形成混雜因素；後續仍需配合實際 diff、測試結果及隨機化實驗，才能比較工具本身的審查品質。