The problem
AI coding agents are making PR review weird.
The old bottleneck was writing code. Now the bottleneck is often reviewing it. Agents can generate more PRs, and the PRs can be larger. A change that used to be a small manual patch can turn into a multi-file diff with tests, refactors, migration updates, config changes, and docs.
That is not automatically bad. A lot of AI-written code is fine. Some of it is boring in the best way: rename this, add that test, wire this button, update this helper.
The problem is that PR review does not scale linearly with generated code.
If the number of PRs goes up and the size of each PR goes up, “read every line with equal attention” stops being a realistic review strategy. It sounds disciplined, but in practice it turns into fatigue. The reviewer skims. The author skims. The dangerous part gets the same amount of attention as the harmless part.
That is backwards.
The important question is not “did an AI write this?”
The important question is: where can this diff hurt us?
Risk is different from correctness
A component rename and a billing migration are not the same review problem. Existing tools can find bugs or style issues, but that does not tell a reviewer where a mistake would cause an outage, data loss, a privilege bug, or an irreversible state change.
The missing artifact is an attention map: not “what might be wrong?” but “where must a human slow down?”
The human attention map
A human attention map is a final section in the PR review that identifies the critical parts of the diff.
It should not list every possible concern. That would just recreate the noise problem.
It should flag only the sections where human review is actually required. For each one, it should say:
- what file, function, or area needs attention
- what changed
- why this section is critical
- what the reviewer should look for
If nothing critical is found, it should say that plainly.
That last part matters. The report should always exist. If there are critical sections, show them. If there are none, say none were identified. The reviewer should not have to infer whether the step ran.
It also needs a failure mode. If the diff is too large for the agent to inspect the changed files and nearby context properly, it should say the attention map is incomplete. It should not pretend to classify everything. It should not mark the whole PR as critical to sound safe. It should say: I could not inspect enough to answer this question.
That is the honest failure mode.
How I implemented it
I added this to my pre-pr-review skill.
The shape is:
normal pre-PR review → deeper review → human attention map
The normal pre-PR review checks the branch against the work that was requested. It looks for unrelated churn, missing verification, repo-specific rules, and the usual things that should happen before opening a PR.
Then the deeper review runs. In my workflow, that means a stricter maintainability pass. It is useful, but it is still mostly about code quality.
The human attention map comes at the very end.
That placement is deliberate. I want it to be the last thing the author sees before opening the PR, and the easiest thing to paste into the PR description for the GitHub reviewer.
The map is generated by an explore agent. It does not scan the whole repo by default. It starts from the changed files, then pulls in enough surrounding code to understand the risky section. That might mean the enclosing function, the migration context, the deployment script around the changed line, or the nearby auth flow.
The agent is allowed to use judgment. I do not want a deterministic list of filenames where infra always means critical and components always means safe. That is too crude. The LLM should decide whether the changed section is actually critical, then explain why.
But the output is constrained.
It must flag only critical sections. It must explain why the section matters. It must tell the human what to review. It must always print the section, even if the deeper review found other issues. And it must be Markdown that can be pasted into a PR.
The goal is not to block the PR.
The goal is to make the review legible.
Takeaway
AI makes review attention scarce. Before a PR is opened or merged, ask one more question:
where does a human actually need to slow down?