# ¿Cómo evitar que una sesión larga de programación pierda el contexto? > Evita la pérdida de contexto trasladando los hechos duraderos fuera del chat a un registro compacto de tareas, decisiones, pruebas y puntos de control del repositorio. Antes de comprimir o cambiar de modelo, restaura el estado desde esos artefactos en vez de reproducir una conversación ilimitada. Las sesiones largas suelen fallar por deriva, no por amnesia repentina. El agente recuerda el objetivo general, pero pierde una pequeña restricción, confía en una prueba obsoleta, repite una investigación o edita siguiendo un plan que ya no coincide con el repositorio. La solución es un estado externo duradero, más corto y fiable que la conversación. Trata la conversación como memoria de trabajo y el repositorio como fuente de verdad. En cada punto de control significativo, anota qué cambió, qué está verificado, qué sigue siendo incierto y qué debe ocurrir después. ## Registra cuatro tipos de contexto Separa los hechos por función para que el resumen no se convierta en una historia indiferenciada. | Tipo de contexto | Ejemplos | Ubicación duradera | |---|---|---| | Objetivo | Resultado del usuario y criterios de aceptación | Registro de tareas | | Restricciones | Compatibilidad, seguridad, estilo y alcance | Registro de tareas | | Estado del repositorio | Archivos modificados y rama actual | Control de versiones | | Evidencia | Pruebas, logs, capturas y benchmarks | Registro de verificación | Añade los supuestos como quinta categoría solo si están claramente marcados. Cada supuesto debe incluir la acción más barata para confirmarlo o descartarlo. ## Mantén un registro compacto Un registro útil cabe en una pantalla. Actualízalo después de hitos, no después de cada mensaje. ```md Objective: Ship model-switch support without changing existing tool behavior. Constraints: * Preserve the public API. * No destructive migration. Current state: * Parser adapter added in src/stream.ts. * Unit tests pass; cancellation test still fails. Decisions: * Buffer tool arguments until the final event. Evidence: * npm test: 142 passed, 1 failed. Next action: Fix duplicate execution after stream cancellation. ``` Conserva rutas, comandos y nombres de fallos exactos. Evita escribir un diario de la conversación. ## Crea puntos de control sobre estados verificados Un punto de control debe seguir a un resultado que la próxima sesión pueda reproducir: un grupo de pruebas aprobado, un cambio pequeño confirmado, una respuesta API verificada o una decisión respaldada por un caso de prueba. Registra los archivos sin confirmar antes de cambiar de modelo o comprimir el contexto. No afirmes que una función sirve porque se escribió código; vincula la afirmación a una prueba, compilación o artefacto observable. | Afirmación | Evidencia necesaria | |---|---| | El parser admite dos llamadas | Caso con dos IDs correlacionados | | El reintento es seguro | Prueba de idempotencia ante desconexión | | El refactor conserva el comportamiento | Pasan suites antiguas y nuevas | | La interfaz es correcta | Inspección renderizada en tamaños objetivo | ## Recupera la fuente en vez de repetir el chat Cuando un detalle importa, vuelve a abrir el archivo, esquema o documento oficial actual. Un fragmento antiguo del chat puede describir código que ya cambió. Proporciona rutas y términos de búsqueda para inspeccionar el estado vigente. La recuperación debe ser estrecha: carga la interfaz, su implementación, la prueba que falla y el log relevante antes que todo el repositorio. Así queda espacio para razonar y se reducen distracciones. ## Comprime conservando decisiones y evidencia Una buena compresión elimina repeticiones, pero conserva restricciones, decisiones difíciles de revertir, alternativas descartadas y verificaciones. Debe diferenciar `verified`, `observed`, `assumed` y `pending`. No resumas un experimento fallido como diseño final. Guarda el motivo de rechazo cuando el mismo enfoque tentador pueda reaparecer. ## Limita la salida de herramientas Los logs largos y archivos generados consumen atención rápidamente. Pide rangos, conteos o líneas coincidentes; guarda la salida completa como artefacto y devuelve un resumen breve con su ruta. Aplica lo mismo a los fallos: conserva el primer stack útil, la aserción fallida y los datos del entorno, no cientos de marcos repetidos. ## Reanuda con un ritual determinista Después de una pausa, compresión o cambio de modelo: * Lee el objetivo y las restricciones. * Inspecciona el control de versiones y los cambios recientes. * Abre los archivos indicados en el estado actual. * Repite la última comprobación relevante. * Confirma que la siguiente acción registrada sigue siendo válida. Esta rutina detecta resúmenes obsoletos antes de que provoquen nuevas ediciones. ## Elige modelos sin depender de la memoria del chat Un gateway facilita el cambio, pero la responsabilidad del estado sigue siendo tuya. Atlas Cloud ofrece varios protocolos LLM desde una URL base; revisa la [matriz de protocolos](https://www.atlascloud.ai/docs/llm-protocols?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=prevent-long-coding-sessions-from-losing-context) y el [catálogo de modelos](https://www.atlascloud.ai/llm-models?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=prevent-long-coding-sessions-from-losing-context) antes de mover un agente activo. Entrega al modelo sustituto el registro, los archivos relevantes y un resultado de verificación reciente. No dependas de identificadores de estado específicos del proveedor sin confirmar el mismo protocolo y comportamiento. ## Conclusión Las sesiones largas conservan contexto cuando el estado duradero es compacto, verificable y fácil de recargar. Mantén un registro de una pantalla, crea puntos de control tras cambios comprobados, recupera la fuente actual en vez de repetir el chat, limita la salida de herramientas y utiliza una rutina de reanudación determinista. Una ventana mayor ayuda, pero el estado externo disciplinado hace que el trabajo sea recuperable. ## FAQ ### ¿Basta una ventana de contexto mayor para una sesión larga? No. Más espacio retrasa la presión, pero no garantiza que las restricciones antiguas sigan visibles ni que se corrijan observaciones obsoletas. ### ¿Qué debe contener el registro de una sesión de programación? El objetivo, las restricciones, el plan actual, los archivos modificados, las decisiones clave, los resultados de verificación, los riesgos abiertos y la siguiente acción exacta. ### ¿Con qué frecuencia debe crear un punto de control el agente? Después de un cambio de estado significativo, como una prueba aprobada, una etapa de migración terminada, una decisión de diseño o un hallazgo que modifique el plan. ### ¿Debo pegar toda la conversación en un modelo nuevo? Normalmente no. Entrega un punto de control curado, los archivos y registros relevantes, y deja que el nuevo modelo inspeccione el estado actual del repositorio. ### ¿Cómo impido que un resumen conserve un error antiguo? Separa hechos verificados de supuestos, adjunta pruebas como comandos o rutas y retira cualquier afirmación que contradigan las pruebas nuevas. ### ¿Cuál es la forma más segura de reanudar tras una interrupción? Recarga el registro, inspecciona el estado del control de versiones, repite la última verificación relevante y comienza por la siguiente acción registrada.