La regla del 40 % de contexto: dónde vive la inteligencia de un LLM

Hay un momento en toda sesión larga de AI coding en el que el modelo parece cambiar de personalidad. Las primeras dos horas todo fluye: el agente entiende el problema, propone una arquitectura razonable y escribe código que revisarías dos veces. Pero en algún punto, casi siempre después de iterar mucho sobre el mismo ticket, las respuestas se vuelven sospechosamente genéricas: repite soluciones que ya descartamos, ignora instrucciones que le dimos hace tres mensajes y propone cambios que un revisor atento tacharía en rojo.

Lo más desconcertante es que nada cambió. Es el mismo modelo, la misma configuración, el mismo prompt de sistema. Lo único que creció es lo que llevamos colgado en la conversación: cada mensaje, cada archivo leído, cada error corregido sigue ahí, pesando.

La intuición natural es culpar al modelo, o a la tarea, o a nosotros. La explicación real es otra, y toca algo que casi nadie mide cuando diseña tareas para agentes: cuánto contexto cargamos en cada sesión.

Voy a defender que el límite real de un LLM no es su ventana de contexto, sino su zona de confort: alrededor del 40 % de la ventana, o de los 100 mil tokens, lo que ocurra primero. Y que diseñar tareas respetando esa zona es la diferencia entre un equipo que usa la IA como multiplicador y uno que la convierte en una fábrica de deuda técnica.

Para que esa tesis sea accionable, conviene aclarar qué entendemos por contexto. En un LLM, el contexto es toda la información que el modelo recibe en una conversación, además de sus pesos (los parámetros que aprendió en su entrenamiento): el prompt de sistema, los mensajes previos, los archivos que le adjuntamos, la salida de las herramientas que ejecuta y los resultados de búsqueda. Ese conjunto vive dentro de la ventana de contexto, la memoria de trabajo del modelo: el texto que puede consultar al generar cada respuesta. Se mide en tokens, fragmentos de texto de unos pocos caracteres. Y es un recurso finito: cada token que entra compite con los demás por la atención del modelo — la competencia que explica esta tesis.

La degradación empieza mucho antes de llenar la ventana

El fenómeno no es nuevo ni anecdótico: los modelos degradan su rendimiento mucho antes de saturar la ventana de contexto, y hay un marcador empírico que se repite. Dex Hardy, fundador de HumanLayer, lo resumió así cuando empezó a observar sus sesiones de trabajo con agentes:

“By around 40% or around 100K is my new marker… it doesn’t matter whether you’re using 1 million context window or 200K, it’s always going to be about this. It starts to just get dumber.”

En criollo: pasados los ~40 % de la ventana, o los ~100 mil tokens, el modelo “se empieza a poner más tonto”, sin importar si la ventana promete 200 mil o un millón. Matt Pocock lo adoptó como heurística central para diseñar tareas de AI coding y lo convirtió en parte de su sistema de skills: una sesión de trabajo tiene una smart zone donde el modelo rinde bien, y el resto es territorio donde el rendimiento se degrada.

Lo he visto una y otra vez en mi propio flujo de trabajo. La calidad no cae de golpe ni al final: cae de forma gradual, casi imperceptible, y para cuando te das cuenta estás peleando contra un modelo que ya no está pensando con el contexto que le diste, sino reaccionando al ruido acumulado. La ventana de contexto es un límite teórico; la degradación práctica llega mucho antes.

Por qué el número es casi fijo aunque la ventana crezca

Que el marcador se mantenga alrededor de los 100 mil tokens, incluso cuando los fabricantes amplían las ventanas a un millón, no es casualidad. Hay dos razones de fondo.

La primera es el costo de la atención. La atención de un transformer escala de forma cuadrática con la cantidad de tokens: cada token nuevo se relaciona con todos los anteriores. Dex Hardy lo explica con una metáfora futbolera que vale la pena robar:

“Cada token que agregas a un LLM es como agregar un equipo a una liga de fútbol: la cantidad de partidos crece cuadráticamente.”

Cuanto más contexto, más “partidos” tiene que disputar el modelo por cada token, y su atención se diluye. La segunda razón es que los modelos se entrenan con secuencias relativamente cortas: su zona de confort está muy por debajo del máximo que admiten en inferencia. Es como un corredor que entrena en pistas de 400 metros: puede correr una maratón, pero su mejor rendimiento está en distancias cortas.

Anthropic documenta el mismo fenómeno con otro nombre en su guía de context engineering: context rot, la capacidad del modelo de recuperar información del contexto disminuye a medida que crecen los tokens, y el attention budget, un presupuesto finito de atención que cada token nuevo consume. La evidencia experimental acompaña: el estudio Lost in the Middle mostró que los modelos usan de forma menos confiable la información del medio del contexto, y las ventanas de contexto por modelo documentan límites que casi nunca conviene rozar.

La conclusión incómoda es que ampliar la ventana no amplía la zona donde el modelo piensa bien: solo agrega más territorio donde puede degradarse. Las ventanas de un millón de tokens son útiles para recuperar información (encontrar un dato en un libro enorme), no para razonar apoyándose en todo lo que contienen.

Las dos zonas: smart zone y dumb zone

Con esto sobre la mesa, podemos nombrar las dos regiones de una sesión:

¿Cuándo estás en la dumb zone sin darte cuenta? Estas son las señales que he aprendido a buscar:

• El modelo repite soluciones que ya descartaste en la conversación.
• Ignora instrucciones que le diste hace algunos mensajes.
• El código que produce empeora de forma gradual, no de golpe.
• Aparecen alucinaciones poco comunes: APIs que no existen, archivos que inventa.
• La sesión supera los ~100 mil tokens y sigues pidiéndole tareas que requieren “inteligencia”.

Dos aclaraciones honestas. Primero, el número exacto varía por modelo y por tarea: Matt Pocock usa ~120-140 mil tokens como su umbral personal para tareas que exigen razonamiento. Segundo, la medición precisa en producción sigue siendo un problema abierto: el proxy más práctico que conozco es contar los tokens de la sesión y tratar el presupuesto como un recurso de diseño, no como un accidente.

Compactar o traspasar: las dos salidas del dumb zone

Cuando la ventana se acerca al límite, hay dos estrategias principales para volver a la smart zone, y la diferencia entre ellas es más importante de lo que parece.

Compact es la función integrada en arneses como Claude Code: resume la conversación dentro de la misma sesión. Sirve para seguir en la misma tarea, pero acumula lo que Matt Pocock llama “sedimento”: resúmenes cada vez más difusos que diluyen la calidad de lo que viene después. Además, el resumen queda atrapado en la sesión: no es portable entre agentes ni sirve para forkear.

Handoff es el movimiento inverso: comprimir la sesión actual en un markdown que otra sesión lee para continuar. Permite forkear a otro track (un prototype separado del grill, un sub-agente, mantener la sesión principal pura). Es throwaway: no acumula sedimento, porque la sesión nueva arranca limpia. Matt lo implementó como skill en su repositorio de skills.

El caso típico en mi día a día es el “handoff sandwich”: la sesión de prototype suele exceder la smart zone (Matt reporta sesiones de ~169 mil tokens). Sin handoff, el prototype se come la sesión principal. Con el sándwich, la sesión A (el grill donde se define el problema) hace handoff a la sesión B (el prototype), y B devuelve un resumen a A. Cada sesión conserva su smart zone intacta y ninguna carga con el sedimento de la otra.

Que el sedimento no sea solo una intuición lo respalda la evidencia reciente: comprimir el contexto pierde fidelidad. El framework ACE, de context engineering agentica, describe el mismo fenómeno como context collapse: la reescritura iterativa erosiona los detalles con el tiempo. Y un paper de Xiaohongshu midió que los resúmenes “preservan el estado narrativo pero esconden la evidencia exacta, los localizadores y los artefactos editables”. Resumir a ciegas, entonces, no es gratis: se paga con información que ya no está cuando la necesitas.

Qué hacer el lunes: una tarea, un ticket, un smart zone

Traducido a decisiones concretas, esto da una regla de diseño que cualquier equipo puede adoptar sin cambiar de herramienta:

Una tarea = un ticket = un smart zone. Presupuesta ~100 mil tokens por tarea. Si una tarea requiere más, no es una tarea: es un proyecto, y debe partirse.

Y un checklist de cinco preguntas para detectar que estás en la dumb zone:

1. ¿La sesión supera los ~100 mil tokens y sigues pidiéndole razonamiento?
2. ¿El modelo repite soluciones que ya descartaste?
3. ¿Ignora instrucciones dadas hace más de algunos mensajes?
4. ¿El código que produce ha empeorado de forma gradual?
5. ¿Ves alucinaciones que antes no aparecían?

Si respondes sí a dos o más, detente. Decide si compactar (seguir en la misma tarea) o hacer handoff (cambiar de foco), según la tabla de la sección anterior. El costo de reiniciar una sesión es pequeño comparado con el costo de dejar que el modelo siga razonando con la mitad de su atención en el ruido.

Diseñar para la zona de confort

La próxima vez que un agente “se ponga tonto” a mitad de sesión, no asumas que el modelo empeoró. Asume que excediste su zona de confort, y que la corrección no es más contexto, sino mejor diseño de tareas. La ventana de contexto es un recurso finito con rendimientos marginales decrecientes; la disciplina de respetar su zona de confort es lo que separa a un equipo que usa la IA como multiplicador de capacidades de uno que la usa como generador de deuda técnica.

La regla del 40 % no es una ley física ni un número mágico: es una heurística de diseño, y como toda heurística, se valida en terreno. Esta semana, revisa cómo partes el trabajo que le das a tus agentes. Si una sola sesión concentra más de un smart zone, esa es la primera tarea que debes rediseñar. Si quieres que tu equipo aprenda a diseñar tareas para agentes con esta disciplina, en nuestro AI Engineering Training trabajamos exactamente estas habilidades con equipos completos.

Notas

• La metáfora de la liga de fútbol es de Dex Hardy, circulando en la comunidad de AI coding; la tomé prestada porque es la mejor explicación intuitiva del costo cuadrático de la atención que he encontrado.
• “Sedimento” es la metáfora de Matt Pocock para los resúmenes acumulados de compact: cada resumen es una pérdida de fidelidad que se hereda a la siguiente iteración.
• Dejo dos preguntas explícitamente abiertas, porque me parece más honesto que fingir certeza: si el 40 % es universal o varía por modelo, y cómo medir en producción el punto exacto donde termina la smart zone. El conteo de tokens de sesión es el mejor proxy que conozco hasta ahora.

Para este artículo me apoyé en

• PI Agent + Deepseek V4 Flash (para iterar sobre la estructura, la redacción y la revisión de este artículo)
• Mi Obsidian Vault (para recuperar notas previas de mi conocimiento: la tesis de Matt Pocock, codebase architecture y design concept)

Referencias

• HumanLayer — Dex Hardy, origen de la regla del 40 % / 100k tokens
• Matt Pocock — Full workflow for AI coding — video donde populariza la smart zone citando a Dex Hardy
• mattpocock/skills — skills de handoff, prototype, grill-me y TDD
• Effective context engineering for AI agents — Anthropic — context rot y attention budget
• Context windows — Anthropic docs — límites de ventana por modelo
• Lost in the Middle — Liu et al. — degradación con contexto largo
• Agentic Context Engineering — Zhang et al. — evidencia sobre pérdida de fidelidad al comprimir contexto
• Self-GC: Self-Governing Context for Long-Horizon LLM Agents — Xiaohongshu — medición empírica de lo que pierde el resumen

Acerca de nosotros

En 23people, somos un grupo de nerds a los que nos gusta lo que hacemos, así que podemos darnos estas licencias de referencias ñoñas. Si quieres conversar sobre diseño de tareas para agentes de IA o necesitas ayuda para que tu equipo use la IA como multiplicador (mira nuestro AI Engineering Training), escríbenos → https://23people.io