生成式 AI 程式設計將工作量減半，卻加重維護人員的審查負擔

AI 生成的 Pull Request 將工作重心從程式設計轉向維護

生成式 AI 正在改變開放原始碼開發的經濟效益：工作成果的產出速度可能更快，但維護人員現在可能需要花費更多時間修正及驗證收到的內容。Linux Foundation Research 的調查指出，生成式 AI 將程式設計時間減半，但 25% 的新進 pull request 被視為「AI 廢料」。

這種組合改變了使用程式設計助手的團隊在實務上的工作流程。如果提交內容中有更大比例需要清理、審查或修復，更快產出第一版實作的價值就會降低。團隊應評估維護人員的總工作量，而不要將縮短的撰寫時間視為唯一的效率指標。

修復時間成為關鍵瓶頸

對工程流程的一項描述指出，將 AI 生成的 pull request 修正至可合併狀態，平均需要維護人員花費約 42 分鐘。這約占真人貢獻所需總時間的三分之一。

實務工作者應體認到，可合併狀態必須成為生成程式碼的一項明確指標。如果接收成果的維護人員必須診斷缺陷、重寫部分內容或強制遵守專案慣例，才能接受這些工作，那麼能快速產生更多程式碼的生成器就不一定有助於交付。采用程式設計代理的團隊需要一種方法，將審查與修復時間分別於生成時間之外進行量測。

生成的程式碼需要持續問責

同一項研究指出，背景審查比在代理完成後才偶爾檢查更有必要。文中提出了一種供代理使用的持續背景程式碼審查資料庫，方式是加快工作速度，同時保留對每一行生成程式碼的問責能力，並支援 Claude Code。

對於正在試驗自主開發的組織而言，這項區別十分重要。生成的貢獻需要具備可稽核的紀錄，涵蓋代理變更了哪些內容、審查了哪些輸出，以及後續採取了哪些行動。相關證據也指出，「AI 廢料」是維護人員的判斷，這更凸顯即使程式碼由機器產出，仍有必要由真人負責。

程式設計代理的生命週期決策需要轉換計畫

程式設計代理市場的另一項進展，是 Jules 這款非同步 AI 程式設計代理宣布將於 2026 年底停止營運。使用者可以完成工作階段至 11 月 11 日，預定停權日期為 2026 年 12 月 31 日。

使用非同步代理進行程式碼生成、背景工作或整合工作的團隊，將需要確認是否能完成進行中的工作階段、匯出所需的輸出，並在指定截止期限前將持續進行的工作移轉至其他工具。現有證據並未說明是否有替代產品，因此眼前的行動是進行營運規劃，而不是假設服務能夠持續運作。

合成式開發工作流程的實務控制措施

相關證據指出，團隊采用生成式程式設計工作流程時，有幾項具體的工具需求：持續執行的 AI 程式碼審查儀表板、pull request 品質評分、缺陷與修復時間追蹤、生成貢獻的來源紀錄，以及用於遷移或關閉非同步程式設計代理工作階段的工具。

以瀏覽器為基礎的工作流程也能協助團隊準備測試資料，而不必暴露專有資料。Dummy File Generator 可以建立預留位置檔案，用於受控測試；指南 Create a Dummy File in CMD with Exact Size and Content 則涵蓋如何產生指定大小及內容的本機測試素材。這些工具可支援合成資料工作流程，但無法評估生成的程式碼，也無法取代維護人員的審查。

對於比較生成測試素材中的識別碼或唯一參照的團隊，ULID Generator 提供了專用於測試資料的選擇。實務優先事項仍然一致：量測生成速度與審查投入、為每一項輸出保留問責能力，並在非同步代理服務結束前確認所有轉換期限。