AI Coding Agent 讓產碼量暴增了嗎？
Simon Willison 想知道 Coding Agent 與 Opus 4.5 等級模型，究竟替自己的開發產出帶來多少影響。他用 GitHub 的 code frequency 圖表觀察開源專案 Datasette，發現近期程式碼新增與刪除量出現明顯高峰，時間點正好對上他使用 Opus 4.8、GPT-5.5、Fable 5 與 GPT-5.6 Sol。這張圖能呈現 AI 輔助開發後的產量變化，但只能證明活動量增加，還不能直接證明程式品質或開發效率同步提升。
現實應用
這種做法很適合長期維護 GitHub 專案的個人開發者、開源團隊與工程主管：不用先建一套複雜分析平台，直接從現有 repository 的變更頻率，對照導入 Coding Agent、模型升級或工作流程調整的時間點，就能快速看到開發節奏是否改變。
不過程式碼行數很容易被重構、產生檔案或大量刪除影響。若公司要拿來評估團隊，最好再搭配 issue 完成速度、PR 審查時間、測試覆蓋率、缺陷數與版本發布頻率，避免把「寫得多」誤當成「做得好」。
期望評估
我認為低標期望，是 Coding Agent 能降低處理瑣碎修改、測試與文件的成本，讓維護者更願意清技術債，也讓專案更新變密集。即使品質沒有大幅提升，至少可把原本排隊的小工作往前推。
我猜高標情況下，成熟開發者能同時指揮多個 Agent，將想法快速轉成可審查的 PR，使個人專案出現接近小型團隊的產出。但前提是維護者仍有能力設計架構、驗證結果並拒絕不可靠的程式碼。
商業策略分析
最先受影響的會是開發工具、程式碼託管平台、外包服務，以及依人力與工時計價的軟體公司。我認為真正的商業意義不是單純多產生幾行 code，而是同一位資深工程師能否更快交付功能、維護更多專案。
值得跟進，但不建議只展示漂亮的產碼圖表。我認為企業應先選一個有測試、可回滾的專案試跑，記錄交付時間、審查負擔與上線缺陷；若 Agent 增加的審核成本低於節省的開發時間，才算真的有商業價值。