作者：Martin Monperrus，瑞典斯德哥爾摩KTH皇家理工學院，電子郵件：monperrus@kth.se

摘要 — 自1976年Fagan將程式碼檢查正式化以來，程式碼審查一直是軟體開發中的主要品質把關機制。五十年來，在合併程式碼之前由同事人工檢查和評論，一直是各種規模組織的基石實務。編碼代理系統（coding agents）是一種基於大型語言模型（LLM）的自主系統，能夠讀取、編寫、測試和修復軟體。我們主張，編碼代理系統已跨越了一個能力門檻，傳統的人工程式碼審查不再是軟體品質流程中的必要環節。我們的論點基於兩個主張：程式碼審查的每個既定目標，都可以由代理系統以更低的成本和更高的效率來達成；而由代理系統編寫程式碼、人類仍是強制性審查者的這種簡單整合模式，是一個死胡同，因為它既無法提供有意義的保證，也無法跟上AI輔助開發的效率規模。

一、前言

程式碼審查是現代軟體開發中主要的人工品質把關機制。自從Bacchelli和Bird調查了微軟（Microsoft）的實務[1]，以及Sadowski等人在Google記錄了這項做法[2]後，該領域普遍認為程式碼審查服務於四個重疊的目標：在程式碼進入生產環境前發現缺陷、強制執行程式風格和慣例、在團隊成員之間傳遞知識，以及建立對不斷演進的程式碼庫的共同認知。沒有哪個認真的軟體團隊會省略這一步。

然而，程式碼審查所帶來的巨大成本常常被低估。大型組織的開發人員會花費百分之十到十五的工作時間來閱讀和評論他人的程式碼[2]。從提交拉取請求（pull request）到收到可付諸行動的回饋，這段審查延遲通常會超過二十四小時，甚至可能長達數天，對持續交付流程構成了結構性的阻礙[3]。除了時間成本，審查還會產生社交摩擦：語氣衝突、資歷偏見，以及廣為人知的現象——首次貢獻者在收到批評性回饋後，傾向於放棄專案[4], [5]。

在這樣的背景下，編碼代理系統應運而生。像Claude Code、Codex和GitHub Copilot這類基於大型語言模型（LLM）的系統，現在能夠在不需要人類指示的情況下，讀取和修改檔案、執行測試套件、解讀編譯器輸出，並迭代式地修復錯誤[6]-[9]。在SWE-bench（一個從熱門Python函式庫中提取的、真實且未經修改的GitHub議題所構成的基準測試）上，最先進的代理系統能夠端到端地解決超過百分之八十的任務[10]。關於基於LLM的程式碼審查研究顯示，代理系統能夠產生與受過訓練的人類審查者品質相當的行內缺陷評論[11], [12]。

在本文中，我們提出一個強烈的主張：編碼代理系統已達到一個能力門檻，在此門檻下，人工程式碼審查是多餘的，應被代理驅動的驗證所取代。我們不呈現新的實證研究；而是綜合現有的能力證據，並列舉其對軟體工程實務、工具和研究的影響。具體來說，我們認為代理系統能夠滿足審查既定的目標；由代理系統編寫程式碼而人類仍是強制審查者的中間過渡模式是不穩定的；對於例行性變更，強制性人工檢查的經濟效益已經轉為負面。

總結來說，我們的貢獻如下：

我們證明了程式碼審查的每個既定目標——缺陷偵測、風格強制執行、知識傳遞和團隊共同認知——都可以由編碼代理系統以比人類審查者更低的成本和更高的效率來達成。

我們論證了將AI程式碼生成與強制性人工審查相結合，並非穩定的終點：它製造了一種獲得保證的假象，同時將審查容量轉變為下一個交付瓶頸。

我們的成本效益分析顯示，強制性人工檢查的優勢已經翻轉；代理審查是即時的、一致的和可稽核的，而隨著代理能力的增長，人工審查的邊際缺陷偵測價值正在縮減。

二、背景

A. 程式碼審查：歷史與實務

程式碼審查作為一門正式的工程學科，起源於Fagan在1976年發表關於IBM程式碼檢查的論文[13]。Fagan提出了一個結構化、多階段的流程：規劃、概述、準備、檢查、重工和追蹤。這個流程被認為成本高昂，需要耗費高達總專案人力的百分之三。

關於現代程式碼審查有效性的實證記錄，其實比這種做法被普遍採用的情況更為微妙。Bacchelli和Bird發現，缺陷偵測雖然是主要動機，但並非審查者最可靠提供的東西：風格修正、微小的改進以及對意圖的提問佔據了評論內容的主導地位[1]。Czerwonka等人得出了一個尖銳的結論：微軟的程式碼審查在捕捉深層邏輯層面的缺陷上「找不到錯誤」；它們的主要價值在於知識傳遞和可維護性的改善[14]。知識傳遞和社交互動在跨研究中，持續被視為審查互動的寶貴成果[1], [4]。

目標1：錯誤與缺陷偵測

含義1：合併工作流程重新設計為代理在迴路中的關卡

主張1：所有審查目標都由代理以更低的成本滿足

目標2：安全分析

含義2：團隊角色轉變為規範制定者和協調者

主張2：對代理程式碼的人工審查是瓶頸所在

結論：代理審查取代強制性人工程式碼審查

目標3：程式碼品質

含義3：開源與新人引導的回饋迴圈壓縮

主張3：人工審查的成本效益平衡已經翻轉

目標4：知識傳遞

含義4：針對代理審查的CI/CD、IDE和平台工具

目標5：標準遵循

圖1. 本文的論證地圖。審查目標支持三項主張，這些主張導向結論，而結論則衍生出對實務和工具的四個含義。

B. 自動化程式碼審查

將程式碼審查自動化的努力早在大型語言模型出現之前就已開始。早期的方法依賴於模式匹配、基於規則的檢查器，以及在審查評論語料庫上訓練的機器學習分類器，用來預測一個變更是否會招致評論，以及該評論會說些什麼。這些系統各自獨立地自動化了審查活動中的某些環節：評論預測、變更檔案的優先級排序、特定缺陷類別的偵測。

大型語言模型（LLM）時代開啟了新的可能性。CodeReviewer[11]在一個龐大的拉取請求差異（diff）和相關審查評論的語料庫上預訓練模型，在評論生成、程式碼優化預測和嚴重性分類方面取得了有競爭力的表現。LLaMA-Reviewer[15]應用參數高效微調來使通用型LLM適應審查評論生成任務，證明了透過微調可以達到強大的審查表現。Tufano等人[16]建立了一個從差異到優化修補程式的端到端流程，顯示模型既能生成審查評論，也能產生修正後的程式碼，從而在審查-修改循環中省去了一次往返。Pornprasit和Tantithamthavorn在產業環境中評估了這些及相關的系統，發現它們對各種缺陷類型都有著有意義的覆蓋率[12]。Tang等人引入了CodeAgent[17]，一個多代理系統，其中專門的、具備溝通能力的代理彼此協作來執行程式碼審查，這將自動化的界限從單一模型的評論生成，推向了協調式的代理工作流程。這些系統的共同點是，它們專注於在一個仍由人類主導的審查工作流程中，將某些活動自動化；它們在不質疑整體審查關卡是否必要的情況下，提高了特定步驟的效率。

據我們所知，本文是首次主張由編碼代理系統完全取代強制性人工程式碼審查，並探討其對工作流程、工具和研究所帶來的影響。

C. 編碼代理系統

一個編碼代理系統是這樣一個系統：一個大型語言模型（LLM）被嵌入到一個代理循環中：該模型可以調用工具來讀取和寫入檔案、執行shell命令、運行測試、查詢文件，然後不斷迭代，直到達成目標或滿足停止條件為止。LLM提供語言理解、程式碼合成和情境推理能力；工具循環則提供了在軟體產品的實際狀態及其執行上的基礎。

具代表性的代理系統包括：OpenAI Codex[18]，一個建立在GPT系列模型之上的互動式助手；Claude Code[19]，一個直接在開發者終端機中運作的代理編碼助手；SWE-agent[6]，它引入了一個針對儲存庫規模的軟體工程任務而最佳化的代理-電腦介面；Devin[7]，一個能夠自主瀏覽程式碼庫並部署修復的商業系統；以及GitHub Copilot[9]，它將代理能力直接整合到拉取請求工作流程中。

三、代理能力的證據

為了支持編碼代理系統能取代人工程式碼審查的主張，我們調查了三個維度的代理能力證據：軟體工程任務的基準測試表現、審查特定能力，以及開發者在使用已部署工具時的生產力。

A. 基準測試表現

代理能力最直接的證據來自SWE-bench，這是一個基準測試，用於評估一個系統是否能解決從熱門開源Python專案中提取的真實、未經修改的議題[10]。與合成的程式設計挑戰不同，SWE-bench的任務需要理解議題描述、瀏覽多檔案儲存庫、修改正確的檔案，並產生能通過專案現有測試套件的修補程式。早期的結果令人清醒：GPT-4搭配基於檢索的情境選擇，大約只能解決1.7%的任務。SWE-agent透過引入一個能結構化模型與檔案系統和shell互動的代理-電腦介面，將這個數字提升到大約12.5%[6]。到2024年底，在SWE-bench Verified（一個經過驗證、具有可靠真實解決方案的策劃子集）上表現最佳的系統，其解決率已超過50%。到2025年底，公開排行榜上的頂尖代理系統解決了超過70%的任務[20]。這條進步軌跡，在大約兩年內從不到百分之二提升到超過百分之七十，在自動化軟體工程工具的歷史上是史無前例的。

相關的證據來自鄰近的任務。例如，Xia等人證明，基於LLM的修復方法在性能上大幅超越了早期的生成-驗證系統，如GenProg[21], [22]，能夠修復更大比例的基準錯誤，而無需手動指定測試案例或修復模板。在競技程式設計層面，AlphaCode在Codeforces競賽中的排名進入了人類參賽者的前54%[23]。這證明了LLM能夠對非平凡的演算法問題進行推理。

B. 審查特定能力

除了通用軟體工程之外，有幾個研究方向特別針對程式碼審查所需的能力。Pornprasit和Tantithamthavorn在產業環境中評估了基於LLM的自動化審查，發現代理系統能偵測到與人類審查者目標相同的缺陷類別：正確性錯誤、安全弱點、性能低下和風格違規[12]。Li等人證明，CodeReviewer在相當一部分的評估集上，產生的可操作行內評論，其品質至少可與受過訓練的人類審查者相媲美[11]。

代理系統帶來了人類審查者在結構上無法比擬的能力。人類審查者閱讀一份差異；而代理系統可以同時將完整的檔案、完整的測試套件、每個被觸及函式的git歷史記錄以及專案文件都放在情境（context）中。人類審查者可以識別一個問題並在評論中描述它；而代理系統可以識別問題、生成修復方案、應用它、執行測試，並在不需要任何人類排程的情況下關閉審查循環。人類審查者有日曆、時區和有限的注意力；而代理系統則持續運作，在週日凌晨3點與在週一上午的衝刺會議中，都運用著同樣的審查標準。這些是結構性的優勢，隨著軟體開發的規模和速度增加，這些優勢只會更加明顯。

四、程式碼審查的終結：我們的論證

A. 主張1：程式碼審查的每個目標都可以由代理系統以更低的成本和更高的效率來滿足。

Bacchelli和Bird指出了程式碼審查的四個主要目標：缺陷偵測、風格和標準強制執行、知識傳遞，以及團隊共同認知[1]。我們認為，當代的編碼代理系統在滿足每個目標上，至少和人類審查者做得一樣好，而且在幾個維度上明顯更優。

缺陷偵測：人類審查者善於識別表面層次的問題，但在捕捉深層邏輯錯誤上則不可靠[14]。相較之下，由大型語言模型驅動的代理系統可以執行詳盡的資料流推理，交叉引用完整的測試套件，並應用從數百萬個開源儲存庫中學到的模式。近期研究顯示，基於LLM的審查系統能夠產生與受過訓練的人類審查者品質相當的可操作缺陷報告，同時對每次提交（commit）進行無疲勞、無時區限制的審查[11], [12]。

風格和標準強制執行：程式碼檢查工具（linters）、格式化工具（formatters）和型別檢查器早已能自動處理語法和風格上的問題。代理系統將這種能力擴展到語意風格：命名一致性、符合語言習慣的API使用方式，以及文件慣例，都可以透過基於LLM的重寫來強制執行，從而消除了一整類的審查者評論。

安全性：安全審查正是人類注意力最為過載且後果最為嚴重的領域。Pearce等人證明，GitHub Copilot會以不可忽視的比率引入常見弱點列舉（CWE）的違規[24]，然而，當同樣的生成能力被重新導向至偵測時，它卻能讓代理系統比進行臨時審查的開發者，更有系統地列舉出各種弱點類別[25]。基於AI的安全掃描器在標準弱點基準測試上，其表現已經優於許多人工作業的審查者[26]。

知識傳遞：代理系統可以在合併時，主動生成隨需應變的解釋、架構摘要和更新的文件，這是一種比忙碌同事的附帶評論更可靠、更具擴展性的知識傳播機制。

B. 主張2：天真的整合模式——AI編碼搭配人工審查——是一個死胡同。

大多數組織面對AI編碼工具崛起的第一反應如下：由代理系統編寫程式碼，由人類進行審查。這種安排感覺保守且安全。我們認為它在兩個獨立的基礎上都是失敗的。

人工審查無法提供真正的保證。傳統上，程式碼審查的合理性建立在一個默認的假設之上：人類開發者編寫程式碼，而人類審查者提供獨立的檢查。當程式碼由代理系統生成時，這個假設就崩潰了。一個大型語言模型可以產生數百行看起來合理、內部一致的程式碼，但其中卻包含著微妙的語意錯誤——這些錯誤若不執行完整的測試套件，或進行只有代理系統才能系統化執行的詳盡資料流分析，是無法察覺的。人類審查者看著螢幕上的差異，他們很難有足夠的準備去捕捉AI生成程式碼中可能包含的錯誤。實際上，對代理生成程式碼的審查變成了橡皮圖章：人類批准，因為程式碼看起來正確，因為測試通過了，也因為進行真正審查的認知成本高得令人卻步[14]。審查理應提供的保證其實是一種幻覺。

人工審查無法擴展。AI編碼工具提高了開發者的吞吐量。一位由代理協助的開發者，每天產生的提交、拉取請求和變更程式碼行數，都比未受協助的開發者多[27]。然而，人工審查的容量並不會隨之擴展，其結果就是一個與AI編碼所帶來的生產力增益成比例增長的瓶頸。那些部署了AI編碼工具卻仍保留人工把關審查的組織，將會發現審查佇列變成了他們交付流程中的約束性限制。代理系統編寫得越快，佇列就變得更長，審查就越退化成在時間壓力下進行的一種形式。在這種情境下保留人工審查，並不能保護品質；它反而同時拋棄了AI編碼的生產力好處和真正審查的品質好處。

邏輯上一致的步驟是關閉這個循環：由一個獨立的代理系統來審查代理生成的程式碼，只有當代理系統標示出不確定性，或是某個變更跨越了明確的風險門檻時，人類才介入。

C. 主張3：成本效益的計算已經翻轉。

程式碼審查帶來了可衡量的成本：大型組織的開發者花費10-15%的工作時間在審查程式碼上[2]，而審查延遲則為持續交付流程帶來了延誤[3], [28]。這些成本在過去被審查所捕捉到的缺陷所合理化。但隨著代理系統的覆蓋範圍增長，這種合理性正在減弱。

試想人類審查評論的邊際價值。隨著代理系統以越來越高的召回率（recall）掃描每個檔案、每個測試和每次提交，那個能逃過代理審查、但會被人類審查者發現的缺陷集合正在縮小。與此同時，人類審查在時間、延遲和社交摩擦上的成本[4], [5]卻保持不變。這個交叉點——即人工審查的邊際效益不再能證明其邊際成本是合理的——已經達到了。代理審查是即時的、確定性的和可稽核的：它們產生的是結構化報告，而非非正式的討論串評論，而且可以在流程的任何節點重新執行。持續交付的競爭優勢[28]使得審查延遲成為軟體團隊越來越難以承受的稅賦，而代理系統則將其徹底消除。

五、影響與意涵

A. 對軟體工程實務的影響

合併工作流程的重新設計。基於代理的審查最直接的影響，就是拉取請求工作流程的重組。在現行模式下，開發者開啟一個拉取請求，然後等待數小時甚至數天，等同事有空來審查。我們提議用一個代理在迴路中（agent-in-the-loop）的驗證流程來取代這個把關步驟，該流程會對每個候選合併自動執行。合併關卡從人類批准的核取方塊，轉變為一個結構化的代理簽核：測試覆蓋率門檻、安全掃描結果、風格遵循報告和推理追蹤，全都在無需人類排程的情況下產生。人類的批准並未被消除；它被保留給那些真正需要它的決策：高風險變更、新穎的架構選擇，以及受監管的程式碼路徑，在這些地方必須有一位具名的人類承擔法律責任。對於絕大多數的提交（增量功能、錯誤修復、依賴項更新、重構），代理簽核已足夠，要求更多就是一種浪費。

團隊結構與角色。隨著代理審查的成熟，專業程式碼審查者的角色在現有形式上將會式微。開發者花在同步審查會議和非同步評論討論串上的時間將會減少。這不代表開發者的專業知識變得不重要；而是代表專業知識被重新導向。開發者將越來越成為規範制定者和協調者：他們精確地闡述需求，使其足夠清晰以便代理系統能據以行動；他們在更高的抽象層次上評估代理產出的成品；並在代理推理不確定或風險很高時進行介入。這門手藝將從逐行檢查轉變為系統層級的判斷。這是許多開發者會歡迎的改變，因為調查一致顯示，審查程式碼是工作中最不令人愉快的部分之一[2]。

新人引導與知識傳遞。程式碼審查最常被提及的好處之一，是它在團隊成員間傳播知識的角色[1]。代理系統可以在合併時生成隨需應變、與情境相關的解釋，其豐富度遠超一位忙碌的資深工程師在倉促評論中所能提供的。真正的風險在於，那些非正式的、雙向對話會減少，而隱性知識和團隊文化正是透過這些對話傳播的；組織將需要互補的機制，如結對程式設計（pair programming）和結構化的師徒制，來維護這種凝聚力。

開源動態。在開源專案中，維護者的頻寬是一個結構性瓶頸：貢獻的程式碼要等上數週才能獲得審查，而專案被放棄的原因，不是因為不再有修補程式提交，而是因為維護者耗盡了審查容量。代理審查直接解決了這個瓶頸，壓縮了回饋循環，並降低了首次貢獻者的進入門檻。

B. 對工具的影響

CI/CD整合。代理審查是持續整合流程的自然延伸。就像構建系統和測試執行器會在每次推送時自動執行一樣，審查代理可以在同一個時間點被觸發，無論是對功能分支的每次提交，或是作為合併前的強制性關卡。這將審查從一個非同步的社交活動，重新定義為一個一級的工程檢查，類似於編譯：它運行、它報告，然後它要麼通過，要麼阻止[28]。代理系統產生結構化報告（如JSON、SARIF），可供CI儀表板、安全平台和分析系統無需人工中介直接取用。審查歷史變成了一種工程產物，可被版本控制和查詢，而不是一串隨著時間變得難以維護的非正式評論。

IDE與編輯器整合。代理系統所實現的延遲降低，並不侷限於合併流程。一個嵌入開發者編輯器中的代理，可以在程式碼被提交前就進行審查：在開發者編寫的同時，代理讀取情境、識別問題，並在行內將它們顯示出來。這將回饋循環從數小時或數天壓縮到數秒。互動模式也改變了：開發者不再閱讀一串審查評論並決定接受或拒絕每一條，而是與代理用自然語言交談，要求解釋、請求替代實作方案，或協商取捨。這更接近結對程式設計而非傳統審查，而且它在運作時沒有那種使同步結對難以大規模維持的社交成本。

版本控制平台。為了讓代理審查能作為一級活動來運作，像GitHub和GitLab這樣的平台，必須擴展其身份和權限模型以支援代理行為者。一個代理審查者需要一個經加密簽名的身份、在平台稽核日誌中推送記錄的能力，以及像人類審查者一樣批准、請求變更或阻止合併的能力[9]。拉取請求的使用者介面必須相應地演進：代理生成的摘要、信心分數、分類發現結果以及行內修復建議，應以結構化的UI元件呈現，而非模仿人類行為的合成評論討論串。在這個模型中，審查歷史的本質就是機器可讀的：下游分析可以直接對代理審查記錄進行操作（如缺陷趨勢儀表板、安全狀態追蹤、程式碼庫健康評分）。

六、討論

A. 反方論點：幻覺與偽陰性（false negatives）。

大型語言模型（LLM）可能會遺漏超出其訓練分布的缺陷[25]。對某個變更感到不確定的人類審查者通常會明確表示出來；但一個LLM可能會默默地產出批准。主要的緩解措施是集成式審查：運行多個獨立的代理，理想情況下基於不同的模型和提示策略，並在簽核前要求達成共識。第二個緩解措施是經校準的不確定性報告：審查代理應被訓練和評估為能夠棄權（表示「我不知道」），並發出與經驗正確性相符的信心估計，而不是總是給出二元的批准[29]。

B. 反方論點：代理生成程式碼中的安全漏洞。

Pearce等人證明，GitHub Copilot在一系列與安全相關的程式設計場景中，會以不可忽視的比率引入常見弱點列舉（CWE）的違規[24]。當負責生成程式碼的同一模型家族也負責審查它時，存在一個風險：生成和審查的盲點是相關的——代理可能無法標記出正是其生成傾向所產生的那種弱點模式。緩解措施是使用網路安全專用的尖端審查器來進行安全簽核：近期的基準測試導向報告顯示，最新的模型在弱點識別任務上，能夠勝過傳統的靜態分析器和強大的基線[30], [31]。

C. 反方論點：對抗性輸入與提示注入（prompt injection）。

一個能夠提交拉取請求的精密攻擊者，也可能精心設計一段程式碼，當審查代理讀取它時，會透過嵌入的自然語言指令來操縱代理的推理。一個惡意製作的評論、識別字或字串字面值，可能會指示代理忽略一個漏洞，或批准一個它本應阻止的變更。這是一個活躍的安全研究領域，還沒有完全解決的防禦措施[32]，而且它代表了一個人類審查者不會遇到的、本質上全新的攻擊面。部署代理審查的組織必須將對代理審查者的提示注入，視為一個一級威脅模型。

D. 反方論點：架構一致性需要人類判斷。

在架構層面，審查者會評估一個變更是否與系統的長期設計一致：一個新的抽象是否重複了既有的抽象、一個局部的取捨是否累積了戰略性的技術債務，或者一個介面決策是否阻礙了未來的擴展。這些判斷依賴於對系統架構的心智模型，而AI可能尚未以足夠的保真度掌握這一點[1]。

這種擔憂錯誤地界定了拉取請求審查實際提供的範疇。架構一致性最好透過設計文件、架構決策記錄和專門的架構審查來強制執行，而不是透過逐次提交的差異檢查。將兩者混為一談，會高估人類PR審查所能可靠提供的東西，因為實證研究顯示，審查者絕大多數關注的是表面缺陷和風格，而不是戰略性的架構有效性[1], [14]。

E. 反方論點：倫理責任需要人類判斷。

在倫理層面，程式碼變更可能會對使用者隱私、演算法公平性和環境足跡帶來後果，這需要基於價值觀的判斷，而非僅是正確性驗證。代理系統被校準為最佳化技術品質指標；它們並未被可靠地裝備來偵測一個遙測變更是否侵犯了使用者的合理隱私期望，或者一個排名修改是否放大了人口統計學上的偏見[4]。法律和組織的責任框架預設了一個具名的人類決策者：當一個變更造成損害時，一個自動化的批准會留下責任缺口。

代理系統已經能夠標記安全敏感的模式（如記錄個人身份資訊PII、不安全的隨機數、過度授權的API呼叫），而且它們對合規屬性（compliance properties）的覆蓋範圍正在增長[24], [25]。更根本的是，強制性的PR審查並非對軟體進行倫理審查的適當場合：這個責任屬於需求工程和部署後的監控。代理審查可以由與其他自動化品質關卡相同的制度性機制來管理，並將人類的升級干預保留給代理標示為不確定或高風險的變更。

七、結論

程式碼審查已為軟體工程服務了五十年。從Fagan的正式檢查[13]到如今主導著每日數百萬次提交的拉取請求模型[1]，讓人類在合併前閱讀彼此的程式碼，一直被視為一種強制性的工程美德。我們論證了這個假設不再成立。

編碼代理系統已達到一個能力水準，在此水準下，程式碼審查的每個既定目標，都可以被自動地、更快地、以人類審查無法比擬的規模來達成。對於業界中的例行性變更，這個轉變已在進行中。代理系統今日已在審查依賴項版本升級、重構和測試新增，而人類僅在邊緣提供監督。懸而未決的問題，不在於這個轉變是否會發生，而在於它會多快地從例行性變更擴展到軟體開發的全部範疇，以及這個專業領域將如何管理這種擴展。

程式碼審查不會在一夜之間消失。它的角色將重新聚焦於一層高風險的人類監督：具有長遠後果的架構決策、受監管系統中的安全關鍵路徑，以及那些其正確性取決於代理系統未被授予存取權限的需求的變更。對於其他一切，強制性人工審查的理由，已經弱化到難以在技術基礎上為其辯護的程度。

程式碼審查的終結，這個我們曾認為是現代軟體工程絕對最佳實踐的終結，正是以一種更有生產力的方式來構建軟體的開始。

參考文獻

[1] A. Bacchelli and C. Bird, 'Expectations, outcomes, and challenges of modern code review,' in Proceedings of the 35th International Conference on Software Engineering (ICSE). IEEE, 2013, pp. 712-721.

[2] C. Sadowski, E. Söderberg, L. Church, M. Sipko, and A. Bacchelli, 'Modern code review: a case study at Google,' in Proceedings of the 40th International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP). ACM, 2018, pp. 181-190.

[3] M. Hilton, T. Tunnell, K. Huang, D. Marinov, and D. Dig, 'Usage, costs, and benefits of continuous integration in open-source projects,' in Proceedings of the 31st IEEE/ACM International Conference on Automated Software Engineering (ASE). ACM, 2016, pp. 426-437.

[4] A. Bosu, M. Greiler, and C. Bird, 'Process aspects and social dynamics of contemporary code review,' in IEEE Transactions on Software Engineering, vol. 43, no. 1. IEEE, 2016, pp. 56-75.

[5] A. Murgia, P. Tourani, B. Adams, and M. Ortu, 'Do developers feel emotions? an exploratory analysis of emotions in software artifacts,' in Proceedings of the 11th Working Conference on Mining Software Repositories (MSR). ACM, 2014, pp. 262-271.

[6] J. Yang, C. E. Jimenez, A. Wettig, K. Lieret, S. Yao, K. Narasimhan, and O. Press, 'SWE-agent: Agent-computer interfaces enable automated software engineering,' arXiv preprint arXiv:2405.15793, 2024.

[7] Cognition AI, 'Introducing Devin, the first AI software engineer,' Cognition AI Blog, 2024, https://www.cognition.ai/blog/introducing-devin.

[8] X. Wang, B. Chen, Y. Yuan, Y. Zhang, B. Li, C. Qian et al., 'OpenDevin: An open platform for AI software developers as generalist agents,' in arXiv preprint arXiv:2407.16741, 2024.

[9] GitHub, 'GitHub Copilot Workspace: Welcome to the Copilot-native developer environment,' GitHub Blog, 2024, https://github.blog/2024-04-29-github-copilot-workspace/.

[10] C. E. Jimenez, J. Yang, A. Wettig, S. Yao, K. Pei, O. Press, and K. Narasimhan, 'SWE-bench: Can language models resolve real-GitHub issues?' arXiv preprint arXiv:2310.06770, 2023.

[11] Z. Li, S. Lu, D. Guo, N. Duan, S. Jannu, G. Jenks, D. Majumder, J. Green, N. Sundaresan, M. Fu et al., 'CodeReviewer: Pre-training for automating code review activities,' in Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE). ACM, 2022, pp. 1536-1546.

[12] C. Pornprasit and C. Tantithamthavorn, 'Automated code review in practice,' in Proceedings of the 38th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 2023, pp. 394-405.

[13] M. E. Fagan, 'Design and code inspections to reduce errors in program development,' IBM Systems Journal, vol. 15, no. 3, pp. 182-211, 1976.

[14] J. Czerwonka, M. Greiler, and J. Tilford, 'Code reviews do not find bugs: How the current code review best practice slows us down,' pp. 27-28, 2015.

[15] J. Lu, L. Yu, X. Li, L. Yang, and C. Zuo, 'Llama-reviewer: Advancing code review automation with large language models through parameter-efficient fine-tuning,' in Proceedings of the 34th IEEE International Symposium on Software Reliability Engineering (ISSRE). IEEE, 2023, pp. 647-658.

[16] R. Tufano, S. Masiero, A. Mastropaolo, L. Pascarella, D. Poshyvanyk, and G. Bavota, 'Using pre-trained models to boost code review automation.' ACM, 2022, pp. 1-12.

[17] X. Tang, K. Kim, Y. Song, C. Lothritz, B. Li, S. Ezzini, H. Tian, J. Klein, and T. F. Bissyande, 'CodeAgent: Autonomous communicative agents for code review,' arXiv preprint arXiv:2402.02172, 2024.

[18] M. Chen, J. Tworek, H. Jun, Q. Yuan, H. P. d. O. Pinto, J. Kaplan, H. Edwards, Y. Burda, N. Joseph, G. Brockman et al., 'Evaluating large language models trained on code,' arXiv preprint arXiv:2107.03374, 2021.

[19] Anthropic, 'The Claude 3 model family: Opus, Sonnet, Haiku,' Anthropic Technical Report, 2024.

[20] S. bench Team, 'SWE-bench leaderboard,' https://www.swebench.com, 2025.

[21] C. Le Goues, T. Nguyen, S. Forrest, and W. Weimer, 'A systematic study of automated program repair: Fixing 55 out of 105 bugs for $8 each,' pp. 3-13, 2012.

[22] C. S. Xia, Y. Wei, and L. Zhang, 'Automated program repair in the era of large pre-trained language models,' pp. 1482-1494, 2023.

[23] Y. Li, D. Choi, J. Chung, N. Kushman, J. Schrittwieser, R. Leblond, T. Eccles, J. Keeling, F. Gimeno, A. Dal Lago et al., 'Competition-level code generation with AlphaCode,' Science, vol. 378, no. 6624, pp. 1092-1097, 2022.

[24] H. Pearce, B. Ahmad, B. Tan, B. Dolan-Gavitt, and R. Karri, 'Asleep at the keyboard? assessing the security of GitHub Copilot's code contributions,' in Proceedings of the 43rd IEEE Symposium on Security and Privacy (SP). IEEE, 2022, pp. 754-768.

[25] R. Khoury, A. R. Avci, J. Brunelle, and B. Marc Camara, 'How secure is code generated by ChatGPT?' 2023.

[26] J. W. Lin, E. K. Jones, D. J. Jasper, E. J.-s. Ho, A. Wu, A. T. Yang, N. Perry, A. Zou, M. Fredrikson, J. Z. Kolter et al., 'Comparing ai agents to cybersecurity professionals in real-world penetration testing,' arXiv preprint arXiv:2512.09882, 2025.

[27] S. Peng, E. Kalliamvakou, P. Cihon, and M. Demirer, 'The impact of AI on developer productivity: Evidence from GitHub Copilot,' arXiv preprint arXiv:2302.06590, 2023.

[28] M. Shahin, M. A. Babar, and L. Zhu, 'Continuous integration, delivery and deployment: A systematic review on approaches, tools, challenges and practices,' IEEE Access, vol. 5, pp. 3909-3943, 2017.

[29] S. Kadavath, T. Conerly, A. Askell, T. Henighan, D. Drain, E. Perez, N. Schiefer, Z. Dodds, N. DasSarma, E. Tran-Johnson, S. Johnston, S. El-Showk, A. Jones, N. Elhage, T. Hume, A. Chen, Y. Bai, S. Bowman, S. Fort, D. Ganguli, D. Hernandez, J. Jacobson, J. Kernion, S. Kravec, L. Lovitt, K. Ndousse, C. Olsson, S. Ringer, D. Amodei, T. B. Brown, J. Clark, N. Joseph, B. Mann, S. McCandlish, C. Olah, and J. Kaplan, 'Language models (mostly) know what they know,' arXiv preprint arXiv:2207.05221, 2022.

[30] A. Yildiz, S. G. Teo, Y. Lou, Y. Feng, C. Wang, and D. M. Divakaran, 'Benchmarking llms and llm-based agents in practical vulnerability detection for code repositories,' arXiv preprint arXiv:2503.03586, 2025.

[31] Berkeley Risk and Decisions Initiative, 'Frontier ai's impact on the cybersecurity landscape (paper summary and blog),' https://rdi.berkeley.edu/frontier-ai-impact-on-cybersecurity/, 2025.

[32] K. Greshake, S. Abdelnabi, S. Mishra, C. Endres, T. Holz, and M. Fritz, 'Not what you've signed up for: Compromising real-world LLM-integrated applications with indirect prompt injection,' arXiv preprint arXiv:2302.12173, 2023.