Módulo 5: Patrones de Error Comunes

Módulo 5: Patrones de Error Comunes en Código AI-Generated

Descripción de la cápsula

En el módulo 4 aprendiste a hacer code review profesional de output AI: tienes un checklist, sabes priorizar, y puedes documentar findings. Eso es el proceso. Ahora necesitas el contenido: saber exactamente qué buscar. Porque hay una diferencia enorme entre "reviso código AI buscando problemas" y "sé que AI tiende a generar funciones con nombres engañosos, ignora edge cases de null/vacío, y deja SQL injection en queries concatenados."

Este módulo entrena tu pattern recognition. La idea es que cuando veas código generado por Claude Code, ciertos patrones salten automáticamente — como un doctor que ve síntomas y sabe el diagnóstico antes de pedir análisis. No porque memorices una lista, sino porque internalizas los patrones que AI repite consistentemente.

Los LLMs tienen tendencias predecibles. Cometen los mismos tipos de errores una y otra vez. Conocer estas tendencias es un superpoder: en vez de revisar todo con la misma profundidad, sabes dónde buscar primero.

Contexto del Módulo

¿Dónde estamos?

Estás en el Módulo 5 de la guía "Debugging & Code Review with Claude Code", dentro de la Phase 2: Code Review Profesional.

Phase 2: Code Review Profesional
├── Módulo 4: Code Review de Output AI ← completado
│   └── Proceso, checklist, priorización, documentación
│   └── Cápsulas: intro, qué buscar, checklist, red flags, lógica de negocio, ejercicio
├── Módulo 5: Patrones de Error Comunes ← estás aquí
│   └── Los 3 tipos de error que representan el 80% de bugs en AI code
│   └── Cápsulas: intro, naming, edge cases, security, ejercicio
└── Módulo 6: Debugging con Claude Code → siguiente
    └── Diagnóstico y resolución de errores usando Claude Code como herramienta

El módulo 4 te dio el cómo hacer code review. Este módulo te da el qué: los patrones específicos que buscas. El módulo 6 te dará el qué hacer cuando encuentras un error y necesitas diagnosticarlo en profundidad.

La transición: de proceso a pattern recognition

En el módulo 4, tu checklist te dice:

☐ Verificar naming y abstracciones
☐ Revisar edge cases
☐ Buscar vulnerabilidades de seguridad
☐ Validar lógica de negocio
☐ Confirmar error handling

Pero cuando estás frente al código, surgen preguntas que el checklist no responde:

"¿Qué tipo de naming engañoso genera AI específicamente?"
"¿Cuáles edge cases AI tiende a ignorar?"
"¿Qué vulnerabilidades de seguridad son las más frecuentes en AI code?"
"¿Cómo se ve un patrón de diseño mal aplicado por AI?"

Este módulo responde esas preguntas con ejemplos concretos, código real, y patrones que puedes reconocer visualmente.

Los 3 Patrones que Representan el 80% de Errores

¿Por qué solo 3?

Podrías esperar una lista de 20 tipos de errores. Pero en la práctica, 3 categorías cubren la gran mayoría de problemas en código AI-generated:

Distribución de errores en AI code (basado en patrones observados):

1. Naming y abstracciones incorrectas    ─── ~30%
   └── Nombres engañosos, clases innecesarias, patrones mal aplicados

2. Edge cases no manejados               ─── ~35%
   └── Null, vacío, límites, concurrencia, unicode

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

4. Todo lo demás                         ─── ~20%
   └── Lógica de negocio, hallucinations, performance

Los primeros 3 suman ~80%. Aprender a reconocer estos 3 patrones te da el mayor retorno de inversión en tu code review.

¿Por qué AI comete estos errores específicos?

Cada tipo de error tiene una razón estructural:

Naming y abstracciones incorrectas — AI optimiza por patrones estadísticos. Ha visto millones de funciones llamadas get_user, process_data, handle_request. Replica esos nombres aunque no sean descriptivos para tu caso. Aplica Factory pattern porque lo vio en mucho código, no porque tu situación lo requiera.

Edge cases no manejados — AI genera el "happy path" con alta calidad. Los edge cases (null, vacío, concurrencia) requieren pensar en lo que puede salir mal — algo que AI no hace proactivamente. Genera items[0] sin considerar que items podría estar vacío.

Security holes — AI prioriza funcionalidad sobre seguridad. Genera un endpoint que funciona, pero sin auth. Construye un query que devuelve datos, pero con string concatenation vulnerable a SQL injection. La funcionalidad se ve correcta; la seguridad es invisible hasta que alguien la explota.

La metáfora del doctor

Piensa en un doctor experimentado. Cuando un paciente describe síntomas, el doctor no consulta una enciclopedia médica de 500 páginas. Reconoce patrones:

Síntomas: fiebre + dolor de garganta + ganglios inflamados
Diagnóstico probable: infección de garganta
→ No necesita considerar las 10,000 enfermedades posibles

Síntomas en código AI:
función llamada get_user que hace 3 cosas diferentes
→ Diagnóstico: naming incorrecto + single responsibility violation
→ No necesitas revisar toda la taxonomía de code smells

Tu objetivo es desarrollar esa misma intuición para código AI-generated. Cuando ves ciertos "síntomas" en el código, tu diagnóstico es casi automático.

Progresión del Módulo

Mapa del Módulo

Cápsula	Tema	Qué aprenderás	Tipo
02	Naming y Abstracciones Incorrectas	Nombres engañosos, abstracciones prematuras, patrones mal aplicados	Técnica
03	Edge Cases No Manejados	Null, vacío, boundary, concurrencia, unicode	Técnica
04	Security Holes Típicos	SQL injection, secrets, auth, XSS, CORS, rate limiting	Técnica
05	Ejercicio: Identificar Patrones	Código FastAPI con 5 errores embebidos — identifica y corrige	Ejercicio

Flujo de aprendizaje

Empiezas con naming y abstracciones (cápsula 02) porque son los errores más frecuentes y los más sutiles — código que "funciona" pero es una bomba de tiempo para mantenimiento. Después atacas edge cases (cápsula 03), que son los errores que causan crashes en producción con inputs inesperados. Luego security holes (cápsula 04), que son los errores con mayor impacto potencial. Finalmente, el ejercicio integrador (cápsula 05) te hace aplicar todo en un codebase FastAPI realista.

La progresión es: errores sutiles → errores de runtime → errores de seguridad → aplicar todo junto.

Dependencias entre cápsulas

Cápsula 02 (Naming) ──────────┐
                                ├── Cápsula 05 (Ejercicio)
Cápsula 03 (Edge Cases) ──────├── El ejercicio contiene
                                │   los 3 tipos de error
Cápsula 04 (Security) ────────┘

Las cápsulas 02, 03 y 04 son independientes entre sí — puedes leerlas en cualquier orden. Pero la cápsula 05 requiere haber completado las tres, porque el ejercicio contiene errores de las tres categorías.

Objetivo Profesional

Al final de este módulo podrás:

✅ Reconocer naming engañoso en funciones AI-generated: nombres que prometen una cosa y hacen otra
✅ Detectar abstracciones incorrectas: Factory donde bastaba if/else, herencia profunda innecesaria
✅ Identificar edge cases no manejados: null, vacío, off-by-one, división por cero, concurrencia
✅ Encontrar security holes comunes: SQL injection, secrets hardcoded, endpoints sin auth, XSS
✅ Corregir cada patrón con justificación de por qué la corrección es correcta
✅ Explicar por qué AI genera cada tipo de error (entender la causa, no solo el síntoma)

Conexión con Proyecto

Cómo se conecta con el proyecto integrador (Módulo 8)

El codebase del proyecto integrador contiene intencionalmente los 3 tipos de patrones de error. Las correcciones que practicas en este módulo son exactamente lo que harás en el proyecto:

Proyecto integrador (Módulo 8):
├── 3-4 errores de naming y abstracciones
│   └── Funciones con nombres engañosos
│   └── Patrones de diseño mal aplicados
├── 3-4 edge cases no manejados
│   └── Null handling faltante
│   └── Arrays vacíos que causan crashes
│   └── Off-by-one en paginación
├── 3-4 security holes
│   └── SQL injection
│   └── Secret hardcoded
│   └── Endpoint sin auth
└── ... otros tipos de errores

Si dominas este módulo, puedes encontrar 10-12 de los 15-20 problemas del proyecto solo con pattern recognition — antes de siquiera ejecutar el código.

Ejercicio de este módulo

El ejercicio de la cápsula 05 es una versión concentrada del proyecto integrador: una aplicación FastAPI de ~150 líneas con 5 patrones de error embebidos. Es tu ensayo general para el módulo 8.

Límites: Qué NO Se Cubre en Este Módulo

❌ Hallucinations — Imports falsos, APIs inventadas. Eso fue el módulo 3. Aquí los errores son de código real, no inventado.
❌ Debugging — Diagnosticar y arreglar errores en runtime. Eso es el módulo 6. Aquí identificas patrones, no debuggeas.
❌ Proceso de code review — Eso fue el módulo 4. Aquí asumes que ya tienes un proceso y lo enriqueces con contenido.
❌ Cada error posible — No cubrimos performance, memory leaks, o errores de concurrencia avanzada. Cubrimos el 80% más frecuente.

Cómo Usar Este Módulo

Enfoque recomendado

Para cada patrón de error (cápsulas 02-04):

1. Lee el código vulnerable que AI genera
   → "¿Lo hubieras aceptado a primera vista?"

2. Entiende por qué se ve correcto
   → "¿Qué te engaña?"

3. Ve cómo se explota o falla
   → "¿Cuál es el impacto real?"

4. Estudia la corrección
   → "¿Por qué esta versión es mejor?"

5. Practica con los ejercicios
   → "¿Puedes detectar el patrón sin ayuda?"

Los 4 componentes de cada patrón

Cada ejemplo de error en las cápsulas 02-04 sigue la misma estructura de 4 componentes. Esta estructura no es arbitraria — es la que entrena pattern recognition efectivo:

Componente A: El código que AI genera
├── Código completo con imports
├── Funciona correctamente con happy path inputs
└── Se ve profesional y limpio

Componente B: Por qué se ve bien a primera vista
├── Qué señales de "código correcto" tiene
├── Por qué un code review superficial lo aceptaría
└── Qué te engaña visualmente

Componente C: Cómo se rompe o se explota
├── El input específico que causa el problema
├── El escenario de producción donde falla
├── El impacto real (crash, data leak, breach)
└── Esto es lo que ancla el patrón en tu memoria

Componente D: La corrección correcta
├── Código completo con la fix
├── Justificación de por qué es mejor
├── Qué principio aplica (defense in depth, least privilege, etc.)
└── Esto te da la herramienta para actuar

Sin el componente B, no entiendes por qué el error se escapa. Sin el C, no sientes la urgencia. Sin el D, no puedes hacer nada al respecto. Los 4 juntos crean el patrón completo.

El ciclo de reconocimiento

Después de estudiar los ejemplos de cada cápsula, tu cerebro empieza a crear atajos:

Ciclo 1 (consciente — primeras revisiones):
"Veo un f-string en SQL... espera, ¿no era eso SQL injection?
Sí, cápsula 04 lo cubrió. Necesito parameterized queries."
→ 30 segundos de análisis consciente

Ciclo 10 (semi-automático — después de práctica):
"f-string en SQL → parameterize"
→ 5 segundos, el patrón salta

Ciclo 50+ (automático — pattern recognition):
*Ve f-string en query* → *señal de alerta inmediata*
→ < 1 segundo, sin esfuerzo consciente

El módulo te lleva del ciclo 1 al ciclo 10. La práctica diaria te lleva del 10 al 50.

Lo que hace este módulo diferente

Este módulo no es una lista de "10 errores comunes en Python." Es un entrenamiento de pattern recognition específico para AI-generated code. La diferencia:

Lista de errores genérica:
├── "No uses eval()"
├── "Siempre valida input"
├── "No hardcodees secrets"
└── Sabes QUÉ evitar, pero no QUÉ BUSCAR en código AI

Pattern recognition para AI code:
├── "AI genera get_user() que también modifica estado"
│   → Sabes buscar funciones con nombres simples que hacen varias cosas
├── "AI genera items[0] sin verificar si items está vacío"
│   → Sabes buscar accesos directos a índices sin guards
├── "AI concatena strings en SQL queries"
│   → Sabes buscar f-strings o + dentro de queries
└── Sabes QUÉ BUSCAR porque conoces las tendencias de AI

Relación entre los 3 Patrones

Los 3 patrones no son categorías aisladas — a veces se cruzan y se refuerzan:

Naming + Security:
Una función llamada get_user() que también verifica permisos
→ Un developer la llama pensando que es solo lectura
→ Se salta la verificación de permisos en otro flujo
→ Se crea un bypass de autorización

Edge Cases + Security:
Un endpoint de paginación sin validación de page/size
→ size=1000000 permite dump de toda la base de datos
→ Lo que parece un edge case es un vector de ataque

Naming + Edge Cases:
Una función llamada calculate_average() que no maneja lista vacía
→ El nombre sugiere que maneja cualquier lista
→ ZeroDivisionError en producción cuando no hay datos

Reconocer estas intersecciones te hace más efectivo: cuando encuentras un patrón, buscas si tiene implicaciones en las otras categorías.

Antes de Empezar: Autodiagnóstico

Evalúa tu nivel actual de pattern recognition:

¿Cómo revisas código AI para errores?

A. "Reviso si funciona y ya"
   → Este módulo te va a cambiar la perspectiva completamente

B. "Busco errores obvios: typos, imports faltantes"
   → Estás en el nivel superficial — los errores reales son más sutiles

C. "Tengo intuición de qué puede fallar pero no es sistemático"
   → Este módulo va a convertir tu intuición en proceso

D. "Sé exactamente qué tipo de errores buscar en AI code"
   → Valida tu conocimiento con los ejercicios — podrías sorprenderte

E. "Conozco los patrones y puedo explicar por qué AI los genera"
   → Estás en nivel avanzado. Usa los ejercicios para confirmar

Qué necesitas para este módulo

Requisitos:
├── ✅ Módulo 4 completado (code review profesional)
├── ✅ Python intermedio (leer y entender código)
├── ✅ FastAPI básico (entender rutas, modelos, dependencias)
└── ✅ SQL básico (entender queries SELECT/INSERT)

No necesitas:
├── ❌ Ser experto en seguridad
├── ❌ Conocer todos los design patterns
└── ❌ Experiencia con pentesting o ethical hacking

Evidencia de Éxito

Al terminar este módulo, sabrás que tuviste éxito si:

✅ Cuando ves una función llamada process_data, inmediatamente preguntas "¿qué procesa exactamente?"
✅ Cuando ves items[0], inmediatamente piensas "¿qué pasa si items está vacío?"
✅ Cuando ves un SQL query con f-string, inmediatamente detectas el riesgo de injection
✅ Puedes explicar por qué AI tiende a generar cada tipo de error
✅ Completaste el ejercicio de la cápsula 05 identificando al menos 4 de 5 patrones
✅ Tus correcciones incluyen justificación, no solo el fix

Comparación: antes y después

Antes del módulo (revisión sin patterns):
├── Revisas el código buscando "algo que se vea mal"
├── Encuentras errores obvios (syntax, imports)
├── Los errores sutiles se te escapan
├── No sabes por qué AI generó el error
├── Tu code review encuentra ~40% de los problemas
└── Cada review se siente como empezar de cero

Después del módulo (revisión con pattern recognition):
├── Sabes exactamente qué buscar en cada tipo de código
├── Los 3 patrones saltan automáticamente
├── Encuentras errores que parecen código correcto
├── Entiendes la causa raíz de cada patrón
├── Tu code review encuentra ~80% de los problemas
└── Cada review aplica el mismo framework de patrones

Resumen

Este módulo entrena pattern recognition para los 3 tipos de error más frecuentes en AI code
Naming y abstracciones incorrectas (~30%): nombres engañosos, Factory donde bastaba if/else, herencia innecesaria
Edge cases no manejados (~35%): null, vacío, off-by-one, división por cero, concurrencia
Security holes (~15%): SQL injection, secrets hardcoded, endpoints sin auth, XSS
Estos 3 patrones representan el 80% de los errores en código AI-generated
El enfoque es pattern recognition, no memorización: "cuando veo X, busco Y"
AI comete estos errores por razones estructurales: optimiza por happy path, replica patrones estadísticos, prioriza funcionalidad sobre seguridad
El ejercicio final (cápsula 05) tiene código FastAPI con 5 errores embebidos para identificar y corregir

Recursos Adicionales

OWASP Top 10 - Las 10 vulnerabilidades de seguridad web más críticas — referencia estándar de la industria
Clean Code — Robert C. Martin - Principios de naming, funciones, y abstracciones correctas
Refactoring Guru — Design Patterns - Cuándo usar y cuándo NO usar cada patrón de diseño
FastAPI Security Best Practices - Documentación oficial de seguridad en FastAPI
Anthropic — Claude Code Best Practices - Documentación oficial de Claude Code

Siguiente cápsula: Naming y Abstracciones Incorrectas — el patrón más sutil y frecuente en código AI.

Debugging & Code Review with Claude Code — Módulo 5, Cápsula 01 Claude Code Agentic Development Path — Guía #6 de 11

← AnteriorEjercicio: Code Review de un PR Generado por AI Siguiente →Naming y Abstracciones Incorrectas