GitHub's AI Reviewer Lost Its Size Limit, and Now Reviews What Bots Write

GitHub removed Copilot code review's 300-file, 20,000-line cap on Aug 27, 2026. A bigger reviewer does not make a big PR safe by default.

GitHub removed the size ceiling on Copilot code review on August 27, 2026. The reviewer that used to refuse anything past 300 files or 20,000 lines of code will now read a pull request of any size, and it can now be auto-requested on pull requests a bot opened, including one from Copilot's own cloud coding agent. None of that makes a 1,000-line pull request a good idea by itself. It means the tool reading the diff got bigger, not that the reason teams kept diffs small went away.

Sources: GitHub Changelog: Copilot code review, resolution reasons and expanded capabilities

The change is specific, not a vague expansion. GitHub's own changelog states that Copilot code review 'previously had a 300 file or 20,000 lines of code limit on the size of a pull request it could review' and that 'this limitation no longer applies.' The same release adds two more capabilities on top of the size change. With the right organization policy turned on, Copilot code review can now be requested automatically on pull requests authored by bots and bill that usage directly to the organization. And a pull request opened by Copilot's own cloud coding agent now gets what GitHub calls 'a full agentic review' instead of the lighter pass it got before. Three ceilings came down in one release: how big a diff can be, who is allowed to author the pull request under review, and how thorough that review gets when the author is Copilot itself.

Sources: GitHub Changelog: Copilot code review, resolution reasons and expanded capabilities

The opposite argument ran on this site on August 19, 2026, eight days before this changelog shipped: keep AI pull requests small made the case that a coding agent's 1,000-line pull request gets rubber-stamped because no reviewer can hold it properly, not because it is correct. That argument favors a category we build in, since TLM Forge caps diff size structurally, in phases, before a human ever opens the pull request. Read what follows with that stake disclosed. GitHub did not prove the small-PR argument wrong. It shipped a capability that changes what a reviewer can process, and that is a different claim from what a team should still choose to ship, so the honest response is to say exactly where those two claims now split.

What actually changed on August 27

The August 2026 change finishes a trajectory GitHub started over a year earlier: the 300 file, 20,000 line wall that used to make Copilot code review decline some pull requests entirely is gone, not just raised. This was not GitHub's first move against large pull requests. A July 2025 changelog had already lifted 'previous system limits that prevented reviews on larger or more complex files,' motivated by the fact that roughly 30 percent of GitHub pull requests contain more than 20 files, but that release only widened what Copilot code review could handle without removing the ceiling outright.

Sources: GitHub Changelog: Copilot code review, better handling of large pull requests

The bot-authorship change matters as much as the size change, maybe more. Before this release, an agent-opened pull request could sit with no automatic Copilot review at all, or a Copilot cloud agent pull request got a lighter review than one a person opened. Now the reviewer follows the work all the way through: a bot opens the pull request, an enabled organization policy can request a Copilot review on it automatically, and a Copilot cloud agent pull request gets the same full review depth as anyone else's. A loop where machine-authored code writes itself into a queue that a machine also reviews, start to finish, is the part of this release most likely to scale fast, because neither side of that loop needs a human to press go.

Sources: GitHub Changelog: Copilot code review, resolution reasons and expanded capabilities

A bigger reviewer is not the same claim as a bigger PR being fine

Capability and advisability are different claims, and this release only settles the first one. Copilot code review being able to process two thousand lines says nothing about whether a person on the team can still hold that change in their head, and human review has not gotten faster just because the AI reviewer's ceiling moved. SmartBear's best-practice research, drawn from a study of a Cisco Systems programming team, still holds: a review of 200 to 400 lines over 60 to 90 minutes catches roughly 70 to 90 percent of the defects present, and defect density found drops significantly once a reviewer works past about 500 lines of code an hour. Nothing in GitHub's changelog changes that math, because that math describes the person signing off, not the tool that reads the diff first.

Sources: SmartBear: Best Practices for Peer Code Review

The deeper issue is accountability, not throughput. A person who approves a pull request is agreeing to answer for it in an incident review later, and that agreement only means something if the approver actually understood the change. An AI reviewer clearing a 2,000-line diff produces a green check, not comprehension transferred to a human. Taking the size ceiling off the tool that reads the diff first does not remove the separate step where someone on the team still has to be able to explain, if it comes to that, what the change was for and why it was safe.

Where a bigger-capable reviewer earns its keep

The size ceiling coming off is genuinely useful in one specific lane: changes that are large because they repeat, not because they reason. Google's own engineering practices describe how the company reviews its large-scale changes, the kind that touch millions of lines to rename an API or retire a deprecated pattern. A 'global approver' reviews the transformation rule itself once, then uses, in the book's words, 'pattern-based tooling to review each of the changes and automatically approve ones that meet their expectations,' checking by hand only the small subset that fails the pattern. A codemod, a scaffolded set of generated files, or a dependency bump touching four hundred call sites is large in line count and small in actual decision count. An uncapped AI reviewer that walks every one of those four hundred sites and flags the handful that do not match the pattern is doing the job a global approver does at Google, at a scale no single senior engineer has hours for.

Sources: Software Engineering at Google: Large-Scale Changes (abseil.io)

Mechanical refactors, generated boilerplate, dependency bumps

Three shapes of large pull request fit this lane well. A mechanical refactor, renaming a type across a codebase or moving a module without changing behavior, is large because the transformation repeats, so reviewing it is really reviewing the rule once and then spot-checking that it applied cleanly everywhere. Generated boilerplate, scaffolding for a new service or a set of typed client bindings, is large because a template expanded, not because two thousand independent decisions were made. A dependency bump touching every file that imports a renamed export is large for the same mechanical reason a rename is. In all three cases, a reviewer with no size ceiling can check every occurrence instead of a sample, which is strictly better than what a time-boxed human reviewer could manage on the same diff before this release existed.

• The change is describable as one rule: rename X to Y, upgrade package A from version B to C, move module D without touching its behavior.
• Every hunk in the diff matches that one rule when you spot-check a sample of them, with no hunk doing something the rule does not cover.
• No hunk introduces a new conditional, a new permission check, a new external call, or a new field that stores user data.
• A single reviewer, human or AI, could approve the whole class of change, not just this one instance of it, and that approval would still hold next month.

Where size discipline still matters no matter what the reviewer can do

Novel business logic, and anything touching money, authentication, or user data, sit in the opposite lane, and the reason has nothing to do with what a reviewer can read. Each line in a new pricing rule, a permission check, or a data-access path is a distinct decision nobody has approved before, so there is no pattern to check against and no shortcut to spot-checking. GitHub's own guidance for reviewing agent pull requests, published separately from this changelog, asks for a smaller pull request when the diff touches more than five unrelated files, when nobody can state its purpose in one sentence, or when the agent produced no implementation plan at all. Those are tests of scope and intent, not line count, and they apply exactly as hard to a pull request Copilot can now technically finish reading in one pass. A reviewer with no size ceiling can still fail every one of those three tests on a single, tightly scoped, high-stakes diff.

Sources: GitHub: Agent pull requests are everywhere. Here's how to review them

Blast radius is the variable that actually decides this, not diff size. A rename that goes wrong breaks a build, and the build tells someone immediately. A billing rule that goes wrong charges the wrong customer, and nothing in CI catches that class of mistake before a person does. Authentication code that goes wrong grants access it should not, quietly, until an audit or an incident surfaces it. User data code that goes wrong can turn into a breach disclosure. None of those outcomes gets safer because the reviewer that first looked at the diff no longer has a file-count limit. Size discipline was never really about how many lines a reviewer could physically get through. It was about keeping high-consequence, low-precedent work small enough that one specific person can trace every decision in it and still be willing to own the outcome.

This is the distinction TLM Forge is built to make before a pull request exists, not after one lands for review. A spec audit decides up front whether a piece of work is a mechanical transformation or a novel decision, phase-gated TDD keeps each phase to one of those two shapes instead of letting them blend into a single diff, and the convergence gate will not let work ship while a critical question, mechanical or not, is still open. An uncapped AI reviewer is a better tool for reading whatever diff arrives. It is not a substitute for deciding, before the agent writes a line, which kind of diff this is supposed to be.

That classification deserves to live somewhere durable once it is made. Whether a given class of change, this API rename, this scaffold template, this dependency, was reviewed once and approved as mechanical is exactly the context that gets lost between sessions and re-argued every time a pull request of the same shape shows up again. That classification belongs in a durable, searchable place tied to the pattern itself, a labeled PR template, an internal doc, not in one reviewer's memory of having seen it before. MemX, from the same team behind TLM Forge, addresses a personal version of that same problem: a private, persistent memory layer for an individual's own photos, documents, voice notes, and messages, not a team's review classifications.

GitHub removing the size ceiling on Copilot code review is a real capability change, not a policy statement about how big your team's pull requests should be. Let the uncapped reviewer take the mechanical work it is now genuinely good at: renames, scaffolds, dependency bumps, anything large because it repeats. Keep the discipline for work that is large because it decides something new, especially anything that touches money, authentication, or user data, because the reviewer's page limit was never the reason that work stayed small. The constraint was always the size of what a person is willing to sign their name to, and nothing in this release moved that number.