Code review was built around an assumption: a human wrote this, and another human is checking it.
That assumption is breaking down fast.
A growing share of the code hitting pull requests now comes from AI coding assistants, and it doesn't fail the way human-written code fails. Code reviews built for one failure mode don't automatically catch the other.
Pre-screening AI-generated code before it reaches a reviewer isn't optional anymore. It's the only way review capacity keeps up with how fast the code is arriving.
That's also why AI-generated code pre-screening tools have become a distinct category rather than a feature bolted onto existing review tools. The job is different enough to need its own approach.
Human-written bugs tend to cluster around effort and attention: a tired engineer skips an edge case, a rushed PR misses a null check. Reviewers have decades of intuition for spotting that pattern.
AI-generated code fails differently.
It's confident, syntactically clean, and often plausible-looking even when it's wrong.
It can invent a function that doesn't exist, misunderstand the intent behind a ticket, or quietly reproduce an anti-pattern from its training data that happens to compile fine.
None of that looks like a "tired engineer" bug.
It looks like normal code, right up until it isn't.
GitClear's analysis of over 200 million changed lines of code found duplicated code blocks becoming far more common as AI authorship scaled, exactly the kind of pattern a human reviewer skimming a large diff is likely to miss.
The review process didn't change.
The thing it is reviewing did.
Reviewer intuition is calibrated to the left-hand panel, and the volume is arriving from the right.
That's the real argument for pre-screening: the failure mode changed, so the review process built for the old failure mode is checking for the wrong things.
An AI assistant will sometimes call a method that doesn't exist on the object it's using, or import a package that isn't in the project.
It reads fine.
It doesn't run.
A screening pass that just checks style and formatting won't catch this. It needs to actually resolve what the code is calling against what's real.
AI-generated code is good within a narrow window, and weaker on context awareness across a bigger change.
It can lose the thread: two functions in the same PR handling the same edge case two different ways, or a rewritten function that no longer matches an invariant the rest of the codebase depends on.
A 1,000-line PR makes this easy to miss, right when a human reviewer has the least time to catch it.
The hardest category.
Code that runs, passes the obvious test cases, and is still wrong for a case nobody thought to write a test for.
Static analysis catches syntax problems. It doesn't catch a model's confident misunderstanding of what the ticket actually asked for.
If the codebase has an established way of handling retries, auth checks, or error propagation, AI-generated code doesn't reliably know that unless it's told.
Pre-screening that checks new code against existing patterns catches drift before it becomes the third inconsistent way of doing the same thing.
It's the kind of problem worth discussing in the open rather than solving quietly in isolation, since most teams are hitting the same drift.
This distinction matters more than it sounds like it should.
Code review asks:
Is this the right approach, does it fit the design, should we ship it?
Pre-screening asks a narrower question first:
Is there anything here a reviewer needs to know before they spend their attention on it?
Two questions, asked in order.
The narrow mechanical one is answerable automatically.
The wide one is the only part that actually needs a human.
Collapsing the two into one step is how review queues get backed up.
A reviewer opening a 1,000-line AI-generated PR with no pre-screening has to do both jobs at once. The narrower mechanical checks eat the time that should go to the judgment call.
Separating them means the mechanical stuff gets caught automatically, and the human time goes to the part that actually needs a human.
It runs before a human ever opens the PR, as part of the CI/CD pipeline rather than a parallel check they have to remember to read.
It's specific about what it found and why, not a wall of generic linting output.
A screening tool that buries real issues under a pile of false positives gets ignored within a few weeks; teams learn to click through it the same way they learn to ignore a smoke alarm that goes off every time someone makes toast.
Good pre-screening gets faster and more accurate over time as it learns which patterns actually cause problems in a given codebase.
That's the opposite of applying the same generic ruleset to every team regardless of what their incident history actually looks like.
Teams that get this right aren't reviewing less.
They are reviewing unevenly, on purpose.
The teams that get this right aren't reviewing less. They're spending their review time on the 10% of changes that actually need a human's judgment, instead of splitting attention evenly across all of it.
Pre-screening is the prevention half of the story.
For what happens after something still slips through, see why automated root cause analysis needs to look past MTTR. Tomosu pre-screens AI-generated changes at the merge gate, checking them against how your codebase actually works and what has actually broken it before.
If review capacity is the bottleneck on your AI-assisted development, we're opening a small design partner cohort.