Pull request review

Green checks are not a product decision.

AI assistants now write more code than any team can read. Passing tests and an AI review show that the code runs. Someone still has to notice when the product changed, and the best moment is soon after the merge, before the change reaches your customers.

14 November 2026 · 6 minute read

The review that no longer happens

A few years ago a pull request was a few dozen lines that a colleague wrote and you could read in ten minutes. Today an assistant can produce hundreds or thousands of lines in an afternoon, across files the reviewer has never opened. The team still has the same number of reviewers and the same number of hours.

So review has changed shape. Some pull requests get a quick skim and an approval. Others are passed to a second AI agent that is asked whether the code looks good, and when it says yes, a person clicks approve. Nobody is being careless. The volume is simply larger than careful reading can handle.

What an AI review can tell you, and what it can’t

An agent that reviews a pull request is good at what code review has always covered: bugs, risky patterns, missing error handling, style, unclear names. It answers the question “is this code reasonable?”, and that is a useful question.

It cannot answer “is this what the product is supposed to do?”, because that answer is not in the diff. It lives in a product manager’s head, in a ticket from last spring, in a regulation, in a promise made to a customer. An agent that reads only the code will judge the code on its own terms.

Tests do not close the gap either. When the same assistant writes the change and the tests, the tests record its understanding of the task, and they pass because they were written to pass. When one pull request changes the code and the tests that cover it, a green run shows that the two agree with each other. It does not show that either agrees with the product.

An example

Nothing in this story is a bug. The code is clean, the tests pass and the reviewers did their jobs. What is missing is a product decision, and it was taken by default. The sooner someone notices, the cheaper it is to reverse.

Two questions, one approval

Approving a pull request has always meant answering two questions at once. At today’s volume, only the first still gets attention, and more and more of that comes from machines.

Catch it after the merge, before production

Between a merge and production there is usually a gap: a staging environment, a release train, a feature flag, a few hours or a few days. That gap is the time to catch a product change. The earlier in it a change is noticed, the more options there are: ship it, reword the specification, or fix the code before a single customer sees it.

Ship only what is aligned with the specification, or what a person has accepted as a change to the product.

SpecTrail checks each merged pull request against the specification. That check has three outcomes, and only the last one involves a person:

1. Nothing the customer sees has changed.

   Refactors, renames, performance work and styling pass without a word. Nobody is asked anything.

2. Behaviour changed, and it was agreed.

   The change matches a requirement that was already accepted. It passes, with a link to that requirement.

3. Behaviour changed, and nobody agreed.

   The change is flagged and waits for a decision: accept it and update the specification, reword it, or deny it and open a ticket because the code is wrong.

Checking after the merge keeps the team fast. No pull request waits for a product review, developers and assistants keep merging at full speed, and the product owner gets a short list of meaningful changes instead of a queue of everything.

Nobody reads every pull request

This is what makes the approach workable. A product manager cannot read every pull request, and should not have to. The point is not to add a second reviewer to every change. It is to make the system do the reading, and to bring a person in only when a decision is needed.

SpecTrail judges each pull request on one question: does it change what the product does? When the answer is no, nobody is asked, however large the change is and whoever or whatever wrote it. When the answer is yes, the change is meaningful, and only then does it reach a person. The product owner spends attention on the few changes that alter behaviour and none on the rest.

The approach needs one thing most teams do not have: a specification that is current and written in the product’s own words. A document written once and then left alone cannot do the job, so it has to be derived from the code and kept up to date as the code changes.

How SpecTrail does it

SpecTrail reads your repository and writes the specification as user stories with acceptance criteria, grouped by epic and feature. Every statement carries small marks for the code and the tests behind it, so the document is something you can check, not just read.

Each merged pull request is then compared with that specification, by meaning and not by lines. A pull request that changes nothing the customer would notice stays silent. A change that alters what the product does becomes one card that shows the pull request, an assessment of how the behaviour differs, and the history of the requirement. The product owner accepts the change, rewords it or denies it, and the decision is recorded with who made it and when.

The person deciding no longer has to read the diff to know whether the product changed. They read one sentence, and decide.

Related: where a living specification earns its keep · watch a change get caught · how a small startup keeps track of its product · what a SpecTrail flag looks like