Agents Multiply Pull Requests Faster Than Teams Can Review Them

Agents make it easy to open more pull requests; they make it only slightly easier to open ones worth reviewing. That imbalance, Matt Pocock argues, intensifies a bottleneck organizations already had: PRs waiting for someone to inspect them. The problem is not simply how quickly code gets written. It is how to keep a growing flow of changes reviewable.

Pocock describes a “software factory” as a system in which agents can initiate work, not just carry out tasks a person starts. A bug report or support ticket might be classified and turned into a proposed fix or reproduction. A slow database query might trigger a different workflow. These inputs accelerate the flow of code through the factory, even when no person initiates each task.

Acceleration without restraint produces what Pocock calls a “slop cannon”: more low-quality PRs than anyone can inspect. His countermeasure is to build brakes into the system—mechanisms that slow output while raising its quality. The stakes extend beyond a bad change making it into a release. Code is the environment agents work in, he says, and poor code in that environment can lead to more poor code.

His proposed process has three layers: deterministic automated checks, agent-based automated review, and human review. Checks catch failures that can be tested consistently; automated review looks for problems those checks may miss; humans decide what needs judgment and attention. More speed means more PRs, but the goal is not to ask people to review every change at the same depth. It is to make the earlier layers strong enough that human review becomes faster and more selective.

Automated checks—tests, linting, typechecking, and code-quality rules—cost CPU cycles rather than human effort or the tokens used by an agent. Pocock’s practical implication is that teams can run many of them, and may not be using enough. A test that catches a bug may lead to more agent work to fix it, but he considers that effort well spent.

A passing check still does not prove that a change is ready to merge. Checks can “lie”: they may pass without establishing the behavior that matters. Pocock describes automated and human review as lie detectors for those checks.

One example is a tautological test. An agent defines X_POST_CHARACTER_LIMIT as 280, then tests it by asserting that the constant equals 280. The test repeats the implementation instead of checking behavior. Pocock calls this structure-sensitive: change or rename the constant and the test can fail even if the system still behaves correctly. The test is coupled to how the code is written.

A more elaborate test checks that a “Videos” section appears after “Content Plan” on a page. It does not render the page and check what a user sees. Instead, it reads the source file, searches for those labels, and compares their positions. Rearranging the source could break the test without changing the page’s behavior. The test verifies where text appears in a module, not the order of sections in the interface.

Mocking can conceal the opposite problem: a test that cannot expose a real failure. In Pocock’s example, a useAudioBoost function uses the browser’s AudioContext API. The test replaces that API with fake methods. The real API has error modes the mock does not reproduce, so the test can pass while production encounters a failure.

Pocock does not claim that agents deliberately write bad tests. Rather, they can follow instructions in ways that check implementation details instead of executing code meaningfully. The design question is how to make checks harder to satisfy without establishing that the behavior works.

Pocock’s first answer is to improve codebase design, particularly by creating “deep modules”: modules that hide complex behavior behind simple interfaces. He contrasts a module with a substantial implementation behind a small interface with one that exposes many functions, each doing relatively little. The first gives callers a simpler point of contact.

When tests exercise behavior through a small public interface, they depend less on internal structure and are less likely to break just because the implementation changes. Pocock’s advice is to steer agents toward those interfaces rather than letting them reach into implementation details to test them.

His /improve-codebase-architecture skill identifies opportunities to restructure code into deeper modules. One displayed example starts with three components that each contain a hand-written version of the same compound visibility rule, with no shared name and no unit test. The proposed change extracts named predicates into visibility-predicates.ts, where they can be tested independently and called from all three components. The rule becomes local to a testable module instead of being repeated across components: one interface serves three call sites.

The skill also supplies language for discussing design. Pocock highlights locality—whether related code is located together—and leverage: the value a caller gets from a simple interface backed by a deeper module. He also mentions seams. His point is that teams need terms they can use consistently to discuss code structure, rather than relying on an assortment of approaches that may all be given the same label. He sees these qualities as useful for agents as well as people.

Pocock argues against loading coding standards into the agent that implements a change. An implementer has to explore the codebase, make the change, and spend time debugging and verifying it. Adding the job of applying broad standards to that same context makes an already demanding task harder.

Instead, his /code-review skill receives a diff, reads a repository-specific CODING_STANDARDS.md, and checks the change against those standards. It runs as a subagent with its own context window. The reviewer needs to explore enough surrounding code to understand the diff, but does not need to implement or debug it. In Pocock’s terms, implementation is overloaded while review is underloaded.

The division gives each stage a distinct purpose: /implement makes the change work; /code-review makes it good. Pocock compares the sequence to red-green-refactor: one context window handles the initial implementation and verification, and another handles refactoring against the standards. It is a two-part process, not an attempt to produce ideal code in one pass.

For the same reason, he recommends keeping coding standards out of a global file such as AGENTS.md. Standards placed there may compete with implementation instructions or be inconsistently applied. A dedicated CODING_STANDARDS.md gives the review agent a specific place to find and apply them.

Pocock also advises teams not to outsource automated review wholesale. A generic reviewer can be too broad and produce irrelevant false positives, or so specialized that it does not transfer across languages and contexts. His preference is to build and refine standards for the team’s own codebase, and share them across the team.

The reviewer should usually fix what it finds, not merely leave comments for a human to interpret and address. Comments can create more work: the human reviewer must read each one and decide what to do. Pocock’s default is for the agent to commit corrections, leaving a more finished artifact for human review. It can still ask questions when uncertain, but comments should not be the automatic output.

A human-friendly PR, in Pocock’s account, combines good code with a concise description and concrete evidence. His /pr skill was still in progress at the talk, but he used it to explain how a PR can help reviewers direct their attention.

First, not every change deserves the same level of scrutiny. Pocock asks reviewers to think of a PR as a one-way or two-way door: how easily can the change be reverted? Most software changes, he says, are reversible. But the apparent size of a diff is not a reliable guide to reversibility. A small change that sends an email to 60,000 people can have consequences that cannot be undone. Expensive migrations and data loss also make a change effectively one-way. Those PRs deserve especially careful review.

He pairs reversibility with blast radius: what could go wrong, and how bad would it be? One displayed merge-danger summary describes a change to error-message rendering as a two-way door, trivial to revert, with localized effects and no API, schema, or control-flow changes. This kind of summary helps a reviewer judge how much attention to give the change before deciding where to look closely. It does not replace reviewing the code; it makes the stated risk legible.

Reviewers also need to understand what a change is for before studying its implementation. Pocock’s preferred aid is pseudocode or a diagram that explains the “why.” He credits Dex Horthy’s /show-me skill from the HumanLayer skills repository, which presents changes through images and diagrams rather than relying on long prose.

One example diagrams a lesson being dragged into an empty section. The section changes from empty to real, which renumbers the paths of real sections; an update then writes a numbered title. The sequence makes the underlying issue visible: a title intended to reflect domain language has become a derived, numbered field. The diagram helps explain the behavior and the reason for the change without asking the reviewer to infer the system’s flow from the diff alone.

Another summary concerns a command-line change for clips. Clip was the item with soft deletion but no way to restore it, while related entities either lacked an archive round trip or offered an archived-list view without restoration. The change adds a clip restore command, described as idempotent, and adjusts how archived clips are found. The summary explains why this particular item needed the change and shows the resulting commands. For Pocock, making that rationale quick to grasp is part of making review faster.

Pocock’s final principle is to make human review matter beyond the individual PR. When teams share skills, standards, and other instructions for agents, the process that produces the code becomes as important as the code itself. A reviewer should be looking at the system that created the change, not only at the lines in front of them.

That leads to a rule: do not write the same review comment twice. If an agent repeats a mistake across PRs, the useful response is not to keep correcting it by hand. The team should add a mechanism that prevents the mistake or helps the agent catch it next time.

Pocock’s /retro skill is designed to turn review into that mechanism. It can analyze a single agent session, a PR together with its session, or a set of PRs and reviews from a week. It then proposes changes intended to improve the next round of work.

Some proposals concern deterministic checks: can the issue found in human review be prevented automatically? Others concern CODING_STANDARDS.md: can the automated reviewer be taught to detect it next time? The skill also examines whether agents could find information more easily with better navigation pointers in AGENTS.md, whether tools could return results more economically in tokens, and whether bloated steering files or skills are contributing to poor results.

The intended loop compounds: human review identifies a problem; a retrospective turns that finding into a check, a standard, or a better working environment; future changes arrive in better shape. The aim is not merely to reduce effort on one PR, but to make subsequent reviews easier. Pocock’s process layers automated checks and automated review before human judgment, then uses that judgment to improve the process that feeds the next PR.