.svg)
For more than twenty years, code review has been the gatekeeper of quality in codebases. Before code ships, another engineer reads it, challenges it, and decides whether it is safe to merge.
AI coding agents break the premise that made that system workable. One engineer can now generate more code in a day than their teammates can realistically read. If writing code keeps getting faster but reviewing it does not, the review queue becomes the new constraint—and line-by-line scrutiny stops scaling.
So what guards quality when people can no longer inspect every line? We asked five engineering leaders the same question: how has your team changed the way it does code review now that AI writes much of the code? Their answers range from reviewing specs instead of diffs to automating low-risk changes, testing agent output at scale, and making ownership of the merge explicit.
1. Review the spec, not the diff
The earlier you catch a problem, the cheaper it is. Code review happens late, so instead of trying to review more code faster, we moved the review upstream.
For larger initiatives, we write a detailed, code-level spec, then have the AI implement the entire stack of merge requests against it. It might discover a problem at MR three, rewrite the spec, and go back to fix MR one and two. The author reviews the result, then presents the spec to the team alongside a working demo.
Reviewers focus on whether the implementation matches the intent and whether the requirements were understood. That catches the wrong approach before the team reaches MR five of eight.
Restarting used to be a colossal waste of time. Now it’s a colossal waste of tokens, and we don’t care about tokens.
2. Tier by risk, and don’t review the low tier at all
We bucket every decision into low, medium, or high risk. If something is low risk, we don’t review it.
We don’t index on the PR, because PRs are cheap and kind of meaningless now. We index on the ticket: what are you trying to accomplish, and why.
AI classifies each ticket by domain. A low-risk change can proceed through deployment automatically. A high-risk change fails the automated gates and requires a person to review it, using the CI/CD and rollout controls already in place.
The medium tier is less obvious. If a change passes three of five gates, an engineer gets tagged and it’s choose-your-own-adventure: reclassify it as low risk, approve it and let the robot roll it out, or take it over. Since rolling this out, unhealthy connectors are down 60 to 70 percent, with 30 percent fewer people. The goal is to reserve human attention for the decisions where judgment changes the outcome.
3. Admit the pull request was already broken
The PR was broken before AI showed up. It was invented as a gatekeeper for open source: put up a wall and keep strangers on the other side. That makes less sense inside a company trying to deliver software quickly.
Now add agents. When one writes a PR every five minutes, basic queuing theory says the queue grows forever. Turning engineering teams into full-time reviewers of agent output prevents them from shipping the software they are now capable of building.
Feedback has to arrive sooner and rely more on machine verification. When AI proposes a fix for a flaky test, we run it a hundred times to establish confidence before a developer ever sees it.
People say you can’t specify software in English. We already do: we write Jira tickets and assume a human with different context will build exactly what we meant.
It’s a guessing game; we’re just mad the machines are making bad guesses too.
4. Accept that someone owns the merge button
Writing code has become trivial in terms of time. The review cycle is now the bottleneck, and neither side has much incentive to engage with it: the author doesn’t want to reread a thousand-line diff their agent generated, and the reviewer has even less reason to read a thousand lines nobody actually wrote.
Some teams in our department dealt with this honestly. They declared PR review bankruptcy.
I cannot review code if it’s 1,000 lines. That’s not sane.
In some cases, AI reviewing AI replaced human review, which I find very debatable. But accountability hasn’t changed. When you push the merge button on GitHub, you are responsible for that call, whether the code came from Claude Code, Copilot, or Codex.
Some companies make that responsibility explicit: click merge, and you own the change for the next ninety days, regardless of which agent wrote it. The workflow changes, but accountability stays with the person who merges.
5. Ask two questions: how risky, and how much judgment?
Two factors determine whether we automate a process: judgment density and risk.
When judgment density is high, as it is in production or in emails sent to customers, you want a human in the loop. When both judgment and risk are low, you can automate the process entirely. Dependency updates are a good example; AI handles those as part of the regular development cycle.
High-risk work always needs a person, even when the judgment density is low. Production is both high risk and high judgment: if AI makes a mistake and takes the system down, horrible. That’s why our PR policy puts a named human owner on every piece of AI-generated code.
Whether someone prompted their way to a PR or our agent picked up a Linear ticket, the first review is a real person, the owner.
A second person reviews it afterward, not primarily to find bugs, but to ensure that knowledge of the code survives vacations and departures.
The new job of code review
The pull request used to concentrate three jobs in one place: checking whether the implementation matched the intent, finding defects, and deciding who was willing to let the change ship. AI is forcing teams to separate those jobs.
Intent can be reviewed earlier, in a spec. Defects can be challenged continuously by tests and automated gates. Risk determines how much scrutiny a change deserves. But the final decision still belongs to a person who understands the consequences and is prepared to own them.
That is the tension at the center of all five answers: teams cannot keep treating every generated line as equally worthy of human attention, but they cannot automate responsibility away. The future of code review is therefore less about reading everything and more about deciding where human judgment matters—and making sure it is present when it does.
