截至 2026 年 8 月 28 日，Coding Agent 已經能在邊界清楚的專案裡承擔大型重構、效能調校與跨語言重寫。真正卡住團隊的，逐漸不再是「程式碼能不能寫出來」，而是規格是否完整、測試能不能證明行為沒變，以及誰願意為合併後的結果負責。 OpenAI 把 GPT-5.6 Sol 與 Max 放進 Codex，並把 Codex App 定位成可同時管理多個 Agent 的工作台；公開 GitHub PR 也讓我們看到另一面：Agent 可以一次改動上萬行，但合併的依據仍是合約、測試與工程判斷。
「我不看程式碼」聽起來像挑釁。若把它理解成連 diff 都不開、測試紅了也照合，當然是失職。比較值得討論的版本是：工程師不再把逐行閱讀當成唯一的信任來源，而是先看行為合約，再看證據，最後只對高風險邊界做深入審查。
真正的分水嶺：它跨過你的日常基準
模型會補函式、寫測試，早已成為日常。工作方式真正改變的時刻，是它在你熟悉的程式庫裡，能穩定交出達到日常開發水準的結果。這個基準沒有全球統一答案：對小型 CLI、資料轉換器與內部工具來說可能已經跨過；對支付、身分驗證、分散式一致性與安全核心，還差得很遠。
公開紀錄提供了幾個很好的壓力測試。fast/cronexpr 的 PR #33 用手寫 byte-offset parser 取代 Winnow，5 次提交改了 23 個檔案，新增 1,044 行、刪除 756 行。行數只是表面；它還保留既有 snapshot，並對 34,228 組生成式 cron expression 做差異測試。後續 PR #35、#36 與 #37 又補上競品 benchmark、解析路徑調校與延後錯誤格式化。
fast/hawkeye 的 PR #215 更大：155 次提交、133 個檔案，新增 5,788 行、刪除 6,345 行，八天內完成 HawkEye v7 的 Rust 重寫。這種規模過去會自然形成一道預算牆；現在，產生改動已不再是最昂貴的部分。昂貴的是回答三個問題：新版本是否維持舊行為、效能提升是否可重現、維護者是否看得懂它留下的結構。
不逐行讀，靠什麼合併
「模型很強」無法當證據。
cronexpr 的案例之所以站得住，是因為 parser 的外部行為有 snapshot 和差異測試可以鎖住。Apache DataSketches Rust 的 PR #231 調整 T-Digest 的 partial aggregate 路徑，工作負載明寫要反序列化 64 個 partial state；效能工作有可重跑的 workload，才知道快在哪裡，也才抓得到以正確性換速度的偷跑。
這套審查方式可以整理成三層：
| 風險層級 | 可以交給 Agent 的工作 | 人要盯的證據 |
|---|---|---|
| 低風險 | 內部重構、parser 替換、重複程式碼整理 | 既有 snapshot、差異測試、lint 與型別檢查 |
| 中風險 | 效能調校、資料結構替換、跨語言移植 | 可重跑 benchmark、記憶體與延遲回歸、邊界輸入 |
| 高風險 | 公開 API、並行原語、權限、安全與資料遷移 | 人工設計審查、威脅模型、故障注入、回滾方案 |
Apache Asyncband 的 PR #105 一次加入 305 行，處理 mutex、semaphore 與事件等非同步原語。這類改動即使測試全綠，也不能只看輸出結果：取消語意、公平性、飢餓、死鎖與 runtime 相容性都藏在介面邊界。到了這一層，程式碼閱讀沒有消失，只是從「每行平均用力」改成「對不可逆、不可觀測與高爆炸半徑的位置用力」。
把驗收條件寫在提示詞前面
很多 Agent 任務失敗，是因為團隊根本沒有講清楚什麼叫完成，prompt 長短反而是次要問題。若需求只寫「把它重寫成 Rust，順便變快」，Agent 當然能生出很多程式碼；合併者拿到的仍是一團無法判斷的變更。
比較能工作的任務合約，至少要先寫這五件事：
- 哪些外部行為必須逐字或逐位元相容。
- 哪些檔案、公開 API 與資料格式不能動。
- 要用什麼測試與 workload 證明結果。
- 效能改善的基準機器、樣本與容許誤差。
- 失敗時如何回滾，以及哪些決策必須停下來交給人。
可以直接把要求寫成一份短合約：
任務：替換目前的解析器實作，不改公開 API。
完成條件：
- 既有 snapshot 必須逐位元一致。
- 對至少 30,000 組生成輸入跑新舊實作差異測試。
- 新增 benchmark，分開報告 parse、format 與 allocation。
- 任何語意不確定或需要更改公開格式的地方，停止並回報。
- 最終回覆列出變更、證據、未解風險與回滾步驟。
這份合約沒有華麗的角色設定。它只是把「我希望它做好」改成可驗收的條件。Agent 可以自己找路，合併門檻不能跟著漂。
程式碼供給暴增後，架構債反而更容易被低估
成本下降會改變團隊願意嘗試的事情。過去一個 parser 重寫可能要排兩個季度，現在可以先在隔離分支做出完整版本，再用差異測試決定要不要留下。這是好事。它讓「試了才知道」變得合理，也讓舊系統不必因為改寫太貴而永遠不能碰。
產生程式碼變便宜了，擁有它照樣昂貴。每一個新模組都會增加攻擊面、升級責任、除錯路徑與值班負擔。Bun 1.4 的官方公告提到核心從 Zig 重寫為 Rust，規模約一百萬行，二進位檔縮小約 20%，並新增約 1,400 個 Node.js 測試。這證明大型重寫已經能真實發生；它沒有證明維護成本會自動消失，也不能反推任何一顆模型獨自完成了這場工程。
YAGNI 因此沒有失效。新的判斷方式是：實驗成本可以很低，進入主幹的成本仍要照未來五年計算。Agent 做出的候選方案可以很多，正式留下的介面應該更少。
一套適合 Agent 時代的審查順序
我會把審查順序改成這樣：
- 先看任務合約。 若成功條件寫不清楚，先不要讓 Agent 產生一萬行 diff。
- 再看可執行證據。 測試、benchmark、靜態分析與差異輸出，要能在乾淨環境重跑。
- 看邊界，不平均看每一行。 公開 API、錯誤處理、狀態轉移、並行與安全路徑優先。
- 要求 Agent 說出不知道的地方。 沒有證據的推論要列為風險，不能包成完成事項。
- 最後才問要不要擁有它。 能生成、能通過測試，不等於團隊值得多背一個模組。
OpenAI 對 GPT-5.6 的公開資料強調 coding-agent benchmark 與更高的長任務效率，Codex App 則把多 Agent 平行工作做成產品介面。這些進展會繼續壓低實作成本。它們沒有替團隊回答產品要什麼、相容性要守到哪裡，也沒有接走上線後的責任。
FAQ
Coding Agent 是否已經強到可以取消 Code Review？
不行。低風險改動若有強合約與測試覆蓋，可以減少逐行閱讀。公開 API、並行、安全、資料遷移與不可逆操作仍需要人工審查，而且要看設計與故障模式；測試通過只是其中一項證據。
「不看程式碼」比較精確的意思是什麼？
它代表信任來源從逐行理解，移到行為合約、可重跑證據與高風險邊界。工程師仍會讀程式碼，只是不再把時間平均撒在每一行。
哪些任務最適合先交給 Agent？
外部行為穩定、測試充分、可以隔離執行、容易回滾的任務最適合，例如 parser 替換、內部重構、benchmark 建置與機械式跨語言移植。
大型重寫變便宜後，YAGNI 是否還有用？
有。探索與原型可以更便宜，合併到主幹後的維護、安全與值班成本沒有消失。把更多方案做出來，和把更多方案留下來，是兩個決定。
團隊應該用什麼指標評估 Coding Agent？
不要只算產生多少行或完成多少 ticket。比較有用的指標是：一次通過的驗收比例、回歸缺陷、人工介入點、可重跑證據完整度，以及合併後 30 天內的修復成本。
權威引用
- OpenAI：GPT-5.6
- OpenAI：Introducing the Codex app
- cronexpr PR #33：Replace winnow parser
- HawkEye PR #215：HawkEye v7 Rust rewrite
- Apache DataSketches Rust PR #231
- Apache Asyncband PR #105
- Bun 1.4 官方頁面
Author Insight
Agent 最容易讓團隊誤判的地方，是把「可以做出來」聽成「值得留下來」。我會讓 Agent 多做幾個候選版本，甚至重寫整個模組；進主幹前仍只認合約、證據與可承擔的維護面積。程式碼供給越便宜，刪掉多餘方案的膽量越值錢。
若你的團隊正在把 Codex、Claude Code 或其他 Coding Agent 接進正式開發流程，Tenten 可以協助把任務合約、驗收證據與高風險人工閘門寫成可執行的工作流；可從聯絡頁面提供目前的 repository 與交付限制。
術語表
| 術語 | 說明 |
|---|---|
| Coding Agent | 能讀取程式庫、修改檔案、執行指令並迭代完成任務的 AI 開發代理 |
| 行為合約 | 對外 API、輸入輸出、錯誤語意與相容性等不可漂移的條件 |
| 差異測試 | 讓新舊實作處理同一批輸入，逐項比較輸出的測試方法 |
| Benchmark | 在固定 workload 與環境下測量時間、吞吐量、記憶體或配置次數 |
| 爆炸半徑 | 一項錯誤可能影響的使用者、系統與資料範圍 |
