The Death of the Pull Request: Why Supervising AI Is Breaking Software Craft

Perhaps AI did not break code review. Perhaps it exposed how much we were asking code review to do.

A pull request containing twelve changed lines feels manageable.

You open the diff. You understand what the author intended. You notice an unnecessary condition, leave a comment, check the tests and approve.

Then comes the machine-generated version.

Forty-seven files.

Nine hundred changed lines.

A new abstraction nobody requested.

Tests for the abstraction.

Documentation for the abstraction.

A tiny helper function with a wonderfully confident name that turns out to duplicate something the codebase has contained since 2021.

The entire thing may have been produced in minutes.

Reviewing it will not take minutes.

This is the strange imbalance emerging inside AI-assisted software development: machines have dramatically reduced the cost of producing code while leaving the cost of understanding it stubbornly human.

Yesterday's bottleneck was writing.

Tomorrow's may be reading.

The pull request was designed for a slower world

Pull requests made sense when producing code was expensive.

A developer spent hours or days solving a problem. By the time the work reached review, the amount of new material another engineer had to inspect was constrained by the author's own typing speed, debugging time and capacity to think.

That natural throttle is disappearing.

Rachel Laycock, CTO at Thoughtworks, recently pointed to data showing significant lines of code per human-landed diff at Meta reportedly increasing 106 percent in a year, while DX data showed median pull-request size increasing 64 percent. Her argument is not simply that AI produces too much code. It is that we may be using code review to solve problems that should have been solved earlier.

That distinction matters.

The reflexive response to an overloaded review queue is: how do we review faster?

Perhaps the better question is: why did we wait until somebody had already built the thing to discuss whether it should be built this way?

We put the important conversation at the end

Consider what teams expect a pull request to accomplish.

Catch bugs. Teach junior developers. Spread architectural knowledge. Maintain coding standards. Check security. Encourage collective ownership. Debate implementation choices. Preserve quality.

That is an extraordinary amount of institutional responsibility to place on a screen showing green and red lines after the work has already happened.

Suppose an engineer, human or machine, spends three hours implementing the wrong architecture. The reviewer now has two unpleasant options: approve something they dislike, or ask for major changes after most of the work has been completed.

AI magnifies this problem because the cost of getting to the wrong finished implementation is approaching zero. A coding agent does not resent rewriting 600 lines. The human reviewing those 600 lines certainly resents reading them twice.

Move judgment left

Software engineering has spent decades learning a simple lesson: cheap feedback is early feedback.

Test before deployment. Validate inputs before processing them. Catch security problems before production.

Why should architectural judgment be different?

If a change affects an important subsystem, perhaps the most valuable review happens before the agent writes anything. Five minutes at a whiteboard. A short design note. A conversation about constraints. A statement of what must not change.

Then the agent can operate inside those boundaries.

Laycock's argument is essentially to move many of the benefits associated with code review earlier — through pairing, collective design, automated testing, static analysis, fitness functions and other short feedback loops. Human review remains valuable, but becomes an exception for changes where judgment is genuinely scarce.

That is a very different philosophy from asking a senior engineer to inspect every line simply because a machine can produce every line.

Review by exception

Not every change deserves equal scrutiny.

Renaming an internal variable and modifying an authentication boundary should not enter the same ceremonial queue. Neither should an automatically generated dependency update and a redesign of the payment system.

An AI-native engineering workflow might classify changes instead. Routine transformations could be validated automatically. Small, reversible changes could move quickly. Human attention could be reserved for changes with a large blast radius, unfamiliar architecture, sensitive data, ambiguous product behaviour, or a developer who says: I am not confident about this.

That sentence might become one of the healthiest artifacts in software development. Not every uncertainty needs another test. Some require another mind.

The human-in-the-loop myth

Technology companies love the phrase human in the loop.

It sounds reassuring. The machine acts quickly, but somewhere inside the system sits a human with judgment, ethics and common sense, ready to catch anything dangerous.

The problem appears when that human becomes the loop.

If one engineer must approve output from five tireless agents, the architecture has not preserved human judgment. It has converted human judgment into a queue. The person who once designed software now spends the day inspecting it.

That is not collaboration between human and machine. It is supervision. And supervision at machine velocity is exhausting.

Human judgment is slow because understanding is expensive. That expense is often the feature.

Software craft happens before the diff

There is something revealing about watching two experienced engineers discuss a problem before touching the keyboard.

They talk about what already exists. They remember the outage from three years ago. One says: we tried this once. Another points at a diagram. Someone asks what happens if the queue is delayed.

The solution gradually gets smaller.

By the time they start writing code, half the work has already happened. An AI agent sees almost none of this unless we deliberately give it that context.

So perhaps the future engineering workflow is not: prompt, generate, review. Perhaps it is: understand, design, constrain, generate, verify.

That looks less magical. It also looks much more like engineering.

The scarce resource was never code

We may eventually produce software in which machines write the overwhelming majority of implementation code.

That does not make human engineers irrelevant. It changes where their value sits.

Knowing what the system should do. Recognizing a dangerous abstraction. Understanding which compromise will become painful next year. Knowing which constraint matters despite never appearing in the ticket. Seeing that the elegant solution is wrong for this team. Knowing when not to build.

These qualities do not appear naturally inside a pull-request diff. They exist before it.

For twenty years, software teams treated code review as the final gate of quality. AI may force us to admit that the gate was placed too late.

The future of software craft may depend less on teaching humans how to review machine output faster, and more on ensuring the important human thinking happens before there is so much machine output to review.

Maybe the pull request does not need a better AI reviewer. Maybe it needs a smaller job.