Review is where the time went

Give a development team AI coding tools and code output increases. That part works, and it is usually the part that gets measured. What surprises people is where the time goes instead.

I watched it first at a large enterprise that was just starting to put AI into its workflow. Developers were using Cursor and moving faster individually. Within weeks the queue had shifted. Pull requests were initially arriving at a thousand lines and leaking scope well past what the ticket asked for. The team had an AI review tool, Greptile, sitting on those pull requests. It found small code smells. It couldn't look at a thousand-line change and say this is three separate changes bundled into one, please split it.

That team got more out of asking Cursor to review their own and each other's work than out of the pipeline bot. A typical review went from about two hours to about ninety minutes. It was a modest improvement but swamped by the extra volume arriving. There wasn't much trust in the bot, it was just an accessory.

That was not a local problem. LinearB's 2026 benchmarks, drawn from 8.1 million pull requests across 4,800 teams, put AI-assisted pull requests at over 400 lines at the 75th percentile against 157 for unassisted ones. Reviewers take more than 16 hours on average to pick up an AI-generated pull request, against about 200 minutes for the rest. While the code output increased, reading it could not keep up.

Crossing the trust threshold

At a smaller product team developing a large and complicated application, the tool was GitLab Duo. It read the code and left comments on the logic, and the team trusted it more than the last team. It still wasn't enough. The team wanted people closely involved in every change, and with fewer people to go around, review became the bottleneck.

So we tried moving the judgment upstream. Planning became part of development and plans were reviewed for architecture and high-level logic. The idea was that code review could then be a scan rather than an investigation. The team had verying levels of trust with Duo with the code quality though, so two human approvals stayed on every pull request and the bottleneck was again with code review.

The setup that changed things was using a harness at a mid-sized business that was setup by them. They ran a tuned agent command-line tool inside their continuous integration (CI) machine. Two things made it different: It reviewed against the requirements and not just the code. And its standards were configured deliberately: review rules at the organisation level and project-specific rules in a file checked into the repository alongside the code.

This was where a threshold was crossed in terms of trust. A small pull request came back with two or three comments from the bot and none from a human. On one large complex pull request I worked on with 69 comments, about 70% of them were the bot's and the humans were still in it properly. Each review cost an average of $0.40-0.50 cents in API token costs, a miniscule amount compared to a senior engineer's time. Because the team trusted the bot's comments and that it could pick up enough code smells, the team went with the merge rule: one human approval plus the bot's instead of two humans. Per reviewer, throughput went from reviewing one pull request in a day at the other places to two or three before lunch.

Where the reviewer stops

These bot reviews weren't perfect of course. The bot is very good at whether the code does what the ticket says but it has no way of knowing the ticket is wrong.

That came up more than once. Requirements would be clarified in a stand-up and the ticket would not get updated. The reviewer, working from what was written, would want to satisfy the stale version. In another review it wanted extra API calls added so that a single piece of data would display exactly as specified. The right answer wasn't to write that code and instead go back to the Product Owner and soften the requirement; trading a little nice-to-have for reliability and performance. A human made that call by overriding the bot.

No amount of tuning will get a reviewer to that decision, because the reviewer's frame of reference is the requirement itself.

It's also worth saying plainly what the merge rule change did and didn't do. It only reallocated the review, it didn't completely remove it. The bot's approval is a required gate, not the absence of one. That distinction matters, because plenty of teams are drifting the other way. DORA's research finds 30% of developers report little to no trust in AI-generated code, and that higher AI adoption raises delivery throughput and delivery instability together. But cutting a human approval without putting something trustworthy in its place doesn't move the bottleneck, it removes a check. It's having that acceptable balance of speed and quality that really ships code to production.

What to keep a human for

Keeping the human approval that checks intent instead of checking lines of code that a bot has spit out. A person's time should be determining whether this is still the right thing to build. The nitty gritty belongs to the bot.

Feeding the reviewer context is what made a big difference. What worked best from the three setups was not a better underlying model. It was organisational review standards and project rules the team had codified themselves and reviewing against requirements rather than against the diff alone.

We have since built our own review harness on those lessons, running against a sample React Native application. It looks at a pull request along seven axes: correctness, security, performance, maintainability, anti-patterns, plan adherence and cognitive load. A separate agent with its own instructions reviews the plan. It does cost more per run than the lighter-touch setups, about $1.00 USD on average. Our expectation is that the trade-off is worth it where it saves a reviewer time and frustration. On simpler changes we think a single directly responsible engineer (DRE) could merge with light review. On complex ones the reviewer covers the detail while the DRE works the harder parts and decides whether to pull anyone else in. That is an expectation though, not a result.

The part we are confident about is the shape. A review agent that can be configured is one a team can keep evolving. Their standards go in and the reviews get closer to what the team actually cares about, and the judgment left over is something that humans are still needed for.

Not sure how to keep code review from becoming the bottleneck

The Omnia Collective works with enterprise and mid-sized engineering teams across Australia to put AI review agents into the delivery workflow, set up against each team’s requirements and standards, with a human approval kept for the judgement calls. See our AI and automation services or get in touch.

Gerald Kim is a Lead Engineer at Bound, a boutique digital consultancy combining strategy, human-centred design and engineering. Bound is part of The Omnia Collective, a group of founder-built Australian businesses across technology, design, data, AI and talent.