A year of AI coding / 11
When code gets cheap review gets expensive
Faster code generation can overload review unless teams control work in progress and make changes easier to verify.
By Grafty team · · 3 min read
Written in .
Generating a patch and accepting a patch are different kinds of work. Generation can run while an engineer does something else. Acceptance requires someone to understand the change well enough to take responsibility for it.
When generation gets faster, the gap between those two activities becomes visible. The team may have more completed branches and no more capacity to decide which ones should ship.
Anthropic launched Code Review for Claude Code on March 9, 2026, using agents to examine pull requests. Its announcement addressed the problem of reviewing a growing volume of changes. We see that as a useful response, but adding automated review does not remove the need to manage the work entering the queue.
Open full-size diagram The expensive part is reconstructing intent
Imagine reviewing a generated change to an internal purchasing app. The diff adds a supplier field, changes validation, modifies a database query, and tidies several unrelated components. Everything looks reasonable in isolation.
The reviewer still needs to answer a basic question: what behavior was actually requested? Is the supplier optional for existing records? Can a user select a supplier from another business unit? Does changing the field trigger a downstream export?
If the task description does not say, the reviewer has to reconstruct the requirements while also inspecting the implementation. That is expensive work, and another agent summary may only restate the assumptions already embedded in the patch.
A better handoff names the requested behavior, links to the deciding requirement, and separates unrelated cleanup. Tests should cover the access boundary and the behavior of existing records, not just the newly generated form.
Diff size matters, but line count alone is a weak proxy for review difficulty. A short authorization change may require more thought than a large set of mechanical renames. Organize work around coherent behavior so the reviewer can reason about one question at a time.
Open full-size diagram Automated review should make human review easier
An automated reviewer can inspect call sites, look for missing checks, and propose tests for suspicious behavior. Its findings are most useful when they include enough context to verify the concern quickly.
The process needs a way to handle disagreement. If a reviewer dismisses a finding, capture the reason. If the tool keeps reporting the same false positive, correct its context or configuration instead of training people to ignore all its comments.
There is a risk of adding review theater: multiple generated approvals that look reassuring but share the same limited context. Independent checks should inspect the original requirements and relevant system boundaries. A second model agreeing with the first is not a substitute for a failing regression test that becomes passing after the fix.
Limit work in progress
We would rather have a small number of changes moving through review than a large set waiting for attention. Before starting more agents, look at how long completed work sits unreviewed and how often it returns for major revision.
Useful measures include time to first substantive review, rework after review, and the number of changes carrying unresolved questions. Avoid treating generated lines or opened pull requests as delivery metrics. They count activity without showing whether the application improved.
For an internal app team, the most effective change may be quite ordinary: smaller tasks, better acceptance criteria, fewer simultaneous branches, and a reviewer identified before the work starts.
AI can help with the inspection. The team still needs to make the inspection feasible. Otherwise faster generation simply moves the waiting time to the people responsible for saying yes.