Reviewing agent-generated code when code is cheap
An O'Reilly Radar article argues that as agent-written code becomes cheap, human review becomes the bottleneck, and proposes making evidence a condition for accepting agent-generated code. The author recommends agreeing on intended behavior and the change's expected 'blast radius' before implementation, then using that evidence to spot drift and decide which parts of the diff need direct inspection. A fictional refund-service example — approval required above €100, plus an unrequested retry added to a shared payment client — shows how a small diff can have broad effects, including possible duplicate refunds. The piece recommends bidirectional traceability (citing NASA guidance), checking that tests fail when code is broken (per Google's review guidance), matching review depth to impact, and a short per-pull-request record linking agreed behavior, evidence and open questions. It cites a 2026 study of LLM requirement-conformance judgments that found models rejecting correct implementations and accepting faulty ones.
It offers teams a practical template for keeping human review meaningful as agents generate ever more code.