The argument surfaces every time a model ships with a longer context window. RAG is dead. Retrieval is unnecessary. Just stuff everything in.
The data disagrees.
A widely cited piece circulating this week made the case: across benchmarks and real-world applications, larger context windows do not consistently outperform well-designed retrieval systems. The headline was counterintuitive enough to drive clicks. The finding was not surprising to anyone who has spent real time building with these systems.
There is an important distinction getting lost here. Context window size is a hardware and architectural constraint. Context engineering is a practice. Conflating them is like assuming a bigger warehouse solves a supply chain problem. The warehouse is not the operation.
The Cost Problem Nobody Budgets For
Token pricing scales linearly. A context window loaded with 80,000 tokens of potentially relevant material costs the same on every query, regardless of how much of that material the model actually uses. At the prototype stage, this is invisible. In production, it compounds.
The more important failure mode is subtler. Attention is not uniform across a long context. Content in the middle of a dense window is reliably attended to less than content at the edges. This is documented, replicated, and has a name in the literature: "lost in the middle." It does not resolve when the window grows. A model working across 200K tokens has more middle to lose things in, not less.
More context is not always better context. A retrieval system surfacing the most relevant code chunks performs differently than a context window loaded with an entire repository. The model has to do more disambiguation work. Sometimes it handles that correctly. Often it does not, especially when relevant signal is buried in surrounding noise.
Where the Research Is Pointing
Two papers circulating this week are worth the attention.
CompactionRL proposes a reinforcement learning approach to context compaction for long-horizon agents. The premise: agents operating across extended task sequences accumulate context that becomes progressively less relevant. Rather than letting that pile up, the system learns to compress and compact, retaining signal and discarding noise. The researchers built this into the training loop because the problem is real and the naive solution, keep everything, does not work.
KVpop addresses key-value cache compression through predictive pruning. Same underlying finding: the information in a context window is not uniformly valuable, and treating it as though it is wastes compute and degrades quality.
These are not patches for inadequate context windows. They are evidence that researchers with access to large context windows found that raw capacity does not solve the management problem. The field is building context engineering infrastructure. Not waiting for bigger windows to make it unnecessary.
The Gap Practitioners Live In
Context engineering for developers remains largely manual and ad hoc. There is a version of this situation that comes up repeatedly: a team upgrades their model, expands their context window, reduces retrieval effort, and spends the following quarter debugging quality degradation that cannot be attributed to any single change.
Most teams approach the problem one of two ways. The first is to rely on retrieval entirely and trust that semantic search surfaces what the model needs. This works reasonably when codebases are small and queries are predictable. It breaks down as systems scale and use patterns diversify.
The second is to expand the context window and reduce retrieval precision. Stuff it in. This approach is expensive, degrades at scale, and trades precision for coverage in a way that rarely pays off as expected.
The space between those two is where most developer pain concentrates. Retrieval is not precise enough to be fully trusted. Context windows are not reliable enough to be fully exploited. Teams navigating this well are treating context as a managed resource, not a container to fill.
That means caring about what gets indexed, how it gets chunked, how queries get interpreted, and when embeddings go stale. For codebases specifically, it means accepting that domain-specific language does not map cleanly to generic embeddings trained on general text. Functions named after inside jokes from 2019. Variable names that reference systems nobody on the current team deployed. None of that surfaces correctly in a generic similarity search. For teams using code analysis MCP tools or building similar context pipelines, this is the layer where retrieval quality is actually determined. Not the window size.
The Pattern Repeats
Every time model capabilities expand, there is a wave of commentary claiming something else has been made obsolete. Sometimes that is correct. Often it is premature.
RAG is not dying because context windows grew. The research this week points the other direction: the more capable AI systems become at handling long contexts, the more carefully those contexts need to be managed. Long-horizon agents need compaction. Dense retrieval needs reranking. Codebase search needs domain calibration.
The engineers who treat context management as solved are the ones who hit the wall six months later when accuracy drops and nobody can explain why. Context window expansion is a capability increase. It is not a substitute for the work.
Most teams never draw that line.