Detecting Code Smells with AI

🔄 Quick Recall: In the previous lesson, you built review checklists for bugs, security, and performance. Now you’ll learn to detect code smells — the patterns that don’t cause immediate bugs but indicate deeper design problems that make code harder to maintain, test, and extend.

Code smells are warning signs, not errors. A 200-line function works today. Duplicate code works today. A class with 30 methods works today. But each smell makes future changes more expensive, bugs harder to find, and the codebase harder for new developers to understand. AI detects smells at scale — across hundreds of files simultaneously — and suggests specific refactoring for each one.

Function-Level Smells

AI prompt for function analysis:

Analyze these functions for code smells. Code: [PASTE CODE OR FILE]. Check for: (1) Long functions — functions over 30 lines that likely have multiple responsibilities, (2) Deep nesting — more than 3 levels of if/else/for/while indicating complex logic that should be simplified, (3) Long parameter lists — functions with more than 3-4 parameters, especially boolean flags, (4) Feature envy — functions that access data from another class more than their own, (5) Side effects — functions that modify state beyond their declared purpose, (6) God functions — functions that are called from many places and do many things. For each smell: identify the specific lines, explain why it’s a problem, rate the severity (high/medium/low), and suggest the refactoring pattern to fix it.

Function smell severity guide:

Class and Module-Level Smells

AI prompt for class analysis:

Analyze this class/module for design smells. Code: [PASTE CODE]. Check for: (1) God class — class with too many methods or too many responsibilities, (2) Data clumps — groups of variables that always appear together (should be their own object), (3) Primitive obsession — using strings/ints where a custom type would be clearer (e.g., ‘status’ as string instead of enum), (4) Divergent change — one class that changes for many different reasons, (5) Shotgun surgery — one change that requires modifying many classes, (6) Refused bequest — subclass that doesn’t use most of its parent’s methods, (7) Inappropriate intimacy — classes that access each other’s private/internal details. For each smell: the specific class/method affected, why it’s a problem for maintainability, and the recommended refactoring.

✅ Quick Check: You have a User class with methods: getName(), getEmail(), validatePassword(), sendEmail(), generateInvoice(), updateSubscription(), logActivity(), exportToCSV(). What’s the smell? (Answer: God class — User has at least 4 responsibilities: user data, email, billing, and reporting. Each should be a separate class: UserProfile, EmailService, BillingService, UserExporter. The test: “If I change how invoices are generated, should I need to modify the User class?” If the answer is no, that logic doesn’t belong in User.)

Codebase-Level Smells

AI prompt for codebase analysis:

Analyze my codebase structure for architectural smells. File structure: [DESCRIBE OR PASTE DIRECTORY TREE]. Check for: (1) Circular dependencies — modules that depend on each other, (2) Feature scattering — one feature’s code spread across many unrelated directories, (3) Layer violations — business logic in controllers, database queries in UI code, (4) Inconsistent patterns — different parts of the codebase solving the same problem differently, (5) Missing abstraction — the same concept represented differently in different places (e.g., ‘user’ defined in 3 different ways). For each smell: which files/modules are affected, the impact on maintainability, and the refactoring approach.

AI Smell Detection at Scale

AI prompt for full codebase scan:

Scan this codebase for the most impactful code smells. Files: [LIST OR DESCRIBE]. Prioritize by: (1) Impact — how much does this smell cost in maintenance, bugs, and developer time? (2) Frequency — is this a one-off or a pattern repeated across the codebase? (3) Fix difficulty — is this a 10-minute rename or a multi-week architecture change? Generate a prioritized list: top 10 smells sorted by (impact × frequency) / fix difficulty. For each: the smell, the files affected, the estimated cost of fixing, and the estimated cost of NOT fixing (continued maintenance burden).

Key Takeaways

• Long functions with multiple responsibilities are the most common and costly code smell — a 180-line function that does 6 things has 6 reasons to change and every change risks breaking the other 5. AI detects multi-responsibility functions and suggests extraction points
• Duplicate code with “slight variations” is the most dangerous form of duplication because the differences may be intentional or accidental — AI finds all instances and diffs them to show exactly what varies, helping you decide whether to unify or keep separate
• Boolean parameters create hidden execution paths: 3 boolean flags = 8 possible paths, most of which are probably untested. AI detects long parameter lists and suggests refactoring to separate functions, configuration objects, or type-based splitting
• Code smells should be prioritized by (impact × frequency) / fix difficulty — a smell that appears in 50 files and takes 10 minutes each to fix has higher total ROI than a complex architectural smell in one file
• Codebase-level smells (circular dependencies, layer violations, inconsistent patterns) are the hardest to detect manually but have the highest long-term cost — AI scans the entire codebase structure to find patterns humans miss

Up Next

In the next lesson, you’ll learn systematic refactoring patterns — the specific transformations that fix code smells while preserving external behavior.