Módulo 8: Proyecto Integrador

Proyecto Integrador: Code Review, Debugging y Corrección de un Codebase FastAPI

Descripción de la cápsula

Has llegado al proyecto integrador de la guía. Todo lo que aprendiste en los módulos 1-7 — awareness del problema de confianza en AI code, mental models para supervisar output, detección de hallucinations, code review profesional con checklist, reconocimiento de patrones de error, debugging con Claude Code, y decisiones de regenerar vs editar — se aplica aquí en un escenario completo y realista.

El escenario: recibes un codebase de una API de gestión de tareas construida con FastAPI. El código fue "generado por AI" y contiene entre 15 y 20 problemas distribuidos en múltiples categorías. Tu trabajo no es generar código nuevo — es validar, diagnosticar y corregir el código existente. Exactamente lo que un senior developer hace cuando recibe código de un junior o de una herramienta AI.

Esta cápsula establece el scope completo del proyecto, te entrega los requisitos de negocio contra los cuales evaluar el código, describe la estructura del codebase, y define exactamente qué debes entregar.

Contexto del Proyecto

Lo que simula este proyecto

En tu trabajo diario con Claude Code, vas a generar código constantemente. A veces será perfecto. A veces tendrá problemas sutiles que pasan desapercibidos hasta producción. Este proyecto simula la segunda situación: código que se ve razonable pero tiene problemas reales.

La diferencia con un ejercicio de módulo individual es la escala. En el módulo 3 detectaste hallucinations en snippets aislados. En el módulo 5 identificaste patrones en funciones individuales. Aquí tienes un codebase completo con 8-12 archivos interconectados, donde los problemas se esconden en la interacción entre módulos, en la lógica que cruza archivos, y en los detalles que son fáciles de ignorar cuando estás revisando un sistema completo.

El rol que asumes

Eres un senior developer que recibe un codebase para code review antes de que se haga merge a la rama principal. El código fue generado usando Claude Code por un compañero de equipo. Tu responsabilidad:

Revisar el código contra los requisitos de negocio
Identificar todos los problemas (seguridad, lógica, edge cases, hallucinations, runtime bugs)
Debuggear los problemas que requieren ejecución para confirmar
Corregir cada problema con justificación
Documentar todo el proceso con un findings document profesional
Reflexionar sobre tu proceso con una retrospectiva

Requisitos de Negocio: Task Management API

Este es el documento de requisitos funcionales contra el cual debes evaluar el código. Léelo con atención — cada divergencia entre estos requisitos y la implementación es un problema que debes documentar.

Documento de Requisitos Funcionales

Producto: TaskFlow API Versión: 1.0 Fecha: Marzo 2026

RF-01: Gestión de Usuarios

ID	Requisito	Prioridad
RF-01.1	El sistema debe permitir registrar usuarios con email, nombre y contraseña	Alta
RF-01.2	La contraseña debe almacenarse hasheada con bcrypt, nunca en texto plano	Crítica
RF-01.3	El email debe ser único en el sistema	Alta
RF-01.4	El sistema debe validar formato de email y longitud mínima de contraseña (8 caracteres)	Alta

RF-02: Autenticación

ID	Requisito	Prioridad
RF-02.1	Login con email y contraseña, retornando un JWT token	Alta
RF-02.2	El JWT debe expirar en 30 minutos	Alta
RF-02.3	El JWT secret key debe cargarse desde variables de entorno, sin fallback hardcoded	Crítica
RF-02.4	Endpoints protegidos deben requerir token válido en header Authorization	Crítica

RF-03: Gestión de Tareas (CRUD)

ID	Requisito	Prioridad
RF-03.1	Crear tarea con título (obligatorio), descripción (opcional), prioridad (low/medium/high), y estado (pending/in_progress/completed)	Alta
RF-03.2	Listar tareas del usuario autenticado con paginación (10 por página por defecto)	Alta
RF-03.3	Filtrar tareas por estado y/o prioridad	Media
RF-03.4	Obtener detalle de una tarea por ID (solo si pertenece al usuario)	Alta
RF-03.5	Actualizar tarea (solo el propietario puede modificarla)	Alta
RF-03.6	Eliminar tarea (solo el propietario, soft delete cambiando estado a "deleted")	Alta
RF-03.7	Un usuario NO debe poder ver, editar ni eliminar tareas de otro usuario	Crítica

RF-04: Estadísticas

ID	Requisito	Prioridad
RF-04.1	Endpoint que retorna estadísticas del usuario: total de tareas, tareas por estado, tareas por prioridad	Media
RF-04.2	Las estadísticas deben calcularse solo sobre las tareas activas (no las eliminadas/soft-deleted)	Media
RF-04.3	Incluir porcentaje de tareas completadas sobre el total activo	Media

RF-05: Validaciones y Edge Cases

ID	Requisito	Prioridad
RF-05.1	Títulos de tarea: mínimo 3 caracteres, máximo 100	Media
RF-05.2	Prioridad solo acepta valores: "low", "medium", "high"	Media
RF-05.3	Estado solo acepta valores: "pending", "in_progress", "completed"	Media
RF-05.4	Paginación: page debe ser >= 1, size debe ser entre 1 y 100	Media
RF-05.5	IDs de tarea inexistentes deben retornar 404 con mensaje descriptivo	Media
RF-05.6	Intentar acceder a tarea de otro usuario debe retornar 403, no 404	Media

RF-06: Requisitos No Funcionales

ID	Requisito	Prioridad
RF-06.1	Configuración sensible (DB URL, JWT secret) desde variables de entorno	Crítica
RF-06.2	Queries SQL deben usar parámetros, nunca concatenación de strings	Crítica
RF-06.3	Errores internos no deben exponer stack traces al cliente	Alta
RF-06.4	La API debe retornar respuestas consistentes en formato JSON	Media

Estructura del Codebase

El codebase que recibirás en la siguiente cápsula tiene esta estructura:

taskflow-api/
├── main.py                    # Punto de entrada de la aplicación FastAPI
├── config.py                  # Configuración y variables de entorno
├── database.py                # Conexión y operaciones de base de datos
├── models.py                  # Modelos Pydantic (request/response)
├── routes/
│   ├── auth.py                # Endpoints de registro y login
│   ├── tasks.py               # Endpoints CRUD de tareas
│   └── users.py               # Endpoints de perfil y estadísticas
├── services/
│   ├── auth_service.py        # Lógica de autenticación y JWT
│   └── task_service.py        # Lógica de negocio de tareas
└── requirements.txt           # Dependencias del proyecto

Descripción de cada archivo

main.py — Configuración de la aplicación FastAPI, registro de routers, y middleware. Es donde todo se conecta.

config.py — Clase de configuración que carga variables de entorno. Incluye configuración de base de datos, JWT, y parámetros de la aplicación.

database.py — Funciones para crear la base de datos SQLite, obtener conexiones, y ejecutar queries. Este archivo es crítico: contiene la interacción directa con la base de datos.

models.py — Modelos Pydantic para validar request bodies y formatear responses. Define los schemas de usuario, tarea, autenticación, y estadísticas.

routes/auth.py — Endpoints de POST /register y POST /login. Maneja la creación de usuarios y la generación de tokens.

routes/tasks.py — Endpoints CRUD: crear, listar, obtener, actualizar, y eliminar tareas. Incluye filtros y paginación.

routes/users.py — Endpoint de estadísticas del usuario y perfil.

services/auth_service.py — Funciones de hashing de contraseñas, generación y verificación de JWT, y extracción del usuario actual.

services/task_service.py — Lógica de negocio: crear tarea, obtener tareas con filtros, calcular estadísticas, y validaciones.

Cómo Leer los Requisitos: Guía Práctica

Los requisitos funcionales no son solo una lista de features — son tu herramienta principal de verificación. Aquí te explico cómo usarlos efectivamente durante el code review.

Técnica: Mapear requisito → código → verificación

Para cada requisito, sigue este proceso:

1. LEE el requisito (e.g., RF-01.2: contraseña hasheada con bcrypt)
2. BUSCA el código que lo implementa (¿dónde se guarda la contraseña?)
3. VERIFICA que la implementación cumple el requisito
4. DOCUMENTA si cumple o no (y por qué)

Ejemplo práctico

Requisito RF-01.2: La contraseña debe almacenarse hasheada 
con bcrypt, nunca en texto plano.

1. ¿Dónde se almacena la contraseña?
   → routes/auth.py, función register()
   → Ejecuta INSERT con el campo password

2. ¿Se hashea antes de insertar?
   → ¿Llama a hash_password() o bcrypt.hashpw()?
   → ¿O inserta user.password directamente?

3. ¿La función de hash existe y es correcta?
   → services/auth_service.py tiene hash_password()
   → ¿Se llama en el flujo de registro?

4. Resultado: [CUMPLE / NO CUMPLE]
   → Documentar en findings document si no cumple

Requisitos que son fáciles de pasar por alto

Algunos requisitos no son evidentes con solo leer el código:

RF-03.6: Soft delete — La palabra "delete" es engañosa. El requisito dice que eliminar debe cambiar el estado a "deleted", no borrar la fila de la base de datos. Necesitas verificar la implementación de delete, no solo que "funciona."

RF-04.2: Estadísticas sobre tareas activas — Si el delete no implementa soft delete correctamente, las estadísticas podrían estar afectadas también. Los requisitos están interconectados.

RF-05.6: 403 vs 404 — La diferencia es sutil: 404 dice "no existe," 403 dice "existe pero no tienes permiso." La implementación de autorización determina cuál se retorna. Muchos developers lo implementan como 404 para ambos casos, pero el requisito específicamente pide 403 cuando la tarea existe pero pertenece a otro usuario.

RF-06.2: Parámetros en SQL — No basta con verificar que hay un ? en la query principal. Necesitas verificar TODAS las queries del codebase, incluyendo las de filtros dinámicos y búsquedas.

La importancia de los requisitos de prioridad "Media"

Los requisitos marcados como "Media" parecen menos importantes, pero en este proyecto representan la diferencia entre una entrega buena y una excelente. Los problemas más sutiles del codebase están en los requisitos de prioridad media:

✅ Validación de longitud de título (RF-05.1)
✅ Validación de valores de prioridad y estado (RF-05.2, RF-05.3)
✅ Parámetros de paginación (RF-05.4)
✅ Estadísticas sobre tareas activas (RF-04.2)

Un developer junior encuentra los Critical (secrets hardcoded, SQL injection). Un developer senior también encuentra los Medium (validaciones incorrectas, cálculos erróneos).

Tipos de Problemas que Encontrarás

El codebase contiene entre 15 y 20 problemas distribuidos en 5 categorías. No se te dice dónde están — encontrarlos es parte del ejercicio. Lo que sí se te dice es qué tipos de problemas buscar:

Categoría 1: Hallucinations (3-4 problemas)

Código que referencia algo que no existe o que usa una API incorrectamente:

✅ Imports de módulos o funciones que no existen
✅ Funciones de librerías con parámetros que no acepta
✅ APIs con signatures inventadas que parecen correctas

Módulo de referencia: Módulo 3 — Detectar Hallucinations en Código

Categoría 2: Security Holes (3-4 problemas)

Vulnerabilidades que exponen el sistema a ataques o acceso no autorizado:

✅ Secrets hardcoded en el código fuente
✅ SQL injection por concatenación de strings
✅ Endpoints sin protección de autenticación
✅ Contraseñas almacenadas sin protección adecuada

Módulo de referencia: Módulo 5, Cápsula 04 — Security Holes Típicos

Categoría 3: Edge Cases No Manejados (3-4 problemas)

Inputs o condiciones que causan comportamiento inesperado:

✅ Valores null/None no manejados
✅ Listas vacías que causan errores
✅ Errores de off-by-one en paginación

Módulo de referencia: Módulo 5, Cápsula 03 — Edge Cases No Manejados

Categoría 4: Lógica Incorrecta (3-4 problemas)

Código que se ejecuta sin errores pero produce resultados incorrectos:

✅ Filtros que incluyen en vez de excluir (o viceversa)
✅ Cálculos de estadísticas incorrectos
✅ Validaciones que aceptan datos que deberían rechazar

Módulo de referencia: Módulo 4, Cápsula 05 — Verificar Lógica de Negocio

Categoría 5: Runtime Bugs (2-3 problemas)

Errores que solo aparecen al ejecutar el código con ciertos inputs:

✅ Type mismatches que solo se manifiestan con datos específicos
✅ Errores que solo aparecen con combinaciones particulares de parámetros

Módulo de referencia: Módulo 6 — Debugging con Claude Code

Formato de Entrega

Tu entrega debe contener exactamente estos 4 componentes:

1. Findings Document (40% de la evaluación)

Una tabla documentando cada problema encontrado:

# Findings Document — TaskFlow API Code Review

## Resumen Ejecutivo
[2-3 oraciones describiendo el estado general del codebase]

## Findings

| # | Severidad | Categoría | Archivo | Línea(s) | Descripción | Impacto |
|---|-----------|-----------|---------|----------|-------------|---------|
| 1 | Critical  | Security  | config.py | 12 | JWT secret hardcoded en código fuente | Cualquier atacante puede forjar tokens válidos |
| 2 | High      | Logic     | services/task_service.py | 45-52 | [descripción] | [impacto] |
| ... | ... | ... | ... | ... | ... | ... |

## Estadísticas
- Total findings: X
- Critical: X
- High: X
- Medium: X
- Low: X

Guía de severidades

Severidad	Criterio	Ejemplos
Critical	Vulnerabilidad de seguridad explotable o pérdida de datos	SQL injection, secrets expuestos, auth bypass
High	Funcionalidad incorrecta que afecta a los usuarios	Lógica de negocio mal implementada, datos devueltos incorrectamente
Medium	Edge case no manejado o problema de robustez	Crash con inputs específicos, paginación incorrecta
Low	Problema de calidad o mantenibilidad	Import inexistente que no se usa, naming confuso

2. Código Corregido (30% de la evaluación)

El codebase completo con todas las correcciones aplicadas. Cada archivo corregido debe tener un comentario al inicio indicando qué se cambió:

# CORRECCIONES EN ESTE ARCHIVO:
# - Línea 12: Removido JWT secret hardcoded, ahora usa os.environ
# - Línea 45: Corregido filtro de estado (incluía deleted, ahora los excluye)
# - Línea 78: Agregado manejo de lista vacía en cálculo de estadísticas

3. Justificaciones (20% de la evaluación)

Para cada corrección, explica:

Qué cambió (el fix concreto)
Por qué el código original era incorrecto (referenciando el requisito funcional que viola)
Por qué tu corrección es correcta (cómo verificaste que soluciona el problema)
Decisión regenerar vs editar (si decidiste regenerar el fragmento con Claude Code o editarlo manualmente, y por qué)

## Justificación Finding #1: JWT Secret Hardcoded

**Qué cambié:** Reemplacé `SECRET_KEY = "mi-clave-secreta"` 
con `SECRET_KEY = os.environ["JWT_SECRET_KEY"]`

**Por qué era incorrecto:** Viola RF-06.1 (configuración sensible 
desde variables de entorno) y RF-02.3 (JWT secret sin fallback 
hardcoded). Un atacante con acceso al código fuente podría 
forjar tokens válidos.

**Por qué mi fix es correcto:** `os.environ[]` lanza KeyError 
si la variable no existe, lo cual es el comportamiento deseado: 
la app no debe iniciar si falta configuración crítica.

**Decisión:** Editar manualmente. El fix es puntual (una línea) 
y el contexto es claro. Regenerar sería desproporcionado.

4. Retrospectiva (10% de la evaluación)

Documento de 300-500 palabras. Detalle completo en la Cápsula 05 de este módulo.

Timeline y Enfoque Sugerido

El proyecto está diseñado para completarse en 3-4 horas. Esta es la distribución sugerida:

Fase 1: Code Review (60-90 min)

Lectura inicial (15 min): Lee todos los archivos para entender la estructura general
Review contra requisitos (30-45 min): Compara cada archivo contra los requisitos funcionales
Checklist de seguridad (15-20 min): Aplica los items de seguridad del checklist del módulo 4
Documentar findings (10-15 min): Registra cada problema encontrado en el formato del findings document

Fase 2: Debugging (30-45 min)

Setup local (10 min): Instalar dependencias y levantar la aplicación
Reproducir bugs (15-20 min): Ejecutar los endpoints que sospechas tienen problemas
Confirmar findings (10-15 min): Verificar los hallazgos del code review con pruebas reales

Fase 3: Corrección (45-60 min)

Priorizar (5 min): Ordenar findings por severidad
Corregir Critical y High (25-30 min): Implementar fixes para los problemas más graves
Corregir Medium y Low (15-20 min): Implementar fixes restantes
Verificar correcciones (10 min): Probar que cada fix funciona

Fase 4: Documentación y Retrospectiva (30-45 min)

Completar findings document (10-15 min): Asegurar que cada finding tiene toda la información
Escribir justificaciones (15-20 min): Documentar el razonamiento de cada fix
Escribir retrospectiva (10-15 min): Reflexionar sobre el proceso

Herramientas y Técnicas a Usar

Del Módulo 2: Mental Models

Aplica los tres mental models durante todo el proyecto:

Managing an Intern: Enfócate en revisar la lógica de negocio y las decisiones de arquitectura, no cada línea de código
Circuit Breaker: Define checkpoints claros: "No paso a debugging hasta que termine el code review completo"
Trust Calibration: Confía más en el boilerplate (rutas, config básica) y desconfía más de la lógica de negocio y seguridad

Del Módulo 3: Detección de Hallucinations

Para cada import en el codebase:
1. ¿El paquete existe? → pip show <paquete>
2. ¿La función/clase existe en ese paquete? → documentación oficial
3. ¿Los parámetros son correctos? → verificar signature real

Del Módulo 4: Code Review Checklist

Usa el checklist de 20 items del módulo 4, priorizando:

Seguridad primero: Items 1-5 del checklist (secrets, SQL injection, auth, permisos)
Lógica de negocio: Items 6-10 (resultados correctos, edge cases, validaciones)
Robustez: Items 11-15 (error handling, null checks, boundary conditions)
Calidad: Items 16-20 (naming, estructura, mantenibilidad)

Del Módulo 5: Patrones de Error

Busca activamente los 4 tipos de patrones de error comunes:

Naming y abstracciones incorrectas
Edge cases no manejados
Security holes típicos
Código que "funciona" pero produce resultados incorrectos

Del Módulo 6: Debugging Sistemático

Para los runtime bugs, sigue el proceso de 5 pasos:

1. REPRODUCIR → Crear el input que causa el error
2. AISLAR    → Encontrar la línea/función exacta
3. DIAGNOSTICAR → Entender POR QUÉ falla
4. FIX       → Implementar la corrección
5. VERIFICAR → Confirmar que el fix funciona y no rompe nada

Del Módulo 7: Claude Code como Herramienta

Puedes usar Claude Code durante el proyecto para:

✅ Analizar stack traces y logs de error
✅ Investigar si un import o API existe
✅ Obtener hipótesis de diagnóstico para bugs difíciles
✅ Generar fixes puntuales para problemas claros

No uses Claude Code para:

❌ "Encuentra todos los bugs" — eso es tu trabajo
❌ Aceptar diagnósticos sin verificar
❌ Regenerar el codebase completo

Del Módulo 7: Framework Regenerar vs Editar

Para cada fix, decide:

Regenerar cuando...	Editar cuando...
El approach completo es incorrecto	El 90% del código está bien
La función entera tiene problemas	El fix es puntual (1-5 líneas)
Hay demasiados cambios interconectados	El cambio es claro y localizado
La lógica base está equivocada	Solo necesitas ajustar un detalle

Criterios de Evaluación

Componente	Peso	Excelente (90-100%)	Bueno (70-89%)	Necesita mejora (<70%)
Findings	40%	Encuentra 15+ de 18 problemas con severidad correcta	Encuentra 12-14 con severidad mayormente correcta	Encuentra <12 o severidades incorrectas
Correcciones	30%	Todas las correcciones son correctas y justificadas	La mayoría son correctas, algunas justificaciones débiles	Correcciones parciales o incorrectas
Proceso	20%	Proceso sistemático, documentado, uso apropiado de herramientas	Proceso razonable, documentación incompleta	Proceso desorganizado, sin documentación
Retrospectiva	10%	Reflexiva, específica, con actionables concretos	Reflexiva pero genérica	Superficial o ausente

Antes de Empezar

Checklist de preparación

Antes de pasar a la siguiente cápsula (donde recibirás el codebase), verifica:

✅ Leíste los requisitos funcionales completos (sección anterior)
✅ Entiendes la estructura del codebase (8 archivos + requirements.txt)
✅ Sabes qué tipos de problemas buscar (5 categorías)
✅ Tienes claro el formato de entrega (4 componentes)
✅ Tienes Python 3.10+ instalado
✅ Tienes acceso a Claude Code
✅ Tienes el checklist del módulo 4 a la mano
✅ Reservaste 3-4 horas de tiempo sin interrupciones

Mentalidad correcta

Este proyecto no es un examen de velocidad. Es una simulación de trabajo profesional. En el trabajo real:

No te premian por encontrar los bugs más rápido — te premian por no dejar pasar ninguno
La documentación es tan importante como el fix
La reflexión sobre tu proceso te hace mejor la próxima vez
Pedir ayuda a herramientas (como Claude Code) es inteligente, no trampa

Aborda el proyecto con la mentalidad de un senior developer haciendo code review antes de un deploy a producción. Cada problema que dejas pasar es un problema que tus usuarios van a encontrar.

Preparación del entorno

Antes de empezar, asegúrate de tener todo listo:

# Verificar versión de Python
python --version
# Debe ser 3.10 o superior

# Verificar que pip está disponible
pip --version

# Verificar que tienes SQLite
sqlite3 --version

# Verificar Claude Code
claude --version

Si algo falta, instálalo antes de empezar. No quieres perder tiempo debuggeando tu entorno cuando deberías estar debuggeando el codebase.

Organización sugerida de archivos

Crea esta estructura para tu entrega:

proyecto-integrador/
├── taskflow-api/            # El codebase original (para referencia)
├── taskflow-api-fixed/      # Tu versión corregida
├── findings-document.md     # Tabla de findings
├── justifications.md        # Justificación de cada fix
├── debugging-log.md         # Log del proceso de debugging
└── retrospectiva.md         # Tu retrospectiva

Tener el codebase original y el corregido por separado te permite comparar fácilmente qué cambió y documentar cada cambio con referencia a las líneas originales.

Mapa Visual del Proyecto

Para que tengas clara la secuencia completa del proyecto, este es el flujo de trabajo que seguirás:

┌─────────────────────────────────────────────────────────┐
│                    FASE 1: CODE REVIEW                   │
│                                                          │
│  Leer requisitos → Leer código → Comparar → Documentar  │
│                                                          │
│  Outputs: Findings document (draft)                      │
└───────────────────────┬─────────────────────────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────────────┐
│                    FASE 2: DEBUGGING                     │
│                                                          │
│  Setup local → Ejecutar API → Reproducir bugs →          │
│  Confirmar findings → Buscar runtime bugs adicionales    │
│                                                          │
│  Outputs: Findings document (actualizado), Debugging log │
└───────────────────────┬─────────────────────────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────────────┐
│                   FASE 3: CORRECCIÓN                     │
│                                                          │
│  Priorizar → Corregir Critical → Corregir High →        │
│  Corregir Medium/Low → Verificar → Justificar           │
│                                                          │
│  Outputs: Código corregido, Justificaciones              │
└───────────────────────┬─────────────────────────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────────────┐
│                FASE 4: ENTREGA + RETROSPECTIVA           │
│                                                          │
│  Compilar entregables → Escribir retrospectiva →         │
│  Auto-evaluar → Entregar                                 │
│                                                          │
│  Outputs: Entrega completa con 4 documentos              │
└─────────────────────────────────────────────────────────┘

Cada fase tiene su propia cápsula con instrucciones detalladas. No necesitas memorizar todo ahora — solo entiende el flujo general y confía en que cada cápsula te guiará paso a paso.

Por Qué Este Formato de Proyecto

Tal vez te preguntes por qué el proyecto es "recibir código con problemas" en vez de "generar algo con Claude Code." La respuesta es simple: si el proyecto fuera generar código, tendrías incentivo de generar algo simple sin problemas. No practicarías la habilidad real.

La habilidad real es esta: recibir código que alguien más (o AI) generó, evaluarlo con criterio profesional, y mejorarlo. Es lo que hacen los senior developers todos los días. Es lo que harás con cada PR que revises de un compañero que usa Claude Code. Es lo que harás con tu propio código generado por AI la próxima vez que algo se sienta "raro."

Este proyecto te fuerza a practicar exactamente eso. No es un accidente — es deliberado.

Notas Importantes

Sobre el uso de Claude Code en el proyecto

Puedes (y debes) usar Claude Code durante el proyecto. La guía completa se trata de usar Claude Code con criterio profesional — y el proyecto es donde demuestras ese criterio.

Lo que se evalúa no es si usaste Claude Code, sino cómo lo usaste:

¿Le diste contexto suficiente o le pediste que "arregle todo"?
¿Verificaste sus sugerencias o las aplicaste ciegamente?
¿Usaste la herramienta correcta para cada situación?
¿Documentaste cuándo te ayudó y cuándo tuviste que hacer el trabajo manualmente?

Sobre la dificultad

Algunos problemas son evidentes (un import que falla al ejecutar). Otros son sutiles (una query que devuelve resultados correctos excepto en un edge case específico). No te frustres si no encuentras todo en la primera pasada. Los developers senior hacen múltiples pasadas de code review por una razón.

Sobre la honestidad

La retrospectiva es donde más se nota la diferencia entre alguien que completó el ejercicio con honestidad y alguien que no. No hay respuesta incorrecta en la retrospectiva — pero sí hay respuestas superficiales. "Todo fue fácil" no es una reflexión útil. "Me costó encontrar el SQL injection porque no revisé las queries con suficiente detalle en la primera pasada" sí lo es.

Siguiente cápsula: Fase de Code Review — El codebase completo de TaskFlow API con los problemas plantados, y las instrucciones para aplicar tu checklist profesional.

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

← AnteriorDecision Framework: Regenerar vs Editar Siguiente →Fase 1: Code Review — El Codebase de TaskFlow API