LLM 開發流程全景：瓶頸從寫程式移到驗證程式之後
AI 讓寫 code 快了 34%，但 review 時間暴增 441%、實測交付反而慢 19%。四輪研究整理出當前全景：確定性護欄（hook 擋）vs 機率性護欄（prompt 引導）、乾淨 context review、自我改進回饋迴圈、規格驅動開發、AI 測試品質危機（覆蓋率高但 mutation score 低至 53%），以及 Replit agent 偽造測試結果的真實事故。
#code-review
9 篇文章PR 審查怎麼交給 Claude Code：multi-agent 分析、REVIEW.md 與 ultrareview
GitHub PR 審查設定好後，由一隊 agent 依 repo 觸發模式審查，平均 20 分鐘、每則約 15–25 美元，findings 以 inline comments 貼在問題行上；改動夠大時用 /code-review ultra 開雲端深審，5–10 分鐘回報每條都經獨立驗證的 bug，單次約 5–25 美元、Pro/Max 有 3 次免費。
CS146S Week 6：Google 為了讓 AI review 有用，先刪掉 17 條規則
Google 的 AutoCommenter 部署到數萬名工程師身上，論文寫出了整條調校過程：把 17 條「技術上正確但沒價值」的規則停掉，有用率從 54% 升到 66%，目標訂在 80% 才准進下一階段。最後的留言解決率約 40%。AI code review 的瓶頸從來不是抓不到，是抓太多。
用 Codex + Gemini + Claude 做多引擎 Code Review：原理、模式與實作
AI 模型審查自己的程式碼時會自我合理化，用三個不同 CLI 做獨立 review 可以有效捕捉盲點——這篇介紹背後的設計哲學與實際的工作流程模式。
從實戰整理：AI Native 團隊該做好的事
不是每個人都該直接用 coding agent 改 code。AI Native 團隊要搞定 interface 規格、測試先行、monorepo、security guardrail、human-in-the-loop 與 token 預算管控，在 coding agent 上面再建一層 agent platform 並明確開發者角色轉型才是正途。
code-review-graph：用知識圖譜讓 AI Code Review 省下 8 倍 Token
code-review-graph 用 Tree-sitter 解析 codebase 建立持久化知識圖譜，追蹤變更的爆炸半徑，只把真正相關的 context 餵給 AI，號稱平均省下 8.2 倍 token。
Ticketing 已死，Review 才是新的 Planning
當 AI agent 能在幾分鐘內把 intent 變成 PR，軟體工程的瓶頸就從「規劃該做什麼」翻轉成「評估做出來的東西對不對」。Ticketing 時代的產物（sprint、story point、backlog grooming）正在壓縮歸零，取而代之的核心實踐是 review。
一個人的全端團隊：從 OpenSpec 到自動部署的 AI 驅動開發流程
用 OpenSpec 把需求拆成工程任務，Claude Code 實作，hooks 自動格式化和保護，commit 前本地 review，PR 上三個 AI reviewer 平行審查，merge 後自動部署。整套流程讓一個人能維護六個子專案的品質。
Code Review Comment 怎麼分類？從 Conventional Comments 到 AI Review 工具的分類體系
主流分類系統有三種路線：Conventional Comments（標籤制）、Google 嚴重度前綴（Nit/Optional/FYI）、SonarQube 四象限（Bug/Vulnerability/Code Smell/Hotspot）。AI review 工具各自發展出不同分類，但核心維度收斂在正確性、安全、效能、可維護性四大塊。