# When AI Reviewers Find More Bugs Than Maintainers Can Fix > Source: > Published: 2026-10-18 09:38:35+00:00 For most of the history of software quality, finding bugs was the expensive part. You wrote tests, you ran fuzzers, you paid a security firm, you waited for a user to file a weird crash report. Fixing was comparatively cheap: once a defect is isolated with a reproduction, a competent maintainer can usually reason about it and write a patch. AI-assisted review breaks that assumption. A language model reading a diff, or an agent that can execute code and mutate inputs, can generate candidate defects far faster than a human reviewer can evaluate them. The output is not a finished bug report. It is a claim: *this code may be wrong, for this reason, under these conditions.* Some fraction of those claims are correct and important. Some fraction are correct but already known. Some fraction are technically true but irrelevant. And some fraction are confidently wrong. The Postgres 19 release slipping because AI reviewers surfaced more issues than the project could work through is the visible version of a dynamic that is quietly arriving in every large codebase. The headline sounds like a success story for AI. It is closer to a queueing problem. To see why, it helps to be precise about the mechanism. There are two distinct techniques getting lumped together. The first is **static review by a language model**. You feed a diff plus surrounding context and ask for defects. This scales trivially — you can run it on every commit, with several models, at several temperatures, and get several different answers. Recall goes up. So does noise. These systems cannot run the test suite, cannot check whether a code path is reachable in production, and cannot know that the project deliberately made a tradeoff four years ago. They are pattern matchers over text that resembles buggy code. The second is **agentic or fuzzing-based discovery**, where the model writes inputs, runs the program, observes crashes or assertion failures, and iterates. This is slower and more expensive per finding, but the findings tend to be reproducible, because the agent had to actually trigger the failure to report it. The first technique is what generates the flood. And a flood of unreproduced claims is the worst possible input to a review process, because evaluating a claim costs almost as much as fixing the bug if the claim is real. A bug report is a unit of work, and its cost is dominated by triage. The properties that make one cheap to process: Most AI review output has none of these by default. It arrives as prose. Someone has to turn prose into a ticket, and that someone is a maintainer who would rather be writing code. If you are running AI review on your own repository, the design decisions that matter are mostly about queue management, not model quality. Run review in a branch or a shadow pipeline and **do not auto-file issues**. Auto-filing converts model output directly into human obligation, which is how you burn out a team. Cluster before you surface. Embed the findings, dedupe by similarity, and rank by a signal you trust — reachability, whether the flagged line changed recently, whether the file has a history of defects. A ranked list of twenty beats an unranked list of two hundred. Prefer the expensive agent that reproduces over the cheap one that speculates, at least for anything you intend to act on. A finding with a failing test attached is worth an order of magnitude more than a finding with a paragraph attached. Budget for remediation, not detection. Detection is now nearly free and getting cheaper. The line item that grows is engineer hours spent reading, reproducing, and patching — plus the regression risk of landing a large batch of fixes under time pressure, which is its own kind of hazard in a project with a long backpatch history. Who is accountable for a defect that a model reported, a human deprioritized, and an attacker later exploited? Disclosure norms assume a reporter and a maintainer. Adding a third party that can generate findings at arbitrary volume, with no stake in the project, has no precedent. Can the same tooling that finds bugs help fix them? Early experience suggests models are better at locating a defect than at producing a patch that respects a codebase's conventions and does not introduce a subtler problem. Reviewing a generated patch is cheaper than writing one, but not free. And the calibration question: how do you know your reviewer's precision? Without a labeled set of known-real and known-false findings from your own repository, you cannot set a threshold, and you will either drown in noise or ignore real defects. Building that set is unglamorous work, and it is probably the highest-leverage thing a team adopting AI review can do first.