The PR Queue Wasn’t Built for This Much Code

AI made writing code dramatically cheaper. Reviewing it did not get cheaper at the same rate.

An agent can open three pull requests while you are still trying to understand the first one. It can refactor a service, upgrade a dependency, add tests and fix a bug before someone on the team has decided whether any of those changes are actually worth shipping.

For years, opening a pull request carried some natural friction. A developer had to understand the problem, write the code, test it and decide it was ready enough to ask someone else to spend time reviewing it. Agents remove a lot of that filter. Trying something is cheap now. Opening a PR for it is cheap. Rewriting it is cheap. The expensive part starts after that, when someone still has to understand what changed, what it touches, whether the tests prove anything useful and whether it should reach production.

That is the problem we built Autter Triage around.

A list of pull requests is not enough anymore

Most PR queues are really just lists. You get an author, reviewers, labels, checks and a timestamp. That works until the amount of code entering the queue starts growing faster than the team can inspect it.

Imagine opening GitHub in the morning to fifteen PRs. One changes copy. One upgrades an internal package. Three are small fixes created overnight by an agent. One changes authentication. Another touches a payment retry path. Two are part of the same stack, and another has been sitting there for three days because the reviewer it actually needs was never assigned.

On the screen, they mostly look like equivalent rows.

But they clearly are not equivalent work.

A seven-line change to authentication may deserve far more scrutiny than a 700-line refactor in an isolated internal package. A dependency bump may look routine until you realise it affects a package sitting in the request path of three services. A PR near the bottom of the list may be the actual blocker for four other changes above it.

The questions engineers care about are not “Which PR is newest?” or “Which one has the most comments?” They are things like: Which change has the largest blast radius? Which one is missing meaningful tests? Which one is blocking other work? Which one needs someone who actually understands this part of the system?

Those are context problems, not sorting problems.

And this is where we think the shape of code review has to change.

Good review is expensive because judgment is expensive. Understanding whether a new abstraction belongs in the architecture takes time. Thinking through what happens when a payment provider times out takes time. Looking at a database migration and tracing what might break downstream takes time.

At the same time, not every PR deserves that level of attention.

If an agent changes a small utility, the affected behaviour is well tested, nothing sensitive is involved and the blast radius is tiny, spending thirty minutes of senior engineering time on it probably does not make sense. But teams often end up in one of two places: they inspect everything deeply and become the bottleneck, or the queue gets large enough that review quality starts collapsing.

The more useful question is not, “How do we review every PR faster?”

It is, “Which PRs actually deserve deep human attention?”

That became the foundation for Triage.

We wanted the queue to understand the change, not just show it

A diff tells you what changed. It does not necessarily tell you what that change means inside the system.

So when Autter looks at a pull request, we try to build a much broader picture around it. That can include dependencies, downstream blast radius, test evidence, security findings, ownership, relevant reviewers, related PRs, stacked dependencies and, where available, runtime and production signals.

The goal is not to attach another AI-generated risk score to the PR.

If Autter says something is risky, the engineer should be able to understand why. Maybe the change touches a payment fallback used by three services and there is no test covering the affected behaviour. Maybe a dependency update introduces a known vulnerability. Maybe the diff looks harmless, but it sits at the bottom of a stack and everything above it is waiting on this one change.

That is useful because it gives someone something to do.

“High risk” is not an action.

“Payment fallback changed, three downstream services affected, no test covers the failure path” is.

The same idea applies to stacked PRs. If PR C depends on PR B, which depends on PR A, and the real problem was introduced in PR A, we do not want someone spending time investigating the same symptom three times. The queue should understand the chain and surface where the problem actually started.

This matters more as agents do more of the implementation work. Engineering work starts looking less like isolated PRs and more like connected changes moving through a system.

Agents should remove work from the queue too

There is an easy trap with agentic development.

More coding agents create more code. More code creates more PRs. More PRs create more review work. So teams add reviewing agents, which produce more summaries and more comments for humans to process.

You can very quickly end up with more automation and somehow more work.

That is not what we want Triage to do.

If a test is missing, an agent may be able to prepare it. If a review finding has an obvious fix, an agent may be able to create the patch. If several PRs are blocked by one issue lower in a stack, Autter should point to the origin instead of asking a human to rediscover it several times.

Agents should not only add work to the queue. They should help clear it.

The human should appear when judgment is actually required.

There is another part of this we care about a lot: the queue should not forget everything after merge. Production is where a lot of the truth appears. A PR can pass review and still create an incident. A green test suite can still miss the path customers actually use. A supposedly low-risk part of the codebase can turn out to be operationally critical.

That evidence should come back.

If a certain part of the system caused an incident last week, the next PR touching it probably deserves more scrutiny. If a particular type of change repeatedly leads to rollbacks, that should eventually influence how similar changes are treated.

This is why we keep coming back to the idea that review, testing and production observability should not be completely separate systems. You review something, test it, ship it, observe what happens and carry that evidence into the next change.

The pull request is changing jobs

For a long time, the pull request was mostly a collaboration surface between developers. One person wrote some code, another person reviewed it, they discussed a few things and eventually merged it.

That model is already changing.

The author may now be an agent. The first reviewer may be an agent. Tests may have been generated by an agent. The fix for a failed build may also be generated by an agent. Several systems may have touched the change before a human ever sees it.

At that point, the pull request becomes something more important than a place to leave comments. It becomes a control point between software being generated and software reaching production.

And a flat list of open PRs is not enough for that.

The queue needs to understand which changes are consequential, which ones are blocked, what evidence exists, what is missing and who, or what, needs to act next.

That is what we want Autter Triage to become.

Not a prettier inbox. Not another AI summary beside a diff. A layer that helps engineering teams understand where their limited attention actually needs to go.

Because AI is making code abundant.

Confidence in what should ship is becoming scarce.