A Pull Request Is a Coordination Tool

The Diff Is Only One Part

Mark Jason Dominus described the primary purpose of code review as finding code that will be hard to maintain. I think that is right. It is also a much better description of review than the usual claim that a second developer will somehow spot every bug by reading the diff.

But it does not explain the whole value of a pull request.

A PR is not just code presented to another programmer. It is a way to organize a piece of work for everyone affected by it.

One Change, Several Audiences

A useful change crosses more boundaries than the repository makes visible.

• The author needs a boundary around what is and is not part of the change.
• The reviewer needs the intent and tradeoffs, not only the implementation.
• QA needs to know which behaviour moved and where the risk is.
• Product owners and clients need to see whether the result solves the problem they asked about.
• Operations needs deployment, migration, monitoring, and rollback context.
• The next developer, or the next AI agent, needs a durable explanation of why the change was accepted.

Those people do not all want the same level of detail, but they do need to be talking about the same unit of work. The pull request gives that work a name, a boundary, a history, and a place for evidence.

A PR Turns Activity Into a Deliverable

Without that boundary, a project becomes a stream of commits, chat messages, screenshots, test results, and half-remembered decisions. Each artifact may exist somewhere, but nobody can see the whole change.

A good PR gathers the important parts:

• the problem and intended outcome;
• the implementation and its scope;
• the alternatives and tradeoffs;
• the test results and preview;
• the risks, deployment plan, and rollback path;
• the questions that still require a decision.

That is not paperwork attached to the work. It is the structure of the work.

It lets a client comment on the outcome without reviewing a function. It lets QA start from the risk instead of reverse-engineering the ticket. It lets operations see that a schema change is coming. It lets a developer understand why an odd-looking compromise survived review six months ago.

The Best Asynchronous Meeting

Most coordination problems eventually turn into a meeting because the information is scattered and the decision is unclear.

A well-formed PR is an asynchronous meeting with a better memory. The agenda is the intended change. The demo is the preview. The evidence is attached. The discussion stays beside the decision it affected. Approval records who was comfortable moving forward.

Not every stakeholder has to read every line. They can enter at the layer that belongs to them and still leave their input on the same artifact.

AI Makes This More Important

AI can generate more code, more quickly, across more parallel branches of work. That makes organization more valuable, not less.

If an agent can produce a feature in an afternoon, the bottleneck shifts from typing the code to understanding what changed, verifying it, and deciding whether it should ship. A PR creates the checkpoint where that happens. CI supplies the test evidence. AI can summarize and review the diff. Humans make the product, client, and operational decisions.

This is why I think AI should make your pull requests better rather than make you abandon them. The mechanics of producing review context are cheaper than they have ever been. The need for a shared coordination artifact has not gone away.

Review Is Part of It, Not All of It

Code review still matters. Another developer can spot code that is opaque, fragile, or dependent on context that never made it into the repository. But that review is one contribution to a larger decision.

The real output of a pull request is not an approval badge. It is shared understanding: what we changed, why we changed it, what evidence we have, who it affects, and what we agreed to do next.

That is why PRs are useful even when the code is written by one person, reviewed by AI, or shipped by a very small team. They turn motion into organized work, and organized work is something other people can actually participate in.

Header photo by Kvalifik on Unsplash.