Identifying and Fixing Code Smells: The Ten Most Common in AI Code

A code smell is a spot in the source code that works and still points to a deeper problem. The term comes from Kent Beck and Martin Fowler. In AI-generated code, certain smells show up disproportionately often because the model sees the excerpt it is supposed to change, not the existing codebase it is writing into.

What is a code smell?

A code smell is a suspicion, not a defect. The code runs, the tests are green, and yet the structure suggests that the next change in this spot will be unpleasant.

The distinction matters: a smell is not a rule violation that gets fixed automatically. Some smells are correct right where they are, deliberate duplication between two modules meant to evolve independently, for instance. A tool can flag the suspicion; whether it holds is for whoever understands the context to decide.

Which code smells show up most often in AI-generated code?

Ten patterns, ordered by how expensive they become later.

• Duplicated logic. The same behavior in several places. By far the most common and most expensive smell, and the only one whose growth can be measured over years, see technical debt from AI code.
• Parallel implementation. A new helper function next to an existing one that does the same thing, because the model did not know the existing one was there.
• Overly long function. Generated code tends to write the entire flow into a single function, because that is how it was described in the prompt.
• Swallowed error. An empty catch block, or a default value that makes a failure look like a success. Its own OWASP category since 2025 (A10).
• Magic values. Numbers and strings written directly into the code, whose meaning only becomes clear from context.
• Speculative generalization. A configuration switch, an interface, an abstraction layer for a case that does not exist. Models like to build "for later."
• Comment instead of clarity. A comment that describes what the next line does. It does not replace an understandable name and becomes wrong the next time the code changes.
• Data clump. The same five parameters travel through six functions instead of being bundled into a single object.
• Unused leftovers. Imports, variables, functions from a discarded intermediate state.
• Test without an assertion. A test that runs code and checks nothing. Produces coverage and no safety, see measuring code quality.

How do I find code smells in my project?

A tool finds six of the ten patterns above, for the remaining four you need a human. The distinction pays off because it saves review time.

• Machine-findable: duplicates, overly long functions, swallowed errors, magic values, unused leftovers, tests without an assertion. Handled by static code analysis.
• Only human-findable: parallel implementation (requires knowledge of the existing codebase), speculative generalization (requires knowledge of the requirements), comment instead of clarity, data clumps.

Exactly the four human ones are the ones that increase with AI code, and the ones hardest to see in a diff, because the counterpart sits in a different file.

How do I fix a code smell without breaking anything?

In four steps, and the first one is the one most often skipped.

• Secure it first. Before you restructure a spot, a test has to exist that captures the current behavior. Without that test, every restructuring is a gamble.
• One thing per step. Merging a duplicate and splitting a function and renaming something at the same time produces a diff nobody can review.
• Leave behavior unchanged. A refactoring that fixes a bug along the way is no longer a refactoring. Bug fixing is its own commit.
• Check after every step. Test run green, then the next step.

What that looks like in practice for generated code is described in the article refactoring AI-generated code.

Is it worth fixing every smell?

No, and that is the most important sentence on this topic. A smell in code that never gets touched again costs nothing. The effort to fix it always costs something.

Sensible prioritization combines two figures that can both be read from the repository: how often was this file changed in recent months, and how complex is it? Whatever lands in the top right, changed often and complex, deserves attention. The rest is allowed to smell.

Frequently asked questions about code smells

Is a code smell the same as a bug?

No. A bug is incorrect behavior. A smell is correct behavior inside a structure that makes future changes harder. A smell can go without consequences for years.

Does an AI reliably recognize code smells?

For the machine-findable patterns, yes, often better than a rule engine, because it reads the context along with the code. For parallel implementations it is unreliable, because it lacks exactly the overview that makes the smell visible in the first place, unless the tool actively searches the existing codebase before it writes.

How many lines is a function allowed to have?

There is no standardized limit, and any number you hear quoted is a convention. A more solid question is whether the function can be described in one sentence without an "and." If the description needs an "and," it is doing two things.

Should I fix smells before building a feature?

Only where the feature is being built in. Cleaning up around your own change is cheap and gets reviewed anyway, because it is already part of the review. A blanket cleanup as its own project rarely finds a sponsor.

The four smells no tool finds all arise in the same place: where nobody checked what already exists. Code Guardian asks exactly this question before the first line is written: which function, which helper, which query already exists?

Sources

• Martin Fowler, Refactoring (coining and cataloging of code smells, together with Kent Beck).
• GitClear, The Maintainability Gap: 2026 AI Code Quality Research (copy/paste share).
• OWASP Top 10:2025, category A10 "Mishandling of Exceptional Conditions".

As of July 27, 2026. General professional context.