When AI coding agents write more of the code, code review becomes the slowest step, because people still read every change. The fix is to stop asking review to answer "does it work". Let automated end-to-end (E2E) checks answer that before a reviewer opens the pull request, and keep review for intent, design and risk.
Agents raise output while review capacity stays the same
AI coding tools are now part of daily work. Qodo reports that 82% of developers use AI coding tools daily or weekly [Qodo]. The Stack Overflow developer survey found that 51% of professional developers use AI tools daily [Stack Overflow].
An agent can open a pull request in minutes. The number of people who understand the system well enough to approve that pull request does not grow at the same rate. So the queue forms in front of the reviewers. Adding more agents makes the queue longer, not shorter.
Review is being asked to do a job it was not built for
Code review is good at some questions. Does this change fit the design? Is the naming clear? Does it open a security hole? Is there a simpler way?
Review is weak at one question in particular: does the product still work? A reviewer cannot run every user flow in their head. They cannot see how the change behaves with real data, in a real browser, next to changes from other services. When reviewers try to answer that question by reading, one of two things happens. Either review slows down, or approvals become a formality. Neither is a good outcome when an agent wrote code the reviewer has not seen before.
Split the questions between checks and people
The practical move is to divide the work.
- Automated checks answer: do the critical user flows still pass on this branch? Do the unit and integration tests still pass?
- People answer: is this the right change? Is it safe? Does it fit where the system is going? Should it merge now?
This split changes what a reviewer reads. They no longer need to trace every branch of the new code to guess whether checkout still completes. The E2E check already tried it. The reviewer can spend their attention on the parts only a person can judge.
It also changes what you ask of the agent. The agent should run the checks itself and fix failures before it asks for review. A pull request that arrives with red checks is not ready for a person.
Make passing checks a condition for review
A check that can be ignored will be ignored when the queue is long. Make it required. On GitHub, after enabling required status checks, all required status checks must pass before collaborators can merge changes into the protected branch [GitHub]. On GitLab, you can configure your project to require a complete and successful pipeline before merge [GitLab].
Then set a team rule: reviewers pick up pull requests whose checks are green. This one rule removes a large part of the back and forth between agent, author and reviewer. For the continuous integration (CI) setup, see running E2E tests on every pull request and the CI docs.
Keep the failure signal clean, or reviewers stop trusting it
This approach only works if a red check means something. If tests fail for reasons unrelated to the change, people learn to rerun and merge. At Atlassian, test flakiness was responsible for as much as 21% of master build failures in the Jira Frontend repository [Atlassian]. A signal with that much noise pulls reviewers back into manual checking.
Three habits keep the signal clean:
- Find and fix flaky tests, or quarantine them with an owner. See how to reduce flaky tests.
- Separate "the page structure changed" from "the behaviour changed". The first is test maintenance. The second is a decision for a person.
- Give every failure a short diagnosis, so the author knows within a minute whether the app, the test or the environment is at fault.
How AI Testing Platform fits
AI Testing Platform runs a suite in CI with one command and reports a pass, fail or healed status per test as a check on the pull request; whether that check blocks merges is your branch protection rule. Locator and layout changes are healed and recorded for review, while a changed behaviour fails and gets a triage card with the failing step, the page state, the diff from the last passing run and a proposed classification. See failure triage and the agent-first teams page.