AI Pull Request Size Limits Are How Teams Win Back Code Review Time

AI pull request size limits are the most direct way to win back the time that AI coding tools save and code review then absorbs. Michael Hill reports in a recent article that the time savings developers feel are shrinking fast, and this piece extends one claim from it: the review stage is where the gains go.

Hill reports that review work is eating the hours AI saves

Hill summarizes Atlassian’s 2026 State of Developer Experience report, a survey of 1,155 developers and 405 engineering leaders. In it, 87% of developers say AI helps them write and ship code faster, yet 72% report the same or more friction across the delivery lifecycle. The share of developers saving at least 10 hours a week with AI fell from 68% in 2025 to 25% in 2026, and 65% now regularly spend time reviewing, debugging, and correcting AI-generated code. He points to the familiar image of a 900-line pull request described only as a refactor.

He also reports that the older friction remains: finding information, meetings, context switching, tech debt, and unclear requirements top the list. Only 17% of developers and 23% of leaders say their organization has a clearly communicated and implemented AI strategy, and developers in organizations that do are twice as likely to report less friction than before AI.

Google’s review logs show that change size sets review speed

The best public evidence on how review behaves at scale comes from Modern Code Review: A Case Study at Google, by Caitlin Sadowski, Emma Söderberg, Luke Church, Michal Sipko, and Alberto Bacchelli, presented at ICSE-SEIP 2018. The authors analyzed review logs for 9 million reviewed changes. The median change modified 24 lines. Over 10% of changes modified a single line, over 35% touched a single file, and about 90% touched fewer than 10 files.

Speed tracked size. Authors waited a median of under an hour for first feedback on small changes and about 5 hours on very large ones, and the overall median latency for the whole review was under 4 hours. The paper sets this against earlier figures from Rigby and Bird, who reported median changes of 44 lines at AMD and 263 lines at Lucent, and median approval times between 14.7 and 19.8 hours at the projects they studied. The Google authors also cite prior work finding that useful comments decrease and review latency increases as changes grow.

One detail bears directly on AI output. At Google, comments per change rose with the number of lines changed, peaking at 12.5 comments for changes of about 1,250 lines. Changes larger than that drew fewer comments, and the authors note that such changes often contain auto-generated code or large deletions. Read with Hill’s 900-line example, I take this as a warning: past a certain size, reviewers stop engaging line by line, and a change that needs scrutiny can pass through with less of it.

Google exempts generated changes only when the tool is trusted completely

Google’s public engineering practices guide, Small CLs, turns that data into a rule of thumb. It says 100 lines is usually a reasonable size for a change and 1,000 lines is usually too large, and that a 200-line change spread across 50 files would usually be too large as well. Reviewers may reject a change outright for its size alone.

The guide allows one exception that matters here. Large changes are acceptable when produced by an automatic refactoring tool “that you trust completely,” so the reviewer only has to confirm the change is wanted. AI-generated code looks like that category because a machine produced it in bulk. It fails the condition that justifies the exemption. Hill’s figure that 65% of developers regularly correct AI-generated code is the evidence: a tool whose output people routinely fix is a tool they do not trust completely. AI-written changes should therefore be held to the size limits for human-written code.

A size limit turns an AI strategy into a rule a reviewer can enforce

Hill’s strongest finding is that few organizations have a clear AI strategy, and that the ones that do see less friction. A strategy document rarely reaches the moment a reviewer opens a pull request. A size limit does. I would put three mechanics in place. First, the team sets a budget for lines and files per change, starting near Google’s 100-line guidance and adjusting from its own data. Second, a reviewer may return an oversized change without reading it, and the author splits it, which keeps the cost of generating more code with the person who generated it. Third, the team reports first-review latency by size band and the share of changes over budget, in place of counts of prompts or accepted suggestions. Exemptions stay narrow: file deletions and deterministic codemods whose rules the team has reviewed.

The boundary conditions are real. Google’s numbers date from 2018, before AI coding assistants, and come from one company with its own review tooling, so each team should treat them as a reference point and set its own baseline. Splitting work multiplies the number of reviews; the same study found the median developer reviews about 4 changes a week, and a flood of small changes can still swamp a reviewer. The Small CLs guide itself warns that waiting on each review wastes time unless authors work in parallel. Line count is also a crude proxy, since a 40-line change to an authorization path can deserve more scrutiny than 400 lines of test fixtures. And a size limit does nothing for the information and meeting friction that Hill reports at the top of the list.

Why This Matters for Engineering Leadership

Code review is the point where an organization records that a named person understood and accepted a change. From an AI governance view, that record is only as good as the reviewer’s ability to read what they approved, and the Google data shows that ability falls as changes grow. AI tools make large changes cheap to produce, so the size of what reaches review is now a leadership decision. Leaders who set a size budget, protect a reviewer’s right to return oversized work, and measure latency by size band will see whether AI is shortening delivery or just lengthening the queue.

FAQ