Módulo 4: El workflow agentic: Explore → Plan → Code

Cuándo Empezar una Nueva Sesión vs Continuar la Actual

Descripción

Cada vez que ejecutas claude en la terminal, inicias una sesión nueva. Esa sesión tiene su propia conversación, su propio contexto, y su propia historia. Puedes continuar sesiones anteriores con claude --continue o claude --resume, pero la pregunta real no es cómo — es cuándo.

Esta decisión parece trivial pero tiene un impacto directo en la calidad de tus resultados. Continuar una sesión contaminada con contexto irrelevante produce respuestas peores que empezar de cero con CLAUDE.md como base. Pero empezar de cero cuando llevas contexto valioso acumulado te obliga a reconstruir todo. La clave es saber cuándo el costo de mantener el contexto supera el beneficio.

En esta cápsula vas a aprender un framework de decisión claro: cuándo continuar, cuándo empezar de cero, cómo resumir sesiones anteriores, cómo trabajar con múltiples sesiones en paralelo, y los comandos que necesitas para gestionar sesiones como un profesional.

Sesiones en Claude Code: El Modelo Mental

Qué es una sesión

Una sesión es una instancia de conversación con Claude Code. Cada sesión tiene:

ID único — identificador interno
Historial de conversación — todos los mensajes enviados y recibidos
Contexto acumulado — archivos leídos, comandos ejecutados, código generado
CLAUDE.md cargado — siempre presente como base

Terminal A                    Terminal B
┌──────────────┐              ┌──────────────┐
│  Sesión #1   │              │  Sesión #2   │
│              │              │              │
│  CLAUDE.md ✓ │              │  CLAUDE.md ✓ │
│  Contexto:   │              │  Contexto:   │
│  - auth bug  │              │  - nuevo     │
│  - fix JWT   │              │    endpoint  │
│  - tests     │              │  - API docs  │
│              │              │              │
└──────────────┘              └──────────────┘
     ↑ misma CLAUDE.md ↑           ↑ mismo proyecto ↑

Las sesiones son independientes. La Sesión #2 no sabe nada de lo que pasó en la Sesión #1 (a menos que uses --continue o --resume).

Session recap (abril 2026)

Claude Code ahora genera automáticamente un session recap cuando resumes una sesión anterior. En lugar de tener que scrollar por todo el historial o pedirle a Claude que "lea la conversación", Claude Code te da un resumen estructurado:

Qué archivos se leyeron o modificaron
Qué decisiones importantes se tomaron
Qué tareas quedaron pendientes
Qué commands se ejecutaron

El recap aparece al inicio de la sesión resumida para que puedas retomar el trabajo rápido sin perder contexto. Funciona con claude --resume y claude --continue.

Cómo iniciar, continuar, y resumir

# Nueva sesión (context limpio + CLAUDE.md)
claude

# Continuar la última sesión (retoma donde quedaste)
claude --continue

# Resumir una sesión específica (elige de la lista)
claude --resume

claude --continue retoma la última sesión exactamente donde la dejaste. Todo el contexto de esa sesión sigue ahí.

claude --resume te muestra una lista de sesiones anteriores para que elijas cuál retomar. Útil cuando tienes múltiples sesiones y quieres volver a una específica.

El ciclo de vida de una sesión

claude                    ← Inicia sesión nueva
  │
  ├── Mensaje 1 → Respuesta 1
  ├── Mensaje 2 → Respuesta 2
  ├── ...
  ├── /compact             ← Comprime contexto (sesión sigue viva)
  ├── Mensaje N → Respuesta N
  │
  └── Ctrl+C / exit        ← Sesión termina (se guarda en historial)
       │
       ├── claude --continue  ← Retoma esta sesión
       └── claude             ← Nueva sesión (esta se archiva)

El Framework de Decisión

La pregunta central

Antes de cada sesión, pregúntate:

¿El contexto de la sesión anterior me ayuda o me estorba?

Si ayuda → claude --continue
Si estorba → claude (nueva sesión)
Si no estás seguro → probablemente nueva sesión

Cuándo continuar la sesión

1. Mismo task, aún en progreso

# Sesión anterior: empezaste a implementar un endpoint
# Paraste para comer
# Vuelves y quieres terminar

claude --continue
# Claude recuerda el endpoint, el diseño, las decisiones

2. Follow-up directo

# Sesión anterior: implementaste el endpoint
# Ahora quieres agregar tests para ESE endpoint

claude --continue
Tú: "Crea tests para el endpoint que implementamos."
# Claude tiene todo el contexto de lo que implementó

3. Debugging del mismo issue

# Sesión anterior: encontraste un bug, estás investigando
# Paraste para leer documentación
# Vuelves con nueva información

claude --continue
Tú: "Encontré algo: el bug solo pasa cuando el usuario tiene 
     más de 100 items. Probablemente es el LIMIT en la query."
# Claude tiene todo el contexto del debugging previo

4. Iteración sobre lo construido

# Sesión anterior: creaste una función parseCSV
# Quieres agregar streaming support

claude --continue
Tú: "Convierte parseCSV a un Readable stream."
# Claude conoce la implementación actual

Cuándo empezar sesión nueva

1. Tema completamente diferente

# Sesión anterior: trabajaste en autenticación
# Ahora quieres trabajar en el sistema de pagos

claude  # nueva sesión
Tú: "Necesito implementar el procesamiento de pagos con Stripe."
# No necesitas nada del contexto de auth

2. Contexto contaminado

# Sesión anterior: probaste 5 approaches diferentes para 
# resolver un problema. Ninguno funcionó. La conversación 
# está llena de código incorrecto y callejones sin salida.

claude  # nueva sesión
Tú: "Necesito resolver X. Ya probé A, B, C (no funcionaron). 
     El approach que quiero intentar es D."
# Contexto limpio + lecciones aprendidas en tu mensaje

3. Después de un milestone importante

# Sesión anterior: terminaste la feature completa, hiciste 
# commit, tests pasan.

claude  # nueva sesión para la siguiente feature
# "Borrón y cuenta nueva" para la siguiente tarea

4. Contexto lleno / degradado

# Sesión anterior: llevas 30+ mensajes, hiciste /compact 
# dos veces, las respuestas siguen siendo genéricas.

claude  # nueva sesión
# A veces la mejor compaction es empezar de cero

5. Diferente área del codebase

# Sesión anterior: trabajaste en el backend (Express, PostgreSQL)
# Ahora quieres trabajar en el frontend (React, CSS)

claude  # nueva sesión
# El contexto del backend no aporta nada al frontend

6. Después de cambios externos significativos

# Sesión anterior: trabajaste en un branch
# Otro developer hizo merge de 20 archivos a main
# Tu sesión anterior tiene una "foto vieja" del codebase

claude  # nueva sesión
# Claude leerá los archivos actualizados

Árbol de Decisión

¿Vas a trabajar en lo mismo que la sesión anterior?
│
├── SÍ
│   │
│   ├── ¿La sesión anterior tiene contexto limpio y relevante?
│   │   │
│   │   ├── SÍ → claude --continue
│   │   │
│   │   └── NO (mucho ruido, intentos fallidos, off-topic)
│   │       │
│   │       ├── ¿Puedes resumir lo necesario en 2-3 frases?
│   │       │   │
│   │       │   ├── SÍ → claude (nueva sesión con resumen en 1er mensaje)
│   │       │   │
│   │       │   └── NO → claude --continue + /compact con enfoque
│   │       │
│   │       └── (si el contexto es irrecuperable → claude nueva)
│   │
│   └── ¿Hubo cambios externos desde la última sesión?
│       │
│       ├── NO → claude --continue
│       │
│       └── SÍ (git pull, merge, etc.)
│           │
│           └── claude (nueva sesión para reflejar cambios)
│
└── NO (tema/área diferente)
    │
    └── claude (nueva sesión)

La heurística de las 2-3 frases

Si puedes resumir todo lo que Claude necesita saber de la sesión anterior en 2-3 frases, empieza una nueva sesión y pon ese resumen en tu primer mensaje.

Ejemplo:

# En vez de claude --continue con 20 mensajes de contexto contaminado:

claude  # nueva sesión
Tú: "Estoy implementando un sistema de comentarios anidados. 
     Ya creé el modelo Prisma (Comment con parentId para replies) 
     y el service en src/services/comment.service.ts. Falta el 
     controller y las rutas."

Claude tiene todo lo que necesita en 3 frases. El contexto limpio producirá mejores resultados que 20 mensajes acumulados.

Gestión de Sesiones

Ver sesiones anteriores

# Listar sesiones recientes
claude --resume
# Muestra una lista interactiva de sesiones anteriores
# con fecha, hora, y un resumen del tema

Historial de sesiones

Claude Code guarda un historial de sesiones. Cada sesión queda registrada con:

Timestamp de inicio y fin
Número de mensajes
Resumen del tema (generado automáticamente)

Session context en la práctica

# Sesión guardada en historial:
# ─────────────────────────────────
# ID: abc-123
# Fecha: 2026-02-28 14:30
# Mensajes: 12
# Tema: "Implementación de autenticación JWT"
# ─────────────────────────────────

# Para retomar:
claude --resume
# → Seleccionas "Implementación de autenticación JWT"
# → Claude carga todo el contexto de esa sesión

Comparaciones y Decisiones

El costo de la "polución de contexto"

Contexto contaminado = contexto que contiene información irrelevante, intentos fallidos, conversaciones off-topic, o datos desactualizados.

# Sesión "contaminada":
┌────────────────────────────────────────────┐
│ CLAUDE.md                          [2K]    │
│ Exploración de auth (relevante)    [10K]   │
│ Intento 1 de fix (falló)          [8K]    │
│ Intento 2 de fix (falló)          [12K]   │
│ Discusión off-topic sobre naming   [5K]    │
│ Intento 3 de fix (funcionó)       [6K]    │
│ Refactor de logging (otro tema)    [15K]   │
│ ──────────────────────────────────────     │
│ Total: 58K tokens                          │
│ Relevante para la tarea actual: ~16K (28%) │
│ Ruido: ~42K (72%)                          │
└────────────────────────────────────────────┘

# Sesión nueva:
┌────────────────────────────────────────────┐
│ CLAUDE.md                          [2K]    │
│ Tu primer mensaje con contexto     [500]   │
│ ──────────────────────────────────────     │
│ Total: 2.5K tokens                         │
│ Relevante: 100%                            │
│ Ruido: 0%                                  │
└────────────────────────────────────────────┘

72% de ruido vs 0%. ¿Cuál va a producir mejores respuestas?

Sesión continuada vs nueva sesión: tabla comparativa

Factor	Continuar sesión	Nueva sesión
Contexto previo	Todo disponible (incluido ruido)	Solo CLAUDE.md
Setup time	Cero — retomas donde quedaste	Necesitas re-contextualizar
Calidad de respuestas	Depende de la calidad del contexto	Alta (contexto limpio)
Riesgo	Context pollution	Perder contexto valioso
Costo de tokens	Ya gastados, los reutilizas	Gastas tokens para re-leer archivos
Ideal para	Follow-ups directos	Tareas nuevas o contexto contaminado

El "clean slate advantage"

Claude Code con CLAUDE.md bien configurado tiene una ventaja única: empezar de cero no es realmente de cero. CLAUDE.md le da:

Convenciones del proyecto
Stack tecnológico
Estructura de carpetas
Patterns a seguir
Cosas a evitar

# "De cero" en otros tools:
# Claude no sabe nada → necesitas explicar todo

# "De cero" en Claude Code con CLAUDE.md:
# Claude sabe las reglas del proyecto → solo necesitas 
# explicar la tarea específica

Esto reduce dramáticamente el "costo" de empezar sesión nueva. Si tu CLAUDE.md es bueno, una sesión nueva con un buen primer mensaje es casi tan productiva como una sesión continuada — y sin el ruido.

Patterns Comunes

Pattern 1: "Session per Feature"

Una sesión por feature. Terminas la feature, haces commit, nueva sesión.

# Feature: Sistema de comentarios
claude
Tú: "Implementa el sistema de comentarios..."
# ... 8-12 mensajes ...
# Feature completa, tests pasan, commit hecho
# Ctrl+C

# Feature: Sistema de notificaciones
claude  # nueva sesión
Tú: "Implementa el sistema de notificaciones..."

Ventaja: Contexto siempre relevante. Sin contaminación entre features.

Cuándo usar: Cuando las features son independientes.

Pattern 2: "Morning Fresh, Afternoon Continue"

Cada día empiezas con sesión nueva. Durante el día, continúas.

# Lunes 9:00 AM
claude  # sesión nueva
Tú: "Hoy voy a trabajar en el sistema de pagos..."

# Lunes 12:00 PM (después del almuerzo)
claude --continue  # retomar la mañana

# Lunes 5:00 PM
# Ctrl+C — fin del día

# Martes 9:00 AM
claude  # sesión nueva
Tú: "Ayer avancé en pagos: creé el modelo y el service. 
     Hoy implemento el controller y los tests."

Ventaja: Cada día arranca fresco. El resumen en el primer mensaje actúa como "standup para Claude".

Pattern 3: "Parallel Sessions"

Múltiples sesiones simultáneas para diferentes aspectos del proyecto.

# Terminal 1: Backend
claude
Tú: "Trabaja en los endpoints de la API..."

# Terminal 2: Frontend
claude
Tú: "Trabaja en los componentes React..."

# Terminal 3: DevOps
claude
Tú: "Configura el Dockerfile y el CI/CD..."

Ventaja: Cada sesión tiene contexto enfocado. No mezclas backend con frontend.

Con tmux:

# Crear sesiones tmux
tmux new-session -s backend -d
tmux new-session -s frontend -d
tmux new-session -s devops -d

# En cada ventana, ejecutar claude independientemente
# Cambiar entre sesiones: Ctrl+B, luego s para seleccionar

Cuándo usar: Proyectos grandes donde trabajas en múltiples áreas simultáneamente.

Pattern 4: "Explore then Execute"

Sesión exploratoria separada de la sesión de implementación.

# Sesión 1: Exploración (read-only, sin cambios)
claude
Tú: "Analiza cómo funciona el sistema de pagos actual. 
     No modifiques nada, solo explícame."
Claude: [analiza y explica]
Tú: "¿Dónde debería agregar el soporte para subscripciones?"
Claude: [sugiere ubicación y approach]
# Tomas notas de las conclusiones
# Ctrl+C

# Sesión 2: Implementación (con contexto limpio)
claude  # nueva sesión
Tú: "Necesito agregar soporte para subscripciones al sistema de pagos. 
     El módulo de pagos está en src/payments/. Quiero agregar un 
     subscription.service.ts que siga el mismo pattern que 
     payment.service.ts. Usa Stripe Subscriptions API."
# Implementas con contexto enfocado y clean

Ventaja: La exploración a veces genera mucho contexto (lee muchos archivos). Separar las sesiones evita que ese contexto "pesado" contamine la implementación.

Pattern 5: "Resume for Long Projects"

Para proyectos multi-día, usa --resume para volver a sesiones específicas.

# Lunes: Trabajaste en auth
claude  # sesión A
# ...

# Martes: Trabajaste en payments  
claude  # sesión B
# ...

# Miércoles: Necesitas volver a auth para un fix
claude --resume
# Seleccionas la sesión A de auth
# Claude tiene todo el contexto de auth del lunes

Escenarios Reales con Recomendaciones

Escenario 1: "Terminé una feature, necesito empezar otra"

Contexto: Acabas de terminar el sistema de autenticación. Commit hecho. Ahora necesitas implementar el dashboard.

Recomendación: Nueva sesión.

claude
Tú: "Necesito implementar el dashboard de admin. El backend tiene 
     los endpoints listos (GET /api/stats, GET /api/users). Crea 
     la página de dashboard en src/pages/dashboard/ con React."

El contexto de auth no aporta nada al dashboard.

Escenario 2: "Tests fallaron, necesito debuggear"

Contexto: Hace 10 minutos implementaste un endpoint. Ejecutaste tests y 3 fallan.

Recomendación: Continuar sesión.

claude --continue
Tú: "3 tests fallan. Aquí está el output: [pega output]. 
     Investiga y corrige."

Claude tiene el contexto de lo que implementó. Es mucho más eficiente que empezar de cero.

Escenario 3: "Volví de vacaciones y retomo el proyecto"

Contexto: Te fuiste una semana. Otros developers hicieron cambios. Quieres retomar tu trabajo.

Recomendación: Nueva sesión.

claude
Tú: "Acabo de hacer git pull. ¿Qué cambió en src/ desde mi 
     último commit [hash]? Resume los cambios relevantes."

Tu sesión anterior tiene una "foto vieja" del codebase. Mejor empezar fresco.

Escenario 4: "La conversación se fue por las ramas"

Contexto: Empezaste trabajando en un endpoint pero terminaste discutiendo arquitectura, después naming conventions, después herramientas de testing. Llevas 25 mensajes y no terminaste el endpoint.

Recomendación: Nueva sesión con resumen.

claude
Tú: "Estoy implementando GET /api/products/search. Decisiones ya 
     tomadas: usar ILIKE para búsqueda de texto, Zod para validación, 
     cursor-based pagination. Necesito terminar el service y los tests."

25 mensajes de divagación → 3 frases de contexto limpio.

Escenario 5: "Necesito trabajar en frontend Y backend simultáneamente"

Contexto: Estás implementando una feature que toca backend (API) y frontend (UI). Necesitas ir y volver entre ambos.

Recomendación: Dos sesiones paralelas.

# Terminal 1
claude
Tú: "Backend: crea endpoint POST /api/comments..."

# Terminal 2  
claude
Tú: "Frontend: crea componente CommentForm en React..."

Si usaras una sola sesión, el contexto de backend contaminaría las decisiones de frontend y viceversa.

Escenario 6: "Quiero probar un approach diferente"

Contexto: Llevas 10 mensajes intentando un approach para un problema. No funciona. Quieres probar algo completamente diferente.

Recomendación: Nueva sesión.

claude
Tú: "Necesito implementar rate limiting. Ya probé express-rate-limit 
     pero no funciona con nuestro setup de load balancer porque no 
     comparte estado entre instancias. Quiero intentar con Redis 
     como store centralizado."

El contexto del approach fallido solo te estorba. Pero la lección aprendida ("no funciona con load balancer") va en el primer mensaje.

Pitfalls y Edge Cases

Pitfall 1: Continuar por inercia

# Terminas una tarea. Sin pensar, haces:
claude --continue
Tú: "Ahora necesito trabajar en algo completamente diferente..."

# Claude arrastra todo el contexto de la tarea anterior.
# Desperdicio de contexto + posible contaminación.

# Solución: Pausa 2 segundos y pregúntate 
# "¿necesito el contexto anterior?" Si no → claude (nueva)

Pitfall 2: Empezar de cero sin transferir conocimiento

# Sesión anterior: descubriste un bug sutil en el ORM 
# que afecta todas las queries con JOIN.
# Empiezas sesión nueva sin mencionar ese bug.
# Claude vuelve a generar código con el mismo bug.

# Solución: 
# 1. Agregar a CLAUDE.md: "Bug conocido: el ORM genera JOINs 
#    incorrectos con tablas que tienen underscores. Usar raw SQL."
# 2. O mencionarlo en el primer mensaje de la nueva sesión.

Pitfall 3: Sesiones paralelas que se pisan

# Terminal 1: Claude modifica src/auth/login.ts
# Terminal 2: Claude también modifica src/auth/login.ts

# Resultado: conflictos, overwrites, bugs

# Solución: Las sesiones paralelas deben trabajar en 
# archivos/áreas diferentes del codebase

Pitfall 4: --continue después de mucho tiempo

# Sesión original: hace 3 días
# Desde entonces: 15 commits de otros developers
# Haces claude --continue

# Claude tiene un "mapa mental" de archivos que ya no existen 
# o cambiaron significativamente. Va a generar código basado 
# en una versión vieja del proyecto.

# Solución: Si pasaron más de unas horas y hubo cambios 
# significativos, nueva sesión.

Pitfall 5: Demasiadas sesiones paralelas

# Terminal 1: auth
# Terminal 2: payments
# Terminal 3: notifications
# Terminal 4: logging
# Terminal 5: tests
# Terminal 6: docs

# Problema: cada sesión consume API tokens. 
# Tu límite de tokens se agota 6x más rápido.
# Además, es difícil mantener coherencia entre tantas sesiones.

# Solución: máximo 2-3 sesiones paralelas. 
# Trabaja en serie para las demás.

Edge Case: Sesiones con estado compartido

# Sesión 1 crea una migración de base de datos
# Sesión 2 crea código que depende de esa migración

# ¿Sesión 2 sabe de la migración?
# → Solo si la migración ya se ejecutó (está en el schema)
# → O si se lo dices explícitamente

# Las sesiones no comparten contexto conversacional.
# Sí comparten el filesystem (mismos archivos en disco).

Ejemplo Completo Integrado

Escenario: Proyecto de 3 días con gestión de sesiones

# ═══════════════════════════════════════════════
# DÍA 1: Setup y modelo de datos
# ═══════════════════════════════════════════════

# ─── Sesión 1A: Diseño (9:00 AM) ───
claude
Tú: "Estoy empezando un proyecto de task management API. 
     Stack: Express, TypeScript, Prisma, PostgreSQL. 
     Diseña el modelo de datos: Users, Projects, Tasks, 
     Comments. Solo diseño, no implementes."

Claude: [diseña schema]
Tú: "Ajusta: Tasks necesita prioridad (enum), deadline, 
     y assignee (relación con User)."
Claude: [ajusta]
Tú: "Perfecto. Guarda las decisiones de diseño en CLAUDE.md."
Claude: [actualiza CLAUDE.md]
# Ctrl+C — sesión termina

# ─── Sesión 1B: Implementación de modelos (10:30 AM) ───
claude  # NUEVA sesión — el diseño está en CLAUDE.md
Tú: "Implementa el schema de Prisma basándote en las decisiones 
     de diseño en CLAUDE.md. Crea la migración inicial."

Claude: [implementa schema, crea migración]
# ... 6 mensajes de refinamiento ...
# git commit -m "feat: initial schema and migration"
# Ctrl+C

# ─── Sesión 1C: CRUD de Users (2:00 PM) ───
claude  # NUEVA sesión — nueva feature
Tú: "Implementa CRUD completo para Users: controller, service, 
     routes, validator. Sigue el pattern de la docs de CLAUDE.md."

# ... 8 mensajes ...
# git commit -m "feat: users CRUD"
# Ctrl+C


# ═══════════════════════════════════════════════
# DÍA 2: Features principales
# ═══════════════════════════════════════════════

# ─── Sesión 2A: CRUD de Projects y Tasks (9:00 AM) ───
claude  # NUEVA sesión
Tú: "Implementa CRUD para Projects y Tasks. Sigue el mismo 
     pattern que Users (ya implementado en src/modules/users/)."

# ... 12 mensajes, compaction a la mitad ...
# git commit -m "feat: projects and tasks CRUD"
# Ctrl+C

# ─── Sesión 2B: Bug fix (2:30 PM) ───
# Los tests de Projects fallan
claude
Tú: "Los tests de Projects fallan con este error: [error]. 
     El CRUD lo implementé hace un rato."

Claude: [investiga, encuentra bug]
Tú: "Corrígelo."
Claude: [fix]
# git commit -m "fix: project foreign key constraint"
# Ctrl+C

# ─── Sesión 2C: Comments (3:00 PM) ───
claude  # NUEVA sesión — nueva feature
Tú: "Implementa Comments con replies anidadas (parentId). 
     Pattern igual que los otros módulos."

# ... 8 mensajes ...
# git commit -m "feat: nested comments"
# Ctrl+C


# ═══════════════════════════════════════════════
# DÍA 3: Polish y deployment
# ═══════════════════════════════════════════════

# ─── Sesión 3A: Tests integration (9:00 AM) ───
claude
Tú: "Crea integration tests para toda la API. 
     Quiero tests que cubran el flujo completo: 
     crear user → crear project → crear task → agregar comment."

# ... 10 mensajes ...
# git commit -m "test: integration tests for full flow"

# ─── Sesión 3B: Deployment (2:00 PM) ───
# Paralelo en otra terminal
claude
Tú: "Crea un Dockerfile multi-stage y un docker-compose.yml 
     con la app y PostgreSQL."

# ... 6 mensajes ...
# git commit -m "chore: docker setup"

Total: 8 sesiones en 3 días. Cada una enfocada, con contexto limpio. CLAUDE.md como hilo conductor entre sesiones.

Ejercicios Prácticos

Ejercicio 1: Practicar la decisión continue vs nueva

Para cada escenario, decide: ¿claude --continue o claude (nueva)?

Acabas de crear un endpoint. Quieres agregar tests.
Acabas de crear un endpoint. Quieres crear otro endpoint completamente diferente.
Llevas 20 mensajes debuggeando. El bug sigue sin resolverse. Quieres probar otro approach.
Implementaste algo hace 5 minutos y un test falla.
Implementaste algo hace 3 días y un test falla.
Exploraste un codebase ajeno durante 15 mensajes. Ahora quieres empezar a implementar.

Respuestas

--continue — Los tests son un follow-up directo. Claude sabe qué implementó.
Nueva sesión — Diferente endpoint = diferente contexto. La sesión anterior no aporta.
Nueva sesión — 20 mensajes de intentos fallidos son ruido. Empieza limpio con las lecciones aprendidas.
--continue — Contexto fresco y 100% relevante.
Nueva sesión — Han pasado 3 días, el codebase probablemente cambió. El contexto está obsoleto.
Nueva sesión — La exploración generó mucho contexto (archivos leídos). Para implementar, quieres contexto limpio enfocado en la tarea específica. Pon las conclusiones de la exploración en tu primer mensaje.

Ejercicio 2: La heurística de las 2-3 frases

Piensa en tu última sesión de trabajo (real o hipotética). Intenta resumir lo que Claude necesitaría saber en 2-3 frases:

¿Lo lograste? → Podrías empezar sesión nueva con ese resumen
¿No lo lograste? → Probablemente deberías --continue

Practica con estos escenarios:

Sesión donde implementaste login con JWT
Sesión donde exploraste 10 archivos sin conclusión clara
Sesión donde debuggeaste un memory leak

Ejemplos de resúmenes

Login con JWT (fácil de resumir → nueva sesión viable): "Implementé login con JWT en src/auth/. Token se genera con jsonwebtoken, expira en 1h, refresh token en Redis con TTL de 7 días. Falta implementar el endpoint de refresh."

Exploración de 10 archivos (difícil de resumir → quizás --continue): Difícil porque la exploración fue no lineal. Podrías decir: "Exploré src/payments/ y descubrí que usa un pattern de event sourcing con EventStore en src/events/." Pero si hay más matices, --continue puede ser mejor.

Memory leak debugging (depende del progreso): Si encontraste la causa: "Memory leak causado por event listeners que no se remueven en el componente WebSocket. El listener se registra en onConnect pero no se limpia en onDisconnect. Archivo: src/ws/handler.ts línea 47." Si no la encontraste: Más difícil. --continue para mantener el hilo del debugging.

Ejercicio 3: Sesiones paralelas

Abre 2 terminales. En cada una, inicia Claude Code con una tarea diferente del mismo proyecto:

Terminal 1: Trabaja en el backend (un endpoint nuevo)
Terminal 2: Trabaja en documentación (README, API docs)

Observa:

¿Se interfieren? (no deberían si trabajan en archivos diferentes)
¿El contexto de una afecta a la otra? (no debería)
¿Qué pasa si ambas intentan modificar el mismo archivo?

Qué observar

Las sesiones son completamente independientes
Cada una tiene su propio contexto y su propia carga de CLAUDE.md
Si ambas modifican el mismo archivo, la segunda en guardar "gana" — la primera se sobreescribe
Para evitar conflictos: asigna áreas de archivos diferentes a cada sesión
Ambas sesiones consumen tokens de tu cuenta, así que el consumo se multiplica

Ejercicio 4: Transfer de conocimiento entre sesiones

Inicia una sesión. Pide a Claude que analice algún aspecto de tu proyecto
Claude descubre algo interesante (un pattern, una convención, un bug potencial)
Pide que lo guarde en CLAUDE.md
Cierra la sesión
Inicia una nueva sesión
Sin mencionar el hallazgo, pide a Claude que trabaje en algo relacionado
Verifica si Claude usa el conocimiento guardado en CLAUDE.md

Qué observar

Si lo guardaste correctamente en CLAUDE.md, Claude en la nueva sesión debería:

Conocer el hallazgo sin que se lo recuerdes
Aplicarlo automáticamente en su trabajo
Referirse a él si es relevante

Si NO se guardó en CLAUDE.md:

Claude no tiene idea del hallazgo
Podrías cometer los mismos errores que la sesión anterior descubrió

Este ejercicio demuestra por qué CLAUDE.md es el "puente" entre sesiones.

Ejercicio 5: Medir el impacto de contexto limpio

Realiza la misma tarea de dos formas:

Forma A: Después de una sesión larga (20+ mensajes con temas mezclados), pide la tarea.

Forma B: En una sesión nueva limpia, pide la misma tarea con un primer mensaje bien contextualizado.

Compara:

Velocidad de respuesta
Calidad del resultado
Necesidad de correcciones

Qué esperar

Generalmente, la Forma B produce:

Respuestas más rápidas (menos contexto que procesar)
Mayor calidad (sin ruido de conversaciones anteriores)
Menos correcciones necesarias

La Forma A puede funcionar bien si todo el contexto acumulado es relevante, pero eso es raro después de 20+ mensajes con temas mezclados.

Conclusión: No temas empezar sesiones nuevas. Con un buen CLAUDE.md y un primer mensaje bien escrito, el "costo" de empezar de cero es mínimo y el beneficio es significativo.

Resumen

Cada claude inicia una sesión nueva. claude --continue retoma la última. claude --resume elige una anterior.
Continúa cuando: mismo task, follow-up directo, debugging en progreso, contexto limpio y relevante.
Nueva sesión cuando: tema diferente, contexto contaminado, después de milestone, cambios externos, approach diferente.
Heurística de 2-3 frases: Si puedes resumir lo que Claude necesita saber en 2-3 frases, empieza de cero con ese resumen.
CLAUDE.md es el puente entre sesiones. Todo hallazgo importante debe persistirse ahí.
Clean slate advantage: Nueva sesión + CLAUDE.md bueno ≈ sesión continuada sin ruido.
Sesiones paralelas para áreas diferentes del proyecto (backend/frontend/devops). Máximo 2-3 simultáneas.
Session per feature es el pattern más seguro: feature completa → commit → nueva sesión.
Contexto contaminado (intentos fallidos, off-topic, datos obsoletos) reduce la calidad de las respuestas.
No continúes por inercia. Pausa 2 segundos y pregunta: "¿necesito el contexto anterior?"

Recursos Adicionales

Claude Code Interactive Mode — Anthropic Docs — Gestión de sesiones, shortcuts, y task management
Claude Code CLI Reference — Flags de sesión: --continue, --resume, --print
Claude Code Best Practices — Workflows recomendados y estrategias de context management
Claude Code Memory System — CLAUDE.md como contexto persistente entre sesiones
Claude Code Overview — Plataformas, capabilities, y modelo de sesiones
tmux Cheat Sheet — Referencia rápida para gestionar múltiples terminales con tmux

← AnteriorContext Window y Compaction: Gestionar la Memoria de Claude Code Siguiente →Módulo 5: Skills y Hooks — automatizar tu workflow