Why AI-Generated Code Needs a Quality Check, Not Just a Security Scan

Quick answer: an AI coding assistant is very good at making the specific thing you just asked for work. It has no reliable way to notice that the validation logic it just wrote already exists, slightly differently, in three other files, or that the function it just extended now has six responsibilities instead of one. None of that is a security vulnerability on its own. All of it is exactly where the next one hides, because duplicated, oversized, or dead code is harder for a human reviewer to actually read, and a bug nobody can see clearly is a bug nobody catches.

Security scanning and code quality checking answer different questions. One looks for a specific dangerous pattern in a specific line. The other looks at the shape of the codebase itself, and the shape is what determines whether the next real bug gets caught in review or ships quietly.

Duplication: the same logic written five times, five different ways

Ask an AI coding assistant to add email validation to a new signup form, and it will write email validation. Ask it again for a different form three weeks later, in a different session with no memory of the first one, and it will write email validation again, similar but not identical, maybe missing an edge case the first version handled.

This is the default outcome of how these tools work, not a mistake in any single response. Each generation is a fresh pass focused on making the current request work, without a reliable way to search the rest of the codebase for something that already does the same job. The result is a codebase with the same logic implemented multiple times, each copy drifting slightly from the others.

The real cost shows up later. When one of those five near-identical validation functions gets a genuine security fix, an injection check, a length limit that prevents a denial-of-service pattern, the other four don't get it, because nobody remembered they existed, let alone that they needed the same fix.

Complexity: the function that keeps growing

A function that started simple accumulates one more condition, one more edge case, one more integration, across a dozen prompts asking for "just one more thing." Nobody sat down and designed a function with six responsibilities. It arrived at six responsibilities one small addition at a time, and each addition looked reasonable in isolation.

This matters for security specifically because authorization bugs hide in exactly this kind of function. A permission check sitting on its own line, in a function that does one thing, is easy to spot missing. The same check, buried in the fourth branch of a function that also handles data formatting, logging, and three other conditions, is easy to miss, both when it's absent and when a later edit accidentally routes around it.

Dead code: the path that outlived the feature

An AI-assisted rewrite replaces an old authentication flow with a new one. The new flow works, gets tested, ships. The old flow's code, and sometimes the old endpoint it lived behind, doesn't always get removed in the same pass, because removing code that "might still be used somewhere" feels riskier than leaving it.

The problem is that dead code isn't always actually dead from an attacker's point of view. An old API route that the frontend no longer calls can still be reachable if it was never actually deleted from the server, just unlinked from the UI. A disabled feature flag can still gate code that runs the moment someone flips it, intentionally or by a bug. Code that nobody uses on purpose is still code that runs if someone finds a way to reach it.

Lint violations: the small inconsistencies that add up

A single unused import or an inconsistent naming pattern isn't a security problem. A codebase where that's true throughout, where every file looks like it was written by a slightly different author with slightly different conventions, is a codebase where a human reviewer's eyes slide over things faster, because nothing about the formatting signals "this part is different, look closer here."

Lint rules exist to keep code looking consistent enough that an actual anomaly, a variable that shouldn't be there, a comparison that looks subtly wrong, still stands out instead of blending into general inconsistency.

Why this is a security conversation, not just a style one

None of these four patterns, duplication, complexity, dead code, lint violations, are vulnerabilities by themselves. What they share is a common effect: they make a codebase harder for a human to actually read and reason about, and code review is one of the few places a real logic or authorization bug gets caught before it ships. A codebase that's hard to read is a codebase where review quietly gets weaker, not because anyone stopped trying, but because there's more to look at and less signal about where to look.

This is a structural risk specific to how AI-assisted development tends to work. Fast iteration produces working features quickly, and "working" gets confirmed and moved past long before anyone asks whether this is the third version of the same logic, or whether the function doing the checking has grown past the point where a reviewer can hold the whole thing in their head at once.

What actually gets checked

A code quality scan looks at the source directly, across four categories: complexity (functions and files that have grown past a reasonable size or branching depth), duplication (near-identical logic repeated across the codebase instead of shared), dead code (unreferenced functions, unreachable branches, and unused exports), and lint violations (style and consistency rules the codebase has already agreed to but individual files have drifted from).

None of these findings are severity-ranked the way a security vulnerability is. They're maintainability signals, each one pointing at a specific place where the codebase has gotten harder to review than it needs to be, and where the next real bug is statistically more likely to be sitting unnoticed.

Final Thoughts

A security scan finds the dangerous pattern that's already there. A code quality check finds the conditions that make the next dangerous pattern harder to spot. Both matter, and they're not solving the same problem, one is about what's already wrong, the other is about how much harder the codebase has become to look at closely.

Treating "the tests pass" as the finish line skips the question that actually determines what happens next time: can someone look at this code and actually understand what it's doing well enough to know if it's safe.