AI can produce a patch before I finish explaining the ticket. It can also produce a review summary, a list of concerns, and a confident paragraph about why the change is safe.
None of that makes the decision cheaper.
Someone still has to decide whether the patch belongs in the system. Someone has to notice that a tiny helper sits on a hot path, that an innocent schema change breaks an older client, or that the test proves the mocked world rather than the real one.
Code generation got cheap. Review prose got cheap. Judgment did not.
That leaves engineering teams with a weird new bottleneck: reviewer attention. The scarce resource is no longer the ability to produce another plausible change or another plausible comment. It is the time required to understand what matters, verify it, and take responsibility for shipping it.
A good AI review tool does not win by talking more. It knows when a human is worth interrupting.
More comments can make review worse
Most review automation is measured by output. Lines scanned. Comments generated. Issues flagged. Summaries written.
Those numbers are easy to collect and almost useless on their own.
A comment has value when it changes a decision, exposes a risk the reviewer would probably miss, or removes real verification work. Otherwise it is another object the reviewer must classify. Read it. Check it against the diff. Decide whether the bot understood the code. Dismiss it or rewrite it. Maybe explain why it was wrong.
The automation did work. It just handed the bill to the human.
Bot-on-bot review turns into noise fast. One model generates a large patch. Another responds with a large review. The person between them now has two generated artifacts to validate instead of one.
Verbose summaries create the same problem when they repeat the diff in smoother English. A reviewer who can read code still has to inspect the code. The summary has not reduced uncertainty; it has added a second representation that might drift from the first.
Call the useful metric return on attention: how much uncertainty did this signal remove compared with the attention it consumed?
Treat attention like a budget
Teams already budget CPU, memory, storage, and API calls. Reviewer attention deserves the same seriousness because it is both limited and badly distributed.
Not every changed line deserves equal scrutiny.
A 200-line generated test fixture may be boring but easy to validate. A one-line authorization change may deserve the whole room. Diff size does not tell you which is which.
Review tooling can help here by routing attention instead of generating more commentary.
For each change, ask what could make it risky:
- Does it sit behind many callers?
- Does it cross a package or service boundary?
- Does it affect authentication, billing, persistence, or policy?
- Which tests should notice if it breaks?
- Is the runtime behavior visible anywhere, or are we reviewing intent alone?
I want review tools to answer those questions before they start writing paragraphs. The answers tell the human where to spend judgment; they do not replace it.
That distinction matters. An AI reviewer trying to be the final judge has to be right about everything. A review system trying to allocate attention only needs to make the risk surface smaller and more legible.
That is a much better job for software.
Structural risk beats line count
The documented model behind code-review-graph is a useful example. It builds a local structural map of functions, classes, imports, calls, inheritance, and tests. When code changes, the review context can include callers, dependents, and affected boundaries rather than an undifferentiated slice of the repository.
I have not tested the project, and its performance numbers are its own benchmarks. The interesting part is the model, not the speed claim.
A diff is not an isolated document. It is an edit to a graph.
Once you see the change that way, review priority becomes less arbitrary. A small function with twenty dependents may need more attention than a large leaf component. A type change may look harmless until the graph shows consumers outside the package. A test file matters less because it changed and more because it is the only evidence covering an affected path.
Structural context also gives AI a narrower assignment. "Review this repository" is an invitation to spend tokens and produce generic advice. "Inspect this changed function, its callers, the affected tests, and the boundary it crosses" is reviewable work.
The goal is not maximum context. It is the smallest context that preserves the risk.
Put evidence next to the decision
Risk routing gets the reviewer to the right place. The next job is keeping the evidence there.
Line-anchored feedback remains more useful than a detached essay about the patch. Diffsmith's product surface is a simple example: comments attach to local changed lines and can flow back into the correction loop. The anchor does not prove the comment is correct. It does cut the cost of locating the concern and acting on it.
Good review evidence should be annoyingly specific:
- this line changes the authorization decision
- this caller passes a nullable value
- this test covers the happy path but not the failure mode
- this runtime trace contradicts the intended state transition
- this dependency boundary makes rollback harder
Specificity is not the same as verbosity. A precise sentence plus the relevant test result can beat five paragraphs of generalized caution.
The evidence should also stay honest about its limits. A dependency graph cannot prove runtime behavior. A passing unit test cannot settle product intent. A model's confident explanation cannot replace architecture ownership. The tool should show what it knows, what it inferred, and what still needs a person.
If the output hides those boundaries, the reviewer has to rediscover them. There goes the attention budget.
Use a five-question interruption test
Before an automated review signal reaches a human, make it earn the interruption.
What decision will this help someone make?
"Approve, request a test, inspect a caller, or block the change" is useful. "Be aware" usually is not.Why is this risky?
Name the dependency reach, runtime behavior, policy rule, security boundary, or product consequence. Do not confuse unusual syntax with danger.What is the smallest evidence needed?
Prefer the affected caller, failing assertion, trace, screenshot, or contract over a broad explanation of the whole subsystem.Can the feedback stay anchored?
Attach it to the exact line, test, dependency, or observed behavior. Review debt grows quickly when concerns float outside the artifact they describe.Who owns the judgment?
A human author or reviewer still owns the final call and the follow-up. "The AI approved it" is not an accountability model.
This filter will suppress some technically true observations. Good. Review is not a contest to mention everything. It is a process for making a safe decision with finite time.
Faster generation needs quieter review
Practitioner discussions about agentic coding keep returning to the same frustration: generation throughput can grow faster than architecture sign-off, deterministic validation, and human ownership. That is community experience, not a controlled productivity result, but the failure mode is easy to recognize.
When teams respond by adding more automated reviewers, they may increase the queue again. More bots produce more findings. More findings demand more triage. The system looks busy while the merge decision stays stubbornly human.
So compress the decision surface. Do not pretend judgment disappeared.
Map the blast radius. Rank the boundary risk. Show the smallest useful evidence. Keep feedback attached to the change. Interrupt a person only when the signal can alter a real decision.
AI made speaking cheap. Review systems should get better at shutting up.
Source notes
Top comments (0)