Module 5: Common Error Patterns

Module 5: Common Error Patterns in AI-Generated Code

Next →

Module 5: Common Error Patterns in AI-Generated Code

Capsule overview

In module 4 you learned to do a professional code review of AI output: you have a checklist, you know how to prioritize, and you can document findings. That's the process. Now you need the content: knowing exactly what to look for. Because there's a huge difference between "I review AI code looking for problems" and "I know that AI tends to generate functions with misleading names, ignores null/empty edge cases, and leaves SQL injection in concatenated queries."

This module trains your pattern recognition. The idea is that when you see code generated by Claude Code, certain patterns jump out automatically — like a doctor who sees symptoms and knows the diagnosis before ordering tests. Not because you memorize a list, but because you internalize the patterns AI consistently repeats.

LLMs have predictable tendencies. They make the same types of errors over and over. Knowing these tendencies is a superpower: instead of reviewing everything with the same depth, you know where to look first.

Module context

Where are we?

You're in Module 5 of the "Debugging & Code Review with Claude Code" guide, within Phase 2: Professional Code Review.

Phase 2: Professional Code Review
├── Module 4: Code Review of AI Output ← completed
│   └── Process, checklist, prioritization, documentation
│   └── Capsules: intro, what to look for, checklist, red flags, business logic, exercise
├── Module 5: Common Error Patterns ← you are here
│   └── The 3 types of error that represent 80% of bugs in AI code
│   └── Capsules: intro, naming, edge cases, security, exercise
└── Module 6: Debugging with Claude Code → next
    └── Diagnosis and resolution of errors using Claude Code as a tool

Module 4 gave you the how of doing a code review. This module gives you the what: the specific patterns you look for. Module 6 will give you the what to do when you find an error and need to diagnose it in depth.

The transition: from process to pattern recognition

In module 4, your checklist tells you:

☐ Verify naming and abstractions
☐ Review edge cases
☐ Look for security vulnerabilities
☐ Validate business logic
☐ Confirm error handling

But when you're in front of the code, questions arise that the checklist doesn't answer:

  • "What type of misleading naming does AI generate specifically?"
  • "Which edge cases does AI tend to ignore?"
  • "Which security vulnerabilities are the most frequent in AI code?"
  • "What does a design pattern misapplied by AI look like?"

This module answers those questions with concrete examples, real code, and patterns you can recognize visually.

The 3 Patterns That Represent 80% of Errors

Why only 3?

You might expect a list of 20 types of errors. But in practice, 3 categories cover the vast majority of problems in AI-generated code:

Distribution of errors in AI code (based on observed patterns):

1. Incorrect naming and abstractions     ─── ~30%
   └── Misleading names, unnecessary classes, misapplied patterns

2. Unhandled edge cases                  ─── ~35%
   └── Null, empty, limits, concurrency, unicode

3. Security holes                        ─── ~15%
   └── SQL injection, secrets, auth, XSS, CORS

4. Everything else                       ─── ~20%
   └── Business logic, hallucinations, performance

The first 3 add up to ~80%. Learning to recognize these 3 patterns gives you the greatest return on investment in your code review.

Why does AI make these specific errors?

Each type of error has a structural reason:

Incorrect naming and abstractions — AI optimizes for statistical patterns. It has seen millions of functions called get_user, process_data, handle_request. It replicates those names even when they aren't descriptive for your case. It applies the Factory pattern because it saw it in a lot of code, not because your situation requires it.

Unhandled edge cases — AI generates the "happy path" with high quality. Edge cases (null, empty, concurrency) require thinking about what can go wrong — something AI doesn't do proactively. It generates items[0] without considering that items could be empty.

Security holes — AI prioritizes functionality over security. It generates an endpoint that works, but without auth. It builds a query that returns data, but with string concatenation vulnerable to SQL injection. The functionality looks correct; the security is invisible until someone exploits it.

The doctor metaphor

Think of an experienced doctor. When a patient describes symptoms, the doctor doesn't consult a 500-page medical encyclopedia. They recognize patterns:

Symptoms: fever + sore throat + swollen glands
Probable diagnosis: throat infection
→ They don't need to consider the 10,000 possible diseases

Symptoms in AI code:
a function called get_user that does 3 different things
→ Diagnosis: incorrect naming + single responsibility violation
→ You don't need to review the entire taxonomy of code smells

Your goal is to develop that same intuition for AI-generated code. When you see certain "symptoms" in the code, your diagnosis is almost automatic.

Module progression

Module map

CapsuleTopicWhat you'll learnType
02Incorrect Naming and AbstractionsMisleading names, premature abstractions, misapplied patternsTechnique
03Unhandled Edge CasesNull, empty, boundary, concurrency, unicodeTechnique
04Typical Security HolesSQL injection, secrets, auth, XSS, CORS, rate limitingTechnique
05Exercise: Identify PatternsFastAPI code with 5 embedded errors — identify and fixExercise

Learning flow

You start with naming and abstractions (capsule 02) because they're the most frequent and most subtle errors — code that "works" but is a time bomb for maintenance. Then you tackle edge cases (capsule 03), which are the errors that cause crashes in production with unexpected inputs. Then security holes (capsule 04), which are the errors with the greatest potential impact. Finally, the integrative exercise (capsule 05) makes you apply it all in a realistic FastAPI codebase.

The progression is: subtle errors → runtime errors → security errors → apply it all together.

Dependencies between capsules

Capsule 02 (Naming) ──────────┐
                                ├── Capsule 05 (Exercise)
Capsule 03 (Edge Cases) ──────├── The exercise contains
                                │   the 3 types of error
Capsule 04 (Security) ────────┘

Capsules 02, 03, and 04 are independent of each other — you can read them in any order. But capsule 05 requires having completed all three, because the exercise contains errors from all three categories.

Professional objective

By the end of this module you'll be able to:

  • ✅ Recognize misleading naming in AI-generated functions: names that promise one thing and do another
  • ✅ Detect incorrect abstractions: Factory where if/else would have sufficed, unnecessary deep inheritance
  • ✅ Identify unhandled edge cases: null, empty, off-by-one, division by zero, concurrency
  • ✅ Find common security holes: SQL injection, hardcoded secrets, endpoints without auth, XSS
  • ✅ Fix each pattern with justification for why the fix is correct
  • ✅ Explain why AI generates each type of error (understand the cause, not just the symptom)

Connection to the Project

How it connects to the capstone project (Module 8)

The codebase of the capstone project intentionally contains all 3 types of error patterns. The fixes you practice in this module are exactly what you'll do in the project:

Capstone project (Module 8):
├── 3-4 naming and abstraction errors
│   └── Functions with misleading names
│   └── Misapplied design patterns
├── 3-4 unhandled edge cases
│   └── Missing null handling
│   └── Empty arrays that cause crashes
│   └── Off-by-one in pagination
├── 3-4 security holes
│   └── SQL injection
│   └── Hardcoded secret
│   └── Endpoint without auth
└── ... other types of errors

If you master this module, you can find 10-12 of the project's 15-20 problems with pattern recognition alone — before even running the code.

This module's exercise

The exercise in capsule 05 is a concentrated version of the capstone project: a FastAPI application of ~150 lines with 5 embedded error patterns. It's your dress rehearsal for module 8.

Limits: What this module does NOT cover

  • ❌ Hallucinations — Fake imports, invented APIs. That was module 3. Here the errors are in real code, not invented.
  • ❌ Debugging — Diagnosing and fixing errors at runtime. That's module 6. Here you identify patterns, you don't debug.
  • ❌ Code review process — That was module 4. Here you assume you already have a process and enrich it with content.
  • ❌ Every possible error — We don't cover performance, memory leaks, or advanced concurrency errors. We cover the most frequent 80%.

How to Use This Module

Recommended approach

For each error pattern (capsules 02-04):

1. Read the vulnerable code AI generates
   → "Would you have accepted it at first glance?"

2. Understand why it looks correct
   → "What tricks you?"

3. See how it's exploited or fails
   → "What's the real impact?"

4. Study the fix
   → "Why is this version better?"

5. Practice with the exercises
   → "Can you detect the pattern without help?"

The 4 components of each pattern

Each error example in capsules 02-04 follows the same 4-component structure. This structure isn't arbitrary — it's the one that trains effective pattern recognition:

Component A: The code AI generates
├── Complete code with imports
├── Works correctly with happy-path inputs
└── Looks professional and clean

Component B: Why it looks good at first glance
├── What "correct code" signals it has
├── Why a superficial code review would accept it
└── What tricks you visually

Component C: How it breaks or is exploited
├── The specific input that causes the problem
├── The production scenario where it fails
├── The real impact (crash, data leak, breach)
└── This is what anchors the pattern in your memory

Component D: The correct fix
├── Complete code with the fix
├── Justification for why it's better
├── Which principle applies (defense in depth, least privilege, etc.)
└── This gives you the tool to act

Without component B, you don't understand why the error slips through. Without C, you don't feel the urgency. Without D, you can't do anything about it. The 4 together create the complete pattern.

The recognition cycle

After studying the examples in each capsule, your brain starts to create shortcuts:

Cycle 1 (conscious — first reviews):
"I see an f-string in SQL... wait, wasn't that SQL injection?
Yes, capsule 04 covered it. I need parameterized queries."
→ 30 seconds of conscious analysis

Cycle 10 (semi-automatic — after practice):
"f-string in SQL → parameterize"
→ 5 seconds, the pattern jumps out

Cycle 50+ (automatic — pattern recognition):
*Sees f-string in query* → *immediate warning signal*
→ < 1 second, no conscious effort

The module takes you from cycle 1 to cycle 10. Daily practice takes you from 10 to 50.

What makes this module different

This module isn't a list of "10 common errors in Python." It's a pattern-recognition training specific to AI-generated code. The difference:

Generic error list:
├── "Don't use eval()"
├── "Always validate input"
├── "Don't hardcode secrets"
└── You know WHAT to avoid, but not WHAT TO LOOK FOR in AI code

Pattern recognition for AI code:
├── "AI generates get_user() that also modifies state"
│   → You know to look for functions with simple names that do several things
├── "AI generates items[0] without checking whether items is empty"
│   → You know to look for direct index accesses without guards
├── "AI concatenates strings in SQL queries"
│   → You know to look for f-strings or + inside queries
└── You know WHAT TO LOOK FOR because you know AI's tendencies

Relationship Between the 3 Patterns

The 3 patterns aren't isolated categories — sometimes they cross and reinforce each other:

Naming + Security:
A function called get_user() that also checks permissions
→ A developer calls it thinking it's read-only
→ They skip the permission check in another flow
→ An authorization bypass is created

Edge Cases + Security:
A pagination endpoint without page/size validation
→ size=1000000 allows dumping the entire database
→ What looks like an edge case is an attack vector

Naming + Edge Cases:
A function called calculate_average() that doesn't handle an empty list
→ The name suggests it handles any list
→ ZeroDivisionError in production when there's no data

Recognizing these intersections makes you more effective: when you find a pattern, you check whether it has implications in the other categories.

Before You Start: Self-Assessment

Evaluate your current level of pattern recognition:

How do you review AI code for errors?

A. "I check if it works and that's it"
   → This module is going to change your perspective completely

B. "I look for obvious errors: typos, missing imports"
   → You're at the superficial level — the real errors are more subtle

C. "I have intuition about what can fail but it's not systematic"
   → This module is going to turn your intuition into a process

D. "I know exactly what type of errors to look for in AI code"
   → Validate your knowledge with the exercises — you might be surprised

E. "I know the patterns and I can explain why AI generates them"
   → You're at an advanced level. Use the exercises to confirm

What you need for this module

Requirements:
├── ✅ Module 4 completed (professional code review)
├── ✅ Intermediate Python (read and understand code)
├── ✅ Basic FastAPI (understand routes, models, dependencies)
└── ✅ Basic SQL (understand SELECT/INSERT queries)

You don't need:
├── ❌ To be a security expert
├── ❌ To know all the design patterns
└── ❌ Experience with pentesting or ethical hacking

Signs of success

By the end of this module, you'll know you succeeded if:

  • ✅ When you see a function called process_data, you immediately ask "what does it process exactly?"
  • ✅ When you see items[0], you immediately think "what happens if items is empty?"
  • ✅ When you see a SQL query with an f-string, you immediately detect the injection risk
  • ✅ You can explain why AI tends to generate each type of error
  • ✅ You completed the capsule 05 exercise identifying at least 4 of 5 patterns
  • ✅ Your fixes include justification, not just the fix

Comparison: before and after

Before the module (review without patterns):
├── You review the code looking for "something that looks wrong"
├── You find obvious errors (syntax, imports)
├── The subtle errors slip past you
├── You don't know why AI generated the error
├── Your code review finds ~40% of the problems
└── Every review feels like starting from scratch

After the module (review with pattern recognition):
├── You know exactly what to look for in each type of code
├── The 3 patterns jump out automatically
├── You find errors that look like correct code
├── You understand the root cause of each pattern
├── Your code review finds ~80% of the problems
└── Every review applies the same pattern framework

Summary

  • This module trains pattern recognition for the 3 most frequent types of error in AI code
  • Incorrect naming and abstractions (~30%): misleading names, Factory where if/else would suffice, unnecessary inheritance
  • Unhandled edge cases (~35%): null, empty, off-by-one, division by zero, concurrency
  • Security holes (~15%): SQL injection, hardcoded secrets, endpoints without auth, XSS
  • These 3 patterns represent 80% of the errors in AI-generated code
  • The focus is pattern recognition, not memorization: "when I see X, I look for Y"
  • AI makes these errors for structural reasons: it optimizes for the happy path, replicates statistical patterns, prioritizes functionality over security
  • The final exercise (capsule 05) has FastAPI code with 5 embedded errors to identify and fix

Additional resources

  1. OWASP Top 10 - The 10 most critical web security vulnerabilities — the industry standard reference
  2. Clean Code — Robert C. Martin - Principles of correct naming, functions, and abstractions
  3. Refactoring Guru — Design Patterns - When to use and when NOT to use each design pattern
  4. FastAPI Security Best Practices - Official FastAPI security documentation
  5. Anthropic — Claude Code Best Practices - Official Claude Code documentation

Next capsule: Incorrect Naming and Abstractions — the most subtle and frequent pattern in AI code.

Debugging & Code Review with Claude Code — Module 5, Capsule 01 Claude Code Agentic Development Path — Guide #6 of 11

← PreviousExercise: Code Review of an AI-Generated PRNext →Incorrect Naming and Abstractions