AI made writing code cheap. Review is now the bottleneck.
Coding agents can produce more changes than a team can thoughtfully absorb. Engineering leaders need to design for verification.
I can now ask an agent to implement an idea and come back to a pull request. That's useful. It also means I can create work for a reviewer much faster than I could before.
That changes how I think about the time agents are saving. Getting a first implementation used to take enough effort that it naturally limited how many changes a team could have in flight. Now I can get to that point much faster. Someone still has to understand the change and decide whether it belongs in the system.
A study of 278,790 review conversations across open-source projects found that human reviewers exchanged 11.8% more rounds on AI-generated code than on human-written code. That's one study, and open-source review is not every company's workflow. But the direction makes sense to me. A plausible implementation can still miss the reason a system works the way it does.
The same people still have to review all of this
Imagine five engineers each using agents to produce twice as many pull requests. If the team still has the same two people who understand the tricky parts of the architecture, those people become the queue. The team may report more code written while changes spend longer waiting, or while reviewers skim to keep up.
I don't think asking those engineers to read faster gets us very far. We have to make the changes easier to evaluate. A pull request should say what behavior is meant to change, what constraints matter, how it was tested, and what could break. Smaller changes help, but only when each one has a coherent purpose. Ten tiny PRs with a hidden dependency between them can be harder to review than one clear change.
Tests and static checks can take some work off the human reviewer. They cannot decide whether a new abstraction fits the product, whether an edge case matters to customers, or whether a migration will be safe in production. A passing test suite is useful evidence, but I would still want someone who understands the system to examine those decisions.
I would want more of the thinking to happen before the code
When an agent is given a vague request, the reviewer can end up working out the requirements after the implementation already exists. At that point, someone has to explain why the code needs to change, and then review the next version too. We have made producing the first version faster without necessarily reducing the work needed to agree on what it should do.
For consequential changes, I'd rather have the engineer specify the expected behavior, boundaries, and failure cases before implementation. Give the agent the existing patterns to follow. Require evidence for claims like “backward compatible” or “safe to retry.” Then use review to examine the decisions that remain, rather than reconstructing what the author intended from a diff.
This also changes how I'd measure the benefit of coding agents. Lines written and pull requests opened tell me very little. I'd look at time from idea to a change safely running in production, review wait time, rework, incidents, and how often the same senior engineers are pulled into every decision.
I would be fairly skeptical of a productivity claim that stops at how much more code the team is producing. If the same people are spending more time reviewing, answering questions, and fixing problems afterward, some of the work has simply moved. I want to know whether the team can get a useful change into production more easily, and whether maintaining it becomes easier too.