AI coding agent 的討論常常卡在兩種極端。
一邊說它只是 hype，demo 很漂亮，真實專案不可靠。
另一邊說它會快速取代工程師，從此軟體開發全面自動化。
GitHub 上的實證研究讓這件事變得比較冷靜：AI coding agent 既不是玩具，也不是魔法。它已經進入真實開發流程，但效果高度依賴任務類型、review 品質與導入方式。
這比單看 Codex、Claude Code、Cursor 的新功能更重要，因為它回答的是另一個問題：開發者到底有沒有真的把 agent 用在工作裡？
研究開始看「真實痕跡」，不是問卷感受
傳統 AI 寫程式討論常靠三種材料：
- 廠商 demo
- benchmark 排名
- 開發者主觀心得
這些都有價值，但都不夠。Demo 可以挑任務，benchmark 通常太乾淨，主觀心得又很容易受新鮮感影響。
２０２６ 年初出現一批更有意思的研究：直接看 GitHub 上留下的 agent 使用痕跡。
例如：
- commit 是否標示 agent co-author
- PR 是否由 agent 建立或提交
- 任務類型是 feature、fix、docs 還是 test
- PR 最後有沒有被接受
- human reviewer 如何回應 agent 產出
- agent 產出的 commit 是否比人類 commit 更大、更複雜
這種研究不完美，因為不是所有 agent 都會留下相同標記，也可能漏掉私有 repo。但它至少開始把討論從「感覺很強」推向「真實軟體工程裡發生了什麼」。
採用率已經不像小眾工具
論文 Agentic Much？Adoption of Coding Agents on GitHub 分析 １２９,１３４ 個活躍 GitHub 專案，估計 coding agent 採用率落在 １５.８５％ 到 ２２.６０％。
這個數字的重點不是精準到小數點，而是量級。
如果一個只流行幾個月的開發工具，已經能在大量開源專案中留下可觀測使用痕跡，那它就不是單純的嘗鮮現象。
研究也指出，採用不是只集中在玩具專案。它橫跨：
- 不同成熟度的專案
- 不同程式語言
- 不同主題
- 已建立的組織
- feature 與 bug fix 類任務
這代表 AI coding agent 的滲透方式不是「少數人拿來玩」，而是逐步嵌進一般開發流程。
AIDev：９３ 萬個 agentic PR 代表什麼？
另一篇論文 AIDev：Studying AI Coding Agents on GitHub 建立了一個大型資料集，整理 ９３２,７９１ 個 Agentic-PR。
這些 PR 來自五類常見 coding agent：
- OpenAI Codex
- GitHub Copilot
- Devin
- Cursor
- Claude Code
資料集涵蓋 １１６,２１１ 個 repo、７２,１８９ 名開發者，另外也整理一個更細緻的子集，保留 comments、reviews、commits 與 related issues。
這件事很重要，因為 AI coding agent 的研究正在從「工具評測」變成「軟體工程資料研究」。
未來比較有價值的問題不會只是：
- 哪個模型 benchmark 高？
- 哪個 agent 寫 code 較快？
- 哪個工具最熱門？
而會是：
- 哪種任務最適合交給 agent？
- 哪種任務最容易產生不可靠 PR？
- reviewer 需要花多少時間修 agent 的輸出？
- agent 產出的 code 是否比較難維護？
- agent 是否會放大既有測試不足與架構混亂？
這才是企業真的需要的答案。
沒有單一工具永遠最好，任務類型更關鍵
論文 Comparing AI Coding Agents：A Task-Stratified Analysis of Pull Request Acceptance 分析 ７,１５６ 個 PR，結論很值得注意：沒有單一 agent 在所有任務類型都最好。
研究指出，任務類型對 PR 接受率影響很大。文件任務接受率較高，新功能任務接受率較低；不同 agent 在不同任務上的表現也不同。
根據摘要：
| 發現 | 意義 |
|---|---|
| 文件任務接受率達 ８２.１％ | agent 做 docs、說明、補文件通常比較穩 |
| 新功能任務接受率為 ６６.１％ | feature 牽涉產品判斷與架構，難度明顯更高 |
| Codex 在多個任務類別保持高接受率 | 通用性可能較強，但仍需看 repo 情境 |
| Claude Code 在文件與 feature 任務表現突出 | 深入互動式 coding workflow 可能有優勢 |
| Cursor 在 fix 任務表現突出 | AI IDE 型態可能更貼近日常修 bug 工作 |
這對讀者很有用，因為它提醒一件事：不要用單一榜單決定工具。
企業應該把任務拆開看。
文件、測試、簡單 bug、重構、新 feature、安全修補，應該分別評估。
為什麼這些研究對一般開發者也重要？
如果你是個人開發者，這些研究不是要你讀統計模型，而是提醒你如何把 agent 用得更有效。
比較穩的任務包括：
- 解釋陌生 codebase
- 補文件與 README
- 寫測試草稿
- 修小型 bug
- 重構重複邏輯
- 產生 migration 或型別補強的初稿
- 根據 failing test 找可能原因
比較不適合完全放手的任務包括：
- 新增核心架構
- 牽涉產品判斷的新 feature
- 資安敏感改動
- 金流、權限、認證流程
- production config
- 大範圍重構
- 測試覆蓋不足的 legacy code
換句話說，AI coding agent 最適合當成會動手的 junior pair，不適合當成不用 review 的 senior engineer。
對企業來說，重點是建立任務分級
企業導入 AI coding agent 時，不應該只用「開或不開」來管理。
更好的做法是把任務分級：
| 任務級別 | 可以怎麼用 agent |
|---|---|
| 低風險 | 文件、註解、測試草稿、code explanation，可廣泛開放 |
| 中風險 | 小型 bug、型別修正、lint、低耦合重構，可要求 PR review |
| 高風險 | auth、payment、infra、資料庫 migration，需要 approval gate |
| 禁止自動化 | secrets、production access、刪除資料、法遵敏感流程，不讓 agent 自主操作 |
這比「全部禁用」或「全部開放」都合理。
AI coding agent 的價值會出現在大量中低風險任務裡。真正該被嚴格控管的是權限邊界，而不是把所有 AI 輔助都當成同一件事。
接下來讀者該追哪些問題？
這些研究也說明 AI coding 不是短期話題。它會繼續拆成工具選擇、工作流程、風險治理與職涯影響。
接下來需要持續追蹤的問題包括：
- Codex 是什麼
- Claude Code 怎麼用
- Cursor vs Claude Code
- AI coding agent 評估
- coding agent 安全風險
- AI 產生 PR 怎麼 review
- 企業導入 AI coding agent checklist
- AI coding agent 會不會取代工程師
- GitHub Copilot、Codex、Claude Code 差異
這些不是單日新聞，而是開發者與企業會反覆遇到的長期問題。單看新功能發布不夠，還要看 agent 在真實 repo、真實 PR、真實 review 裡能不能穩定交付。
結論：AI coding agent 正在從「能寫」走向「能交付」
GitHub 上的研究讓 AI coding agent 的討論更務實。
不是所有任務都適合交給 agent。
不是所有 agent 都在同一類任務表現最好。
不是所有 AI 產出的 PR 都能降低 reviewer 負擔。
但有一件事已經很清楚：AI coding agent 已經進入真實軟體工程，不再只是 demo 與社群 hype。
２０２６ 年真正要看的問題，不是「AI 會不會寫 code」，而是：
它能不能在真實 repo 裡，針對合適任務，產出可 review、可測試、可合併的變更。
這會是接下來 AI coding 需要持續追蹤的主線。