La mayoría de usuarios no sabe que corregir a Claude dentro de la misma sesión empeora los resultados en lugar de mejorarlos. Esta guía explica el mecanismo de contaminación de contexto y un sistema de trabajo concreto para sacarle el máximo a cada sesión. Esencial para cualquiera que use Claude Code de forma diaria.
Hay un patrón que repiten casi todos los usuarios nuevos de Claude: hacen una petición, el resultado no está bien, corrigen, vuelve a fallar, corrigen de nuevo, y así entran en un ciclo donde cada iteración produce resultados peores que la anterior. No es un bug. Es consecuencia directa de cómo funciona la ventana de contexto.
Claude no tiene "memoria" en el sentido tradicional. Cada respuesta que genera toma en cuenta todo lo que está en la conversación activa: instrucciones originales, respuestas previas, correcciones, errores reconocidos. A medida que eso se acumula, Claude tiene que reconciliar información conflictiva en lugar de seguir instrucciones limpias. El rendimiento baja no porque Claude "se canse", sino porque el ruido supera a la señal.
La analogía correcta: si le pides a alguien que dibuje un gato en una hoja, luego le dices que borre y lo rehaga sin cambiar la hoja, el resultado es una maraña de líneas. La solución no es dar mejores instrucciones de corrección — es dar una hoja limpia.
Regla práctica: máximo dos correcciones por tema dentro de una misma sesión. Después de dos intentos fallidos, el contexto ya está suficientemente contaminado como para que más correcciones generen rendimientos decrecientes.
El flujo correcto es:
La tentación es seguir intentando dentro de la misma sesión porque "ya está casi bien". Esa intuición es incorrecta: cada corrección adicional añade capa sobre capa de información contradictoria.
Claude Code tiene comandos específicos para manejar el contexto:
| Comando | Efecto |
|---|---|
/clear |
Elimina toda la conversación. Pizarrón en blanco. |
Esc |
Interrumpe a Claude mid-respuesta para redirigirlo. |
Esc + Esc o /rewind |
Vuelve a un punto anterior de la conversación. |
/compact |
Comprime la conversación preservando la información esencial. |
Cuándo usar cada uno:
/clear: cuando cambias de tarea o después de dos correcciones fallidas en la misma dirección/rewind: cuando Claude tomó un camino equivocado pero el inicio del hilo era válido/compact: cuando la sesión es larga y productiva pero empieza a degradarse — conserva el contexto útil sin el ruido acumuladoEsc: cuando ves que Claude está generando algo claramente incorrecto y no tiene sentido dejarlo terminarLo crítico: limpiar el contexto no sirve si repites el mismo prompt. Después de /clear, reescribe la instrucción incorporando todo lo que aprendiste de los intentos anteriores.
El valor real de las sesiones fallidas no es el output — es el aprendizaje sobre qué information le faltaba al prompt original. Cada intento fallido te dice algo sobre qué asumiste que Claude sabía y no sabía.
Transformaciones concretas:
Prompt vago → Prompt específico para código:
"Hazme una página web""Crea una landing page en Next.js con Tailwind CSS. Incluye: hero section con headline y CTA, 3 features con íconos SVG, footer con links a redes. Colores oscuros (#111 fondo, #f5f5f5 texto), tipografía Inter. Sin librerías adicionales."Prompt vago → Prompt específico para bugs:
"Arregla el bug"Prompt vago → Prompt específico para tests:
"Agrega tests"Checklist antes de enviar cualquier prompt importante:
Estas no son sugerencias de estilo — son mecanismos que cambian cómo Claude procesa las instrucciones:
1. Dale forma de verificar su trabajo Si el prompt no incluye cómo Claude puede saber que lo hizo bien, Claude infiere criterios de éxito que pueden no coincidir con los tuyos. Proporciona tests, screenshots, outputs esperados o criterios explícitos de aceptación. Claude intentará autoverificarse con lo que tenga.
2. Explorar primero, ejecutar después Para tareas complejas o ambiguas: pídele primero que explore el problema y planifique, y solo cuando el plan te parezca correcto, dale luz verde para ejecutar. Especialmente útil en Plan Mode. Corregir un plan cuesta mucho menos que corregir código ya escrito.
3. Especificidad técnica, no intención "Hazlo más rápido" es una intención. "Reemplaza el loop forEach por un reduce y mueve la llamada a la API fuera del loop" es una instrucción técnica. Claude ejecuta mejor instrucciones técnicas que objetivos de alto nivel sin detalles de implementación.
4. Separar tareas con /clear
Si pasas de depurar un bug a diseñar una feature nueva en la misma sesión, el contexto del bug contamina las decisiones de diseño. Cada tarea sustancialmente diferente merece su propio contexto limpio.
5. Subagentes para investigación a escala Cuando el problema requiere investigar múltiples áreas simultáneamente, los subagentes mantienen contextos separados. Esto evita que la información de una investigación interfiera con otra. Claude Code puede coordinar subagentes para tareas de investigación paralela.
6. Definir el rol explícitamente No es lo mismo "ayúdame con esto" que "actúa como senior engineer con experiencia en sistemas distribuidos, el proyecto tiene estas restricciones técnicas". El rol define el marco desde el que Claude interpreta las instrucciones ambiguas.
7. Ejemplos sobre descripciones largas Tres ejemplos concretos del output que quieres superan a dos párrafos explicando el output. Claude aprecia la demostración sobre la descripción, especialmente para formato, tono y estructura.
8. CLAUDE.md como contexto persistente
Ejecutar /init en un proyecto genera un archivo CLAUDE.md que Claude lee automáticamente en cada sesión. Ahí va todo lo que no quieres repetir en cada prompt: stack técnico, convenciones del codebase, restricciones del proyecto, instrucciones de formato. Una vez configurado, ese contexto existe sin ocupar espacio en la conversación activa.
Claude funciona mejor con instrucciones limpias que con correcciones acumuladas. Eso implica dos hábitos concretos: invertir tiempo en escribir buenos prompts antes de enviar (no después de que falla), y tener la disciplina de limpiar contexto cuando la sesión se degrada en lugar de seguir empujando.
Un prompt bien construido en una sesión limpia siempre supera un prompt mediocre con diez correcciones encima.