Treat an AI coding agent the way you would treat a strong, fast, occasionally overconfident junior developer. That is the framing O'Reilly Radar offered in a recent essay examining what happens to code review once implementation itself becomes cheap — and it is a useful mental model for engineering teams grappling with a workflow that has quietly inverted several long-held assumptions.
The core argument, published on O'Reilly Radar under the title "Code Review After Code Gets Cheap," is an economic one: for years, writing code was the scarce resource and human review was plentiful. Agentic development has flipped that arithmetic. When an agent can produce a hundred lines in the time it takes to read them, the bottleneck — and the risk — moves downstream, to the moment a human decides whether the output is actually correct.
Review is no longer about the lines
The essay's practical question is deceptively simple: once the agent has written the code, how should review work? The answer it builds toward is that line-by-line inspection, the default mode of most pull request workflows, is no longer the highest-value use of reviewer attention. A reviewer facing machine-generated volume can verify syntax and idiom quickly; what they cannot do cheaply is establish that the code does what was actually wanted.
That distinction pushes the leverage point upstream. In agentic workflows, specification work stops being overhead and becomes the single most valuable activity on the team — because the specification is the only artifact against which output can be meaningfully checked. Teams that compress their requirements documents in order to speed up prompting are, in effect, compressing their own ability to review. They are giving up the standard they will later need to enforce.
The tooling trap
A predictable response to review scarcity is automation: AI linters, second-model review, agents that review other agents. The essay argues this treats the symptom rather than the cause. Adding more automated activity does not change who is accountable for the result, or against what standard. A wall of green ticks from machine reviewers can coexist comfortably with a codebase that no human can honestly say they understand. Tooling has a role, but it should compress the mechanical part of review so that human attention lands on intent and correctness — not replace the judgement call itself.
The cost that never shows up
There is also a measurement problem. Defects that escape into production, after-hours incidents, and the slow accumulation of unreviewed code do not appear on velocity charts. The essay makes the case that defect escape rate should sit alongside throughput as a headline metric for any team leaning heavily on agents — the implication being that throughput figures without an escape-rate companion are a vanity metric.
Why this matters for small teams under pressure
None of this is specific to any one market, but the configuration it describes is common among small engineering organisations under sustained delivery pressure, where a handful of senior engineers now supervise output volumes that would have required a much larger group two years ago. For tech leads in that position, the immediate practical takeaway is unglamorous but clear. The scarce skill is no longer writing the code. It is writing down — and holding the line on — what the code was supposed to do.
This article summarises and interprets the O'Reilly Radar essay "Code Review After Code Gets Cheap." The full source text is available on O'Reilly Radar.
把一個 AI coding agent 當作一位能力強、速度快、偶爾過度自信的初級 developer 來看待——這是 O'Reilly Radar 在一篇探討「當實作本身變得廉價之後，code review 會變成什麼樣子」的文章中所提出的框架，也是一個有用的思維模型，可供工程團隊應對那種已悄然顛覆多項長期假設的工作流程。
這篇刊於 O'Reilly Radar、題為「Code Review After Code Gets Cheap」的文章，其核心論點屬經濟學層面：多年以來，編寫代碼是稀缺資源，而人力 review 則相對充裕。Agentic development 已把這筆帳翻轉過來。當一個 agent 能在你閱讀一百行代碼的時間內就寫出一百行，瓶頸——以及風險——便順流而下，轉移到人類判斷輸出是否真正正確的那一刻。
Review 不再是逐行逐行看
文章提出的實務問題看似簡單：當 agent 已經寫好代碼，review 應該如何進行？其逐步建立的答案是：逐行檢視——大多數 pull request 工作流程的預設模式——已不再是 reviewer 注意力最具價值的運用方式。面對機器生成的大量代碼，reviewer 可以快速核實語法與慣用寫法；但他們無法輕易做到的，是確認代碼真正實現了原本想要的功能。
這一點把關鍵槓桿位置推向上游。在 agentic 工作流程中，撰寫 specification 不再是開銷，而成為整個團隊最有價值的活動——因為 specification 是唯一可以用來有意義地核對產出的工件。團隊為了加快 prompting 速度而壓縮需求文件，實際上就是在壓縮自身日後進行 review 的能力。他們放棄掉的，正是之後需要拿來執行的標準。
工具化的陷阱
面對 review 種種資源緊缺，一個可以預期的回應是自動化：AI linters、第二個模型來做 review、讓 agent 去 review 其他 agent。文章主張，這只處理了症狀，而非病因。增加更多自動化活動，並不會改變誰要為結果負責，也不會改變依據什麼標準來負責。來自機器 reviewer 的一整排綠色勾號，完全可以與一個沒有任何人敢說自己真正理解的 codebase 相安無事。Tooling 有其角色，但它應該壓縮 review 中機械性的部分，讓人類的注意力落在意圖與正確性之上——而不是取代判斷本身。
那些從不出現在圖表上的成本
還有一個衡量上的問題。流入 production 的缺陷、深夜事故、以及未經 review 的代碼緩慢累積，都不會出現在 velocity 圖表上。文章主張：缺陷逃逸率（escape rate）應與吞吐量（throughput）並列為任何重度依賴 agent 的團隊的首要指標——其含意是，沒有逃逸率作為配套的吞吐量數字，只是虛榮指標。
為何這對承受壓力的小型團隊尤其重要
上述種種並非針對任何單一市場，但文章描述的情境在持續承受交付壓力的小型工程組織中十分常見：如今由少數資深工程師監督的產出量，放在兩年前需要一個大得多的團隊才應付得來。身處這個位置的 tech leader，眼前最實際的結論樸實卻清晰：稀缺的技能已不再是寫代碼，而是寫下來——並且堅守——代碼原本應該做什麼。
本文撮述並詮釋 O'Reilly Radar 文章「Code Review After Code Gets Cheap」。完整原文可於 O'Reilly Radar 查閱。