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.
Why AI-generated code needs a different filter
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.
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.
What pre-screening AI-generated code actually needs to catch
Hallucinated dependencies and APIs
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.
Context loss across a large diff
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.
Plausible-but-wrong logic
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.
Pattern drift from what already works
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.
Pre-screening is not the same job as code review
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.
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.
What good pre-screening looks like in practice
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.
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 are opening a small design partner cohort. Book a call →