用 Codex + Gemini + Claude 做多引擎 Code Review：原理、模式與實作
AI 模型審查自己的程式碼時會自我合理化，用三個不同 CLI 做獨立 review 可以有效捕捉盲點——這篇介紹背後的設計哲學與實際的工作流程模式。
#code-review
6 篇文章從實戰整理：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 工具各自發展出不同分類，但核心維度收斂在正確性、安全、效能、可維護性四大塊。