Qué es el context rot y cómo lo combate el SDD

Empiezas la sesión y todo va fino. El agente entiende el proyecto, propone un plan decente, toca los archivos correctos. Te frotas las manos.

Dos horas después es otro.

Repite enfoques que ya descartaste. Olvida una restricción que le diste al principio. Intenta arreglar el mismo bug con el mismo método que ya
falló tres veces. Le corriges y, lejos de mejorar, parece que va a peor.

No te has vuelto loco. Y, sorpresa, el modelo tampoco se ha vuelto tonto de golpe. Lo que ha pasado tiene nombre técnico: context rot. Y
entenderlo cambia bastante la forma de trabajar con agentes de código.

En este artículo vas a ver:

Qué es el context rot y por qué no es lo mismo que “el modelo olvida”
Las tres formas en que se manifiesta (y cuál te muerde más en el día a día)
Por qué meterle más contexto al agente suele empeorar las cosas
Cómo se relaciona con el Spec Driven Development y por qué la spec ayuda… pero también se pudre
Una rutina de higiene de contexto que puedes aplicar hoy mismo

Qué es el context rot ¶

El context rot es la degradación de la calidad de las respuestas de un modelo cuando trabaja con demasiado contexto, contexto mal elegido,
contexto contradictorio o contexto caducado.

Ojo a la trampa mental, porque es importante. La idea no es “el modelo pierde información”. Es peor: la información correcta puede estar dentro
de la ventana de contexto y aun así el modelo usarla mal, ignorarla o mezclarla con el ruido. Sigue ahí, visible, presente. Y el agente
igualmente decide mal.

Chroma publicó en julio de 2025 el informe que popularizó el término. Evaluaron 18 modelos punteros (GPT-4.1, Claude 4, Gemini 2.5, Qwen3 y
variantes) y su conclusión no fue el típico “fallan con mucho texto”, sino algo más incómodo: los modelos no usan su contexto de forma
uniforme. El token número 100.000 no se procesa con la misma fiabilidad que el número 100, ni siquiera en tareas simples (Hong, Troynikov,
Huber, “Context Rot”).

Si solo te llevas una frase de todo esto, que sea esta:

🔑 Más contexto no es mejor contexto. Contexto útil es contexto seleccionado, vigente y verificable.

Esto conecta con algo que Anthropic lleva tiempo defendiendo bajo la etiqueta de context engineering: el contexto es un recurso finito con
retornos decrecientes. No basta con escribir buenos prompts; hay que decidir qué tokens entran, cuándo entran y cuáles tienen que salir. Si
quieres ver dónde encaja esta pieza dentro del todo, lo desgrané al hablar de la arquitectura de agentes de IA para
programadores. Y si estás aterrizando en este mundo, en la guía para empezar a
programar con IA verás por qué el plan y la spec aparecen tan pronto en cualquier flujo sano.

👉 Vale, pero “degradación” es una palabra muy gorda para algo que se manifiesta de formas muy distintas.

Las tres caras del context rot ¶

No es un único problema. Son tres, y conviene distinguirlas porque se atacan de maneras diferentes.

Degradación por longitud ¶

Esta es la versión más “investigable”: cuanto más crece el input, más difícil le resulta al modelo encontrar y usar la información relevante.

Lo interesante del informe de Chroma es que no se quedó en el clásico “aguja en un pajar”. Añadieron ambigüedad y distractores, y ahí aparece la
parte que te toca como developer: cuando hay información parecida pero incorrecta, el modelo se engancha a la pieza equivocada. Un solo distractor
ya bajaba el rendimiento; varios lo hundían más.

Traduce esto a tu repositorio y verás que es tu pan de cada día:

“Usa este servicio” y “ya no usamos este servicio” conviviendo en la misma conversación.
Código viejo y código nuevo que se parecen como dos gotas de agua.
Tres intentos fallidos de arreglar un bug, todos pegados en el chat.
Documentación de una API antigua junto a la actual.
Un CLAUDE.md que dice una cosa y un código que hace otra.

El agente no “elige la verdad”. Elige el patrón más plausible dentro de una sopa demasiado densa. Como gran plan, regulinchi.

Contaminación de la sesión ¶

Esta es la que más vas a sufrir en Claude Code, Codex, Cursor u OpenCode.

El agente lee ficheros, ejecuta tests, falla, corrige, recibe tus mensajes, traga logs enormes… y a partir de cierto punto empieza a arrastrar
basura operacional. Drew Breunig puso nombre a los subtipos en un análisis que ya es referencia obligada:

Context poisoning: una alucinación o un error entra en el contexto y se reutiliza como si fuera verdad.
Context distraction: el contexto crece tanto que el modelo se obsesiona con el historial acumulado en lugar de pensar.
Context confusion: información irrelevante se cuela en la respuesta.
Context clash: dos partes del contexto se contradicen entre sí.

El caso del agente que jugaba a Pokémon con Gemini 2.5 lo ilustra bien: pasados los 100.000 tokens, empezó a repetir acciones de su propio
historial en vez de planear de nuevo (Breunig, “How Long Contexts
Fail”). Atención al detalle: el modelo no había llenado la
ventana. Estaba muy lejos del límite duro y ya rendía peor.

Esto explica algo que seguro has vivido: corregir al agente dentro de la misma conversación no siempre arregla nada. A veces lo empeora. Dejas el
error, el intento fallido, tu corrección y la nueva hipótesis flotando en el mismo caldo. Un manjar para un sistema que no tiene criterio humano,
solo atención estadística con corbata. No es casualidad que hayan nacido frameworks enteros, como GSD, diseñado para combatir el context
rot, que atacan justo esta contaminación.

Contexto persistente que se pudre ¶

Y aquí llega la cara más reciente, la que afecta a tus AGENTS.md, CLAUDE.md, .cursorrules, skills, hooks y demás parafernalia moderna.

Esos ficheros describen arquitectura, convenciones, comandos y rutas. Pero el software evoluciona y el fichero no siempre. Cuando dejan de
cuadrar, el agente trabaja desde una premisa falsa sin que salte ningún error visible:

“La autenticación vive en src/auth/middleware.py”, pero ya no.
“Usamos Redux”, pero migrasteis a Zustand hace dos sprints.
“Los tests se lanzan con npm test”, pero ahora es pnpm test:unit.
“No tocar esta carpeta”, una regla que era temporal y nadie borró.

Un trabajo aplicó el término context rot justo a estos artefactos de configuración. Usando una herramienta de consistencia documental sobre una
muestra de 356 repositorios, encontraron referencias obsoletas a elementos de código en el 23% de ellos (Just-In-Time Inconsistency Detection
/ context rot in AI configuration
artifacts). Casi
uno de cada cuatro.

⚠️ Un fichero de contexto caducado es peor que no tener fichero. El agente cree que sigue instrucciones del proyecto cuando en realidad obedece
a un fantasma de hace tres meses.

Si te pasa esto, el problema no es del agente. El estudio de la ETH de Zúrich sobre la eficacia real de estos ficheros apunta en la misma
dirección: un contexto mal dimensionado puede empeorar el rendimiento en vez de mejorarlo. Lo conté en detalle al analizar para qué sirve
AGENTS.md de verdad, y enlaza con un problema gemelo, el de los CLAUDE.md que crecen sin
control y te chupan tokens en cada prompt; ahí te dejo 25 técnicas para ahorrar tokens en Claude
Code.

Si te suena eso de la sesión que se contamina y el fichero de contexto que se pudre, es justo lo que compartimos cada domingo: cómo está cambiando trabajar con IA en el día a día. Ya somos +6.700 developers, gratis desde 2018.

Quiero esa dinamita 🧨

Cómo se manifiesta en agentes de código ¶

Si tuviera que listar los síntomas que más se repiten en foros y blogs de developers, serían estos cinco.

El agente vuelve a caminos descartados. Le dijiste “no uses X” y reaparece X. No es que ignore la orden: es que esa orden compite ahora con un
montón de ruido posterior.

Pierde el hilo después de compactar. La compactación ayuda, pero también puede borrar matices: decisiones condicionales, números exactos, por
qué se descartó un enfoque. Te quedas con el resumen general y pierdes el estado fino de la tarea.

Se aferra a errores previos. Dos intentos malos y luego tu corrección. Pero los dos intentos malos siguen ahí. La higiene es clara: si entra
basura en la sesión, mejor editar o resetear que corregir encima de la porquería.

Se intoxica con tool outputs gigantes. El resultado de una herramienta cuenta como contexto en los turnos siguientes, aunque sea
reconsultable. Un log de 2.000 líneas que leíste una vez se queda ocupando sitio y ensuciando el ambiente.

Y el más sutil de todos: el contexto está “presente”, pero no “operativo”. Que un archivo o una restricción esté dentro de la ventana no
significa que el modelo lo esté usando bien. Es el corazón de todo lo que estamos viendo.

Context rot no es lo mismo que lost in the middle ¶

Se parecen, pero no son lo mismo, y conviene no confundirlos.

El lost in the middle se refiere a que los modelos recuperan peor la información situada en ciertas posiciones del contexto, sobre todo en el
medio. Es un problema de dónde está el dato.

El context rot es más amplio. Incluye el lost in the middle, sí, pero también demasiados tokens, información parecida pero falsa, errores
previos en el historial, herramientas irrelevantes, instrucciones contradictorias, contexto caducado y compactaciones que pierden detalle. No
habla solo de dónde está la información, sino de la calidad completa del entorno en el que el agente piensa.

Por eso el context rot es el concepto más útil para programar con IA. El lost in the middle te dice “coloca lo importante al principio o al
final”. El context rot te obliga a una pregunta mucho mejor: ¿qué debería entrar en esta ventana y qué no?

La solución no es “más contexto” ¶

La reacción instintiva, cuando el agente falla, es darle más: todo el repo, toda la documentación, todo el historial, todos los tools. Y es justo
lo contrario de lo que toca.

LangChain agrupa las estrategias serias en cuatro familias fáciles de recordar: write, select, compress, isolate. Escribir información fuera
del contexto activo, seleccionar solo lo relevante, comprimir lo necesario y aislar tareas en contextos separados. Anthropic usa una división
parecida en su cookbook: compactar conversaciones largas, limpiar resultados de tools que se pueden volver a pedir y mover lo importante a memoria
externa.

Bajemos eso a tierra con cosas que puedes hacer mañana.

Trabaja por tareas pequeñas. Una regla que funciona: una tarea, un contexto de trabajo. Si una sesión empezó como debugging, no dejes que se
convierta en refactor, luego en rediseño y luego en actualizar la documentación. Termina, resume, y abre sesión nueva para lo siguiente. Buena
parte de lo que la gente atribuye al context rot viene de no empezar limpio para una tarea limpia.

Usa ficheros de handoff, no conversaciones eternas. Cuando una tarea avanza, guarda su estado en disco y arranca fresco:

# Handoff

## Objetivo actual
...

## Decisiones tomadas
...

## Enfoques descartados (y por qué)
...

## Archivos tocados
...

## Tests ejecutados
...

## Próximo paso
...

Después abres una sesión nueva y dices: “lee este handoff y continúa”. Mucho mejor que una conversación de 80 turnos con cinco cadáveres técnicos
enterrados a mitad del chat.

Trata tu AGENTS.md como un mapa, no como una enciclopedia. Reglas duraderas, comandos esenciales, rutas. No tutoriales eternos ni el
razonamiento histórico de por qué hace tres meses decidisteis algo que ya no aplica. Una regla mental que ayuda a clasificar:

Duradero → AGENTS.md, CLAUDE.md, reglas del proyecto.
Temporal → handoff de la tarea concreta.
Grande o consultable → fichero externo, docs, rutas, grep, tools.
Fallos descartados → resumidos como “descartado por X”, nunca pegados como novela rusa.

Prefiere referencias a volcados. El agente no necesita que le pegues el código; necesita saber dónde mirar. Compara estas dos instrucciones:

# Bien: una referencia que el agente resuelve por su cuenta
Lee src/modules/billing/subscription.ts y revisa cómo se valida el estado active.

# Mal: el volcado de turno
Te pego aquí 1.200 líneas por si acaso, campeón.

La primera deja que el agente lea solo lo que necesita. La segunda mete miles de tokens que se quedarán contaminando los turnos siguientes.

Delega lo exploratorio en subagentes. Si hace falta rastrear 30 archivos, leer logs o inspeccionar documentación, que lo haga un subagente en
su propio contexto y devuelva un resumen de 1.000 tokens en vez de los 40.000 que consumió investigando. Es la idea que sostiene frameworks como
GSD, pensado para combatir el context rot con contextos frescos: en vez de un orquestador gigante, cada
fase tiene el suyo y se mantiene por debajo del 50% de capacidad.

💡 El reparto que mejor funciona: un agente principal que mantiene el plan y las decisiones, un subagente que explora, otro que ejecuta tests,
otro que revisa el diff. Toda la basura de la exploración se queda fuera de la conversación principal.

Por una vez, el hype multiagente tiene una razón técnica debajo. No es que “multiagente” suene a futuro; es que aísla la mugre. Esa misma separación de contextos, llevada al extremo, es la que hizo posible reescribir Bun de Zig a Rust con 64 agentes en paralelo: quien revisaba el código no veía el razonamiento de quien lo escribió.

Trucos de higiene de contexto como estos —handoffs, subagentes, tareas pequeñas— son de los que seleccionamos entre 12 recursos cada semana. Únete a los +6.700 que reciben la newsletter cada domingo.

Quiero esa dinamita 🧨

Dónde encaja el Spec Driven Development ¶

Aquí viene la conexión que me parece más jugosa, porque toca de lleno el método del que más hablamos por aquí.

El Spec Driven Development (SDD) escribe primero una especificación —un documento que describe qué debe
hacer el software— y solo después deja que el agente genere el código. La spec manda. El código es el resultado, no la fuente de verdad.

Mira ahora lo que es una spec desde la óptica del context rot: es contexto persistente y estructurado que sobrevive a la sesión. Las
decisiones importantes no viven solo en el historial del chat, donde se diluyen turno a turno. Viven en un documento que el agente vuelve a leer
cuando lo necesita. Cuando empiezas una sesión nueva, no arrancas de cero ni dependes de que la compactación haya conservado lo bueno: tienes una
fuente de verdad fresca y de alta señal a mano.

Dicho de otro modo: el SDD ataca de raíz la contaminación de la sesión. No le pides al agente que recuerde por qué decidisteis usar bcrypt y no
argon2; lo lee en la spec. No reconstruye la lista de tareas desde una conversación de tres horas; la tiene escrita. Por eso las herramientas de
spec, OpenSpec entre ellas, encajan tan bien con sesiones largas y multifase.

Pero —y este “pero” es honesto— la spec también se pudre.

Es exactamente el tercer tipo de context rot que vimos antes. Una spec que describe un comportamiento que el código ya no tiene es un AGENTS.md
con peor disfraz: el agente la obedece creyendo que es la verdad del proyecto. Si tratas la spec como algo sagrado e intocable, además, vuelves al
waterfall de los noventa. Y si la dejas envejecer sin actualizarla, le has montado al agente el mismo trastero mental, solo que en formato
premium.

🛡️ El SDD no te inmuniza contra el context rot. Cambia dónde vive el riesgo: lo saca de la conversación efímera y lo mete en un artefacto
duradero. Ese artefacto, como cualquier documentación, hay que mantenerlo vivo.

La conclusión práctica no es “usa specs y olvídate”. Es: la spec es tu mejor herramienta contra la contaminación de la sesión, a condición de
que la revises cuando la realidad te obligue a cambiar el rumbo. Spec viva, no spec embalsamada.

Tu rutina de higiene de contexto, paso a paso ¶

Si quieres convertir todo esto en un hábito en vez de en teoría bonita, piénsalo como un pequeño sistema operativo para cada tarea:

Abre la tarea con un alcance claro y pequeño.
Carga solo lo necesario: la spec o el handoff, las rutas relevantes, nada de volcados.
Ejecuta el trabajo.
Verifica con tests; si exploras mucho, delega en un subagente.
Resume el estado en un handoff o actualiza la spec.
Limpia: compacta antes de que la sesión se ponga turbia, no después.
Continúa en fresco para la siguiente tarea.

No es prompt engineering. Es higiene de trabajo. Glamour cero, utilidad bastante alta. Y si quieres entrenar el músculo desde el principio, en la
guía de cómo empezar a programar con IA verás cómo el plan y la spec encajan en un flujo que
aún no arrastra los vicios de las sesiones maratonianas.

El cambio de mentalidad es el que de verdad importa. Antes pensábamos “necesito que la IA sepa más”. La pregunta correcta hoy es otra: ¿qué
necesita saber ahora mismo, qué puede consultar después, qué debe olvidar y qué tiene que quedar persistido como decisión?

Si tu agente se vuelve tonto tras dos horas, párate antes de echarle la culpa al modelo. Quizá no se volvió tonto. Quizá le montaste un trastero
mental y le pediste que encontrara una llave Allen concreta entre tres mudanzas, dos cadáveres de bugs y un CLAUDE.md escrito como si fuera el
Antiguo Testamento.

La buena noticia: el trastero lo ordenas tú. ¿Por dónde empiezas a tirar?

Preguntas frecuentes ¶

¿Qué es el context rot en pocas palabras? ¶

Es la degradación de la calidad de las respuestas de un modelo cuando su contexto se llena de demasiados tokens, ruido, errores previos,
información contradictoria o documentación caducada. Lo clave es que la información correcta puede seguir dentro de la ventana y el modelo usarla
mal igualmente.

¿El context rot es lo mismo que quedarse sin ventana de contexto? ¶

No. El límite duro de la ventana es un tope de capacidad; el context rot empieza mucho antes de llegar a él. El rendimiento puede caer con la
ventana medio vacía porque el problema es de acumulación de ruido y dilución de la atención, no solo de espacio.

¿Por qué mi agente de IA empeora en sesiones largas? ¶

Porque la sesión va acumulando ficheros leídos, salidas de herramientas, intentos fallidos y correcciones que compiten con tus instrucciones
originales. Esa contaminación hace que el modelo se distraiga con el historial y repita caminos descartados, aunque no haya llegado al límite de
tokens.

¿Context rot es lo mismo que lost in the middle? ¶

No, aunque están relacionados. Lost in the middle describe que los modelos recuperan peor la información situada en el medio del contexto. Context
rot es más amplio e incluye también exceso de tokens, distractores, contradicciones y contexto obsoleto.

¿Cómo evito el context rot en Claude Code o Codex? ¶

Trabaja por tareas pequeñas con sesiones nuevas, usa ficheros de handoff para mover el estado entre sesiones, mantén tu AGENTS.md o CLAUDE.md
corto y vigente, prefiere referencias a rutas en lugar de pegar código, y delega la exploración en subagentes para no contaminar la conversación
principal.

¿Compactar la conversación soluciona el context rot? ¶

Ayuda, pero no es magia. La compactación libera espacio resumiendo el historial, aunque puede perder matices importantes como decisiones
condicionales o números exactos. Funciona mejor como punto de control planificado que como parche de último momento.

¿El Spec Driven Development elimina el context rot? ¶

No lo elimina, lo desplaza. La spec saca las decisiones de la conversación efímera y las guarda en un artefacto duradero, lo que ataca la
contaminación de la sesión. Pero la propia spec puede quedar obsoleta respecto al código, así que hay que mantenerla viva.

¿Un AGENTS.md largo y detallado ayuda al agente? ¶

No siempre. Un fichero mal dimensionado puede empeorar el rendimiento y, si describe código que ya no existe, hace que el agente obedezca
instrucciones falsas. Conviene que contenga reglas duraderas, comandos esenciales y rutas, no tutoriales ni razonamientos históricos.

¿Por qué meterle más documentación al agente no lo hace más listo? ¶

Porque el contexto es un recurso finito con retornos decrecientes: a más tokens, peor precisión para recuperar y razonar sobre detalles concretos.
Volcar documentación de más añade ruido y distractores que compiten con la información que de verdad importa.

¿Sirven los subagentes para reducir el context rot? ¶

Sí. Cada subagente trabaja en su propio contexto, consume tokens explorando y devuelve solo un resumen condensado. Así la basura operacional de la
búsqueda no acaba contaminando la conversación del agente principal.

Fuentes ¶

🧨 Última oprtunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter