AI Engineer onepage/ Greptile
Daksh Gupta, Greptile · 約 12 分鐘
這支影片在講：AI 寫的 PR，品質已落在人類區間
Greptile 用每月逾百萬個 pull requests 比較 Codex、Claude Code、Devin、Cursor 與人類開發者。結論不是「AI 已經完美」，而是：整體品質相近、失敗型態不同；因此 code review 的重心必須從看 diff 轉向驗證影響與意圖。
2026-09-27Video ID: 474j-n1Ltxc
01 / 問題
量變先於品質崩壞
AI 產碼正在快速增加；Greptile 在四月觀察到超過四分之一的 PR 帶有 agent 撰寫跡象，一年前還不到 1%。
02 / 反轉
平均品質沒有輸
回退率、PR 尺寸下的回退率、問題嚴重度與到可合併的審查輪次，agent code 都落在與人類相近的區間。
03 / 解法
驗證取代人工逐行看
要問的是：是否違反使用者契約、是否提高未來違反的機率、是否達成作者意圖；再用自動化提供證據。
Signals
四個改變工程管理方式的訊號
AI share
25%+
四月被觀察到主要或完全由 AI agent 撰寫的 PR；一年前不足 1%。
Dataset
1M+/月
Greptile 以每月超過百萬個 PR，涵蓋 NVIDIA、Coinbase、Scale 等企業資料比較。
Human scale
50 → 1,000
中位數使用者每月少於 50 commits；第 99 百分位接近 1,000，人工 review 不再可擴展。
Failure modes
不一樣
Claude 的 SQL injection 約為人類 1.5 倍；Devin 的 auth bypass 約為一半；Cursor 較常出現 N+1。
What the data says
相近的結果，不同的失敗方式
比較 1
不要把「AI 寫的」直接等同於不可靠
影片比較回退率、依 PR 尺寸切分的回退率、Greptile 標示的 P0／P1／P2 嚴重度，以及達到可合併狀態前的 review rounds；四項都沒有顯示 agent code 整體落後人類。
比較 2
不要只看平均數，先建立 failure-mode 地圖
不同 agent 會留下不同模式：例如 SQL injection、auth bypass、N+1 query 的相對機率不同。治理策略應對準具體模式，而不是套用同一套「AI code」審查規則。
比較 3
提交量才是 review 系統的真正壓力測試
當高產使用者接近每月 1,000 次 commit，要求資深工程師逐一讀完 diff 並不是嚴謹流程，而是不可執行的假設。需要的是可重複、可追蹤的自動驗證層。
Validation model
重新定義「這個 PR 是好的」
1. 有沒有違反使用者契約？從外部行為與關鍵流程檢查變更是否讓使用者原本依賴的行為失效，而非只檢查程式碼是否看起來合理。
2. 有沒有讓未來違反更容易發生？找出會擴大風險面的結構性改動：權限繞過、輸入處理、效能退化或難以維護的路徑。
3. 有沒有做到作者想做的事？把需求、變更與可觀察結果連在一起。編譯通過不是意圖驗證；功能結果才是。
用 blast radius + sandbox 取證Greptile 以 blast-radius analysis 辨識受影響範圍，再讓 sandboxed browser agents 實際嘗試破壞應用程式，將 review 從意見轉成可檢查的證據。
Use this
導入 coding agent 時的實務清單
建立 agent 與人類各自的風險基線用回退率、P0/P1/P2、review round 與特定弱點類型分組觀測，不要只報「AI 寫了多少 code」。
把安全規則映射到具體 failure mode例如針對 SQL injection、認證繞過、N+1 query 設置對應的測試、靜態檢查與審查門檻。
讓 review 先回答使用者契約在 PR template 與驗證流程中明確寫出預期行為、受影響流程及反例，避免驗證只停在程式碼風格。
把人工注意力留給例外與決策讓自動化處理 blast radius、回歸檢查與 sandbox 探索；人類集中在需求取捨、風險接受與系統設計。
Source video