Agents got faster at writing code. Nobody got faster at reading it.
Ask an engineering lead what actually changed this year and you tend to get a version of the same sentence. We ship more and understand less.
The numbers being published support the feeling. Codacy's write up of the review bottleneck describes teams fielding dozens of pull requests a day against a handful of reviewers, and reports that most engineers do not trust that agent written code is correct even when it looks correct. Analyses of pull request timing find that agentic PRs sit unclaimed for multiples of the time a human authored one waits. The queue is not where the writing happens. It is where the reading does not.
The part that is not a tooling problem
A reasonable response is to point more agents at the review side, and that helps with the mechanical half: style, obvious defects, missing tests. It does not touch the half that matters. A paper arguing that coding agents supersede human inspection got a rough reception on Hacker News, and the most useful objection in the thread was that a central purpose of review is making sure humans understand what the software actually does. You cannot delegate that to the thing that wrote the code, because the point of the exercise is the state left behind in a person's head.
Which reframes the bottleneck. It is not review capacity. It is comprehension capacity, and comprehension is expensive in a way that generation stopped being.
Give people something to read
If comprehension is the constraint, the lever is the artifact you hand a reviewer. A 2,000 line diff is a poor teaching instrument. A page that says what changed, why, what is risky, and what to read first is a good one, and the agent that wrote the change is well placed to draft it. We wrote about that specifically in your PR needs an explainer.
Someone put the general version of this better than we have. In a post about building an HTML sharing skill for Claude Code, the author notes that teams are getting better at producing ideas and worse at understanding each other's. That is the whole problem in one line, and it is not really about code review. Code review is just where it shows up first, because that is where a team is contractually obliged to read.
One practical constraint: this cannot be a Claude only workflow. A good share of what arrives in review now comes from Codex, from Cursor, or from a pipeline with no chat attached, so wherever explanations live has to accept a file from any of them rather than from one vendor's conversation.
None of this makes review fast. Reading is the slow part on purpose. The goal is to stop wasting the reading you already do.