The bottleneck moved from finding defects to closing them
For most of the history of software engineering, the hard part of quality assurance has been discovery. Static analyzers, fuzzers, and human reviewers all share a common failure mode: they miss things. Teams invested enormous effort in raising recall — more coverage, more instrumentation, more reviewers — because a bug you never find is a bug you never fix.
The PostgreSQL 19 release cycle reportedly slipped for the opposite reason. AI-assisted review surfaced more candidate defects than the maintainers could triage and fix inside the release window. That inverts the usual assumption. It also generalizes: any project that wires a high-recall machine reviewer into a process whose throughput is set by human triage will eventually hit the same wall.
A review pipeline is a queue, and the queue is the release gate
Model the review process as a queueing system. Candidate defects arrive at some rate. Each one costs a human some amount of time to triage, and the real ones cost additional time to fix and verify. If the arrival rate exceeds the service rate, the backlog grows without bound.
What makes this sharp in practice is that release criteria are usually defined over the queue, not over the arrival rate. "No known release-blocking defects" is a statement about the state of the backlog. So a tool that doubles discovery without changing triage or fix capacity does not make the software better faster. It makes the release later, because the gate cannot close until the queue drains.
This is a throughput mismatch, not a tooling failure. The tool is doing what it was asked to do. The process around it was sized for a world where discovery was the constraint.
Why machine review inflates the queue faster than it drains it
Several mechanisms compound.
- Generation is cheap; falsification is expensive. A model can emit a plausible-sounding defect report in milliseconds. Deciding whether it is real requires reading surrounding code, understanding intent, building or reproducing, and often asking the original author. The cost asymmetry is several orders of magnitude.
- Reviewers are tuned for recall, and recall buys precision loss. Any detector optimized not to miss things will produce a long tail of low-confidence findings. Each one still costs a human minutes to dismiss, and dismissal is invisible work that produces no artifact.
- Duplicates multiply. Multiple detectors, multiple prompts, multiple runs on the same diff will surface the same root cause repeatedly. Without clustering by root cause, N tools produce roughly N times the triage load for one bug.
- Findings without reproducers are not actionable. "This looks like a race" is a hypothesis. A failing input or a deterministic interleaving is a work item. The former consumes triage time; the latter consumes fix time. Conflating them hides where the capacity actually goes.
- Severity is uncalibrated. Models have no shared notion of what blocks a release. Without a severity gate, everything is nominally a candidate blocker, and the queue never has a floor.
- Some findings are not bugs. A reviewer can correctly identify that a code path is fragile, under-documented, or relies on an invariant nobody enforces. Those are real observations that cannot be resolved by a patch. They need a design decision, which is a different and much slower process.
The net effect: the queue grows in units of human attention, and human attention is the one input the tool cannot supply.
Designing the pipeline so the queue stays drainable
The goal is not to suppress findings. It is to convert findings into work at a rate the team can absorb, and to make the conversion itself cheap.
- Deduplicate by root cause, not by text similarity. Cluster findings that point at the same line, the same invariant, or the same failing input, and present one entry per cluster.
- Require evidence before human triage. A finding enters the human queue only with a reproducer, a failing test, or a concrete input. Everything else goes to a machine-triaged backlog.
- Rank by reachability and blast radius. A defect in a hot path that ships to users outranks a defect in a rarely exercised error branch, regardless of how confident the model is.
- Make the fix, not the finding, the unit of work. Auto-generated candidate patches are useful because they let a human verify rather than author. Verification is faster than construction, and it keeps accountability with the person who merges.
- Cap work in progress. An unbounded queue destroys prioritization. Explicit WIP limits force the team to decide what actually blocks the release.
- Measure precision per detector and turn off the noisy ones. If a detector's findings are dismissed more than some fraction of the time, it is consuming capacity, not adding safety.
Verification is the scarce resource, and that is the real story
The same pattern shows up wherever models generate artifacts faster than humans can check them: generated code, generated tests, generated pull requests. Generation has become abundant. Verification has not, and there is no obvious reason it will, because verification requires the very judgment that makes the work hard in the first place.
That reframes what these tools are for. A reviewer that finds more bugs is only useful if the pipeline can turn findings into merged fixes. Otherwise it is a machine for manufacturing guilt — a growing list of known problems that nobody has time to address.
The open questions are uncomfortable. Can models be calibrated to emit only high-precision findings, or is triage itself the thing to automate, with a second model filtering the first? Who owns a regression that an AI reviewer flagged and a human dismissed? Does a backlog of machine-found defects eventually get paid down, or does it become a permanent, growing liability that teams learn to ignore? And how do you measure any of this — findings per change, triage minutes per finding, precision at the release-blocking threshold — in a way that tells you whether the tool is actually helping?
The queue is the artifact. Everything else is upstream of it.
