{"slug": "ai-generated-code-needs-a-different-kind-of-pre-screening", "title": "AI-Generated Code Needs a Different Kind of Pre-Screening", "summary": "A growing share of pull request code is now AI-generated, and it fails differently from human-written code — confidently, syntactically clean, and often plausible-looking even when wrong. GitClear's analysis of over 200 million changed lines found duplicated code blocks becoming far more common as AI authorship scaled, a pattern human reviewers skimming large diffs tend to miss. The piece argues that pre-screening AI-generated code before it reaches a reviewer has become a distinct tooling category, since code review built for human failure modes checks for the wrong things.", "body_md": "Code review was built around an assumption: a human wrote this, and another human is checking it.\n\nThat assumption is breaking down fast.\n\nA 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.\n\nPre-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.\n\nThat'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.\n\nHuman-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.\n\nAI-generated code fails differently.\n\nIt's confident, syntactically clean, and often plausible-looking even when it's wrong.\n\nIt 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.\n\nNone of that looks like a \"tired engineer\" bug.\n\nIt looks like normal code, right up until it isn't.\n\nGitClear'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.\n\nThe review process didn't change.\n\nThe thing it is reviewing did.\n\nReviewer intuition is calibrated to the left-hand panel, and the volume is arriving from the right.\n\nThat'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.\n\nAn 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.\n\nIt reads fine.\n\nIt doesn't run.\n\nA 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.\n\nAI-generated code is good within a narrow window, and weaker on context awareness across a bigger change.\n\nIt 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.\n\nA 1,000-line PR makes this easy to miss, right when a human reviewer has the least time to catch it.\n\nThe hardest category.\n\nCode that runs, passes the obvious test cases, and is still wrong for a case nobody thought to write a test for.\n\nStatic analysis catches syntax problems. It doesn't catch a model's confident misunderstanding of what the ticket actually asked for.\n\nIf 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.\n\nPre-screening that checks new code against existing patterns catches drift before it becomes the third inconsistent way of doing the same thing.\n\nIt's the kind of problem worth discussing in the open rather than solving quietly in isolation, since most teams are hitting the same drift.\n\nThis distinction matters more than it sounds like it should.\n\nCode review asks:\n\nIs this the right approach, does it fit the design, should we ship it?\n\nPre-screening asks a narrower question first:\n\nIs there anything here a reviewer needs to know before they spend their attention on it?\n\nTwo questions, asked in order.\n\nThe narrow mechanical one is answerable automatically.\n\nThe wide one is the only part that actually needs a human.\n\nCollapsing the two into one step is how review queues get backed up.\n\nA 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.\n\nSeparating them means the mechanical stuff gets caught automatically, and the human time goes to the part that actually needs a human.\n\nIt 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.\n\nIt's specific about what it found and why, not a wall of generic linting output.\n\nA 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.\n\nGood pre-screening gets faster and more accurate over time as it learns which patterns actually cause problems in a given codebase.\n\nThat's the opposite of applying the same generic ruleset to every team regardless of what their incident history actually looks like.\n\nTeams that get this right aren't reviewing less.\n\nThey are reviewing unevenly, on purpose.\n\nThe 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.\n\nPre-screening is the prevention half of the story.\n\nFor what happens after something still slips through, see [why automated root cause analysis needs to look past MTTR](https://tomosu.ai/blogs/automated-root-cause-analysis-beyond-mttr.html).\n\nTomosu pre-screens AI-generated changes at the merge gate, checking them against how your codebase actually works and what has actually broken it before.\n\nIf review capacity is the bottleneck on your AI-assisted development, we're opening a small design partner cohort.", "url": "https://wpnews.pro/news/ai-generated-code-needs-a-different-kind-of-pre-screening", "canonical_source": "https://dev.to/parsa4873fe3aa/ai-generated-code-needs-a-different-kind-of-pre-screening-3908", "published_at": "2026-09-15 08:54:27+00:00", "updated_at": "2026-09-15 09:09:16.759100+00:00", "lang": "en", "topics": ["ai-tools", "developer-tools", "ai-products", "generative-ai"], "entities": ["GitClear"], "alternates": {"html": "https://wpnews.pro/news/ai-generated-code-needs-a-different-kind-of-pre-screening", "markdown": "https://wpnews.pro/news/ai-generated-code-needs-a-different-kind-of-pre-screening.md", "text": "https://wpnews.pro/news/ai-generated-code-needs-a-different-kind-of-pre-screening.txt", "jsonld": "https://wpnews.pro/news/ai-generated-code-needs-a-different-kind-of-pre-screening.jsonld"}}