Cómo aplicar la regla del 60% en la gestión de contexto para LLMs

Gestión de contexto: la regla del 60% para sesiones en Claude Code

Tiempo estimado de lectura: 5 min

• Regla operativa: nunca dejes que una sesión consuma más del 60% de la ventana de contexto sin persistir el estado y limpiar la memoria.
• Patrón de trabajo: dividir tareas en Research → Plan → Implement → Validate, con artefactos en disco y limpieza de contexto entre fases.
• Artefactos clave: /CLAUDE.md, /RESEARCH.md, /PLAN.md, /TASK_STATE.md, /VALIDATION_REPORT.md y commits atómicos por módulo.
• Señales y métricas: observar contradicciones, repeticiones de contexto y fallos por “olvidos”; medir % de tareas con rework y tiempo de retoma.

Introducción

La frase “gestión de contexto: la regla del 60%” no es un eslogan. Es la regla operativa que evita que sesiones largas con agentes como Claude Code produzcan código coherente hoy y deuda técnica mañana. Si trabajas con LLMs en ingeniería, aplica esto desde el primer día: nunca dejes que una sesión consuma más del 60% de la ventana de contexto sin persistir el estado y limpiar la memoria.

Resumen rápido (lectores con prisa)

La regla del 60% limita cuánto de la ventana de contexto puede usar una sesión antes de persistir el estado. Úsala para fragmentar trabajo en sesiones controladas y guardar artefactos versionados (archivos en el repo). Aplica especialmente con agentes que leen/escriben repositorios como Claude Code.

Qué significa “Gestión de contexto: la regla del 60%” y por qué importa

Los modelos de lenguaje tienen una ventana finita de tokens. Cuando esa ventana se aproxima a su límite —y en la práctica cuando supera el 60%— el modelo comienza a priorizar lo más reciente. Eso no produce errores ruidosos: produce decisiones de diseño que olvidan criterios definidos al inicio, bugs detectados temprano y validaciones que ya no se tienen en cuenta.

La regla del 60% obliga a fragmentar el trabajo en sesiones controladas y a externalizar el estado en artefactos versionados (archivos en el repo). Con Claude Code esto es práctico y repetible porque el agente puede leer/escribir el repositorio: https://docs.anthropic.com/en/docs/agents-and-tools/claude-code/overview y https://www.anthropic.com/claude.

El patrón operativo: 4 fases limpias por sesión

Divide cualquier tarea compleja en cuatro fases: Research → Plan → Implement → Validate. Cada fase debe terminar con un artefacto en disco y una limpieza explícita del contexto antes de pasar a la siguiente.

1) Research — auditoría

– Objetivo: mapear dependencias, puntos de dolor y deuda técnica sin cambiar nada.

– Salida: RESEARCH.md con módulos auditados, preguntas abiertas y riesgos priorizados.

– Acción: cerrar sesión. No cargar más archivos que los estrictamente necesarios.

2) Plan — diseño acotado

– Objetivo: con RESEARCH.md + CLAUDE.md (contrato del proyecto) definir módulos, orden y criterios de aceptación.

– Salida: PLAN.md con tareas atómicas y criterios verificables.

– Acción: validar el plan con un humano; cerrar sesión.

3) Implement — sesiones por módulo

– Objetivo: una sesión por módulo. Cargar solo PLAN.md, CLAUDE.md y archivos del módulo.

– Salida por módulo: commit atómico + actualización de TASK_STATE.md (estado por módulo) y tests unitarios.

– Acción: limpiar contexto entre módulos (reiniciar sesión o instanciar subagente nuevo).

4) Validate — verificación objetiva

– Objetivo: sesión en blanco que lea PLAN.md y ejecute validaciones (tests unitarios, integración, contratos).

– Salida: VALIDATION_REPORT.md con pass/fail y pasos de corrección.

– Acción: abrir PR / merge si pasa; en caso contrario, agregar tareas correctivas al plan y repetir ciclo.

Ejemplo práctico (prompt y artefactos)

Estructura de archivos mínima:

/CLAUDE.md
/RESEARCH.md
/PLAN.md
/TASK_STATE.md
/VALIDATION_REPORT.md
/tasks/auth-migration.md

Prompt de recuperación inicial (Research → Plan):

Lee /RESEARCH.md y /CLAUDE.md. Propón un PLAN.md que divida la migración de Auth en módulos atómicos,
cada uno con criterios de aceptación y tests mínimos. No implementes código.
Guarda PLAN.md y termina la sesión.

Prompt para Implement (módulo user-service):

Lee PLAN.md y CLAUDE.md. Trabaja únicamente en src/services/user-service.* según el criterio de la tarea "UserService".
Agrega tests unitarios que validen los criterios. Actualiza TASK_STATE.md antes de hacer commit.
No toques otros módulos.

Regla inquebrantable: actualizar TASK_STATE.md y hacer commit antes de terminar la sesión.

Señales de que estás cruzando el 60% (y qué hacer)

– Necesitas repetir contextos largos en prompts para que el agente recuerde una regla inicial.

– El agente empieza a contradecir decisiones anteriores sin justificación.

– Validaciones fallan por “olvidos” de requisitos que estaban en el RESEARCH.md.

Si ves cualquiera de estas señales: persiste el estado en disco, cierra la sesión y reinicia con el artefacto correspondiente.

Ventajas prácticas y métricas que importan

Aplicar la regla del 60% reduce ruido y mejora trazabilidad:

• Menos reverts por decisiones olvidadas.
• Mayor porcentaje de tasks que pasan CI en el primer commit.
• Tiempo de retoma por sesión < 5 minutos (leer artefacto) en vez de re-auditar todo.

Mide: % de tareas con rework, número de bugs registrados en TASK_STATE.md, tiempo desde apertura de sesión hasta reanudación efectiva.

Límites y advertencias

Esto no sustituye especificaciones claras ni revisiones humanas. Si la planifica es ambigua, la IA persistirá ambigüedades más rápido. El patrón reduce riesgos operativos, no el riesgo conceptual de malas decisiones de diseño. Además, no necesitas este overhead para fixes rápidos o scripts aislados: aplica la regla cuando el alcance y la duración lo justifiquen.

La regla del 60% es una disciplina: no es bonita, pero evita que la IA genere parches brillantes que fallan en integración. Si automatizas en serio, diseña tu flujo con RESEARCH.md, PLAN.md, TASK_STATE.md y VALIDATION_REPORT.md, obliga a commits atómicos y reinicia sesiones a tiempo. Con eso, la memoria del modelo deja de ser un talón de Aquiles y se convierte en parte auditable de tu pipeline.

Continuación práctica y recursos: Dominicode Labs

FAQ