Against the mega context window

The pitch is genuinely seductive, and it gets made in every planning meeting where someone is tired of arguing about acceptance criteria. The window is enormous now. Stop curating. Stop writing specs. Put the whole repository in and let the model sort it out.

I want to argue against that, and not on cost grounds, which is the argument everyone expects and the weakest one available. My position is this: a bigger window solves an access problem most teams did not have, leaves the intent problem entirely untouched, and quietly removes the only pressure that was making anybody state their intent in the first place.

What the bigger window actually buys

Start by conceding the real gains, because they are real and the sceptical version of this article usually skips them.

Cross-file reasoning genuinely improves. A refactor that touches eleven files used to fail because the agent saw seven of them. Retrieval misses, where the relevant module simply never got selected, largely go away. The plumbing you had to build to chunk, rank and stitch context becomes unnecessary, and that plumbing was a real source of bugs that were miserable to diagnose because the failure looked like a reasoning failure.

If your agent has been producing confidently wrong changes because it could not see the interface it was calling, a bigger window fixes that. That is a legitimate category of failure and it is worth the money.

It is also a minority of what goes wrong.

The missing information was never in the repository

Here is the scenario I keep coming back to. A ticket says add retry handling to the payments callback. Every file in the repository is in the window. The agent writes an exponential backoff with jitter, five attempts, clean code, passing tests.

It is wrong, because two years ago the team discovered that the provider treats a retried callback as a distinct event and double-credits the account, and the rule since then has been that this specific path never retries, it dead-letters. That rule is not in the repository. It is in a post-incident review, in the memory of two people, and in a comment that was deleted during a tidy-up.

No window size recovers a fact that was never written down.

This is the shape of context blindness as it actually presents: output that is internally coherent, professionally structured, and incompatible with a decision the organisation made and did not record. Widening the aperture does not help, because the aperture was never the constraint.

More evidence is not the same as better evidence

There is a second effect, and it is the one that surprises teams.

A mature repository is not a consistent document. It contains three ways of doing authentication, two of which are live and one of which is a migration that stalled in 2024. It contains a helper that everybody agrees is the wrong abstraction and that forty call sites still use. It contains a directory nobody has opened in a year.

When you could only fit part of the repository in the window, somebody had to decide which part. That decision was annoying, and it was also doing real work: it was an act of selection that said this is the pattern we mean.

Put everything in, and the selection disappears. The agent now has to resolve a contradiction, and the tiebreaker available to it is prevalence. The pattern with forty call sites beats the pattern with three, every time, regardless of which one the team decided on last quarter. You have automated the propagation of your worst-established convention.

In the window, all at once:
auth/legacy_session.py     41 call sites, deprecated
auth/token_provider.py      3 call sites, the standard
docs/adr-014-tokens.md      “we are moving to tokens”
docs/adr-002-sessions.md    superseded, not marked so
Agent picks: legacy_session.
Reason: it is what the codebase does.

The pressure that goes away

This is the part I care about most, and it is not a technical argument.

Writing a criterion that a machine can check is unpleasant work. It forces someone to decide things they would rather leave open. The only reason organisations do it is that the alternative visibly fails.

A very large window removes the visible failure for a while. The agent produces something plausible from raw material alone, so the case for spending ten minutes on precision gets harder to make, so precision decays, so the failures that do arrive are subtler and arrive later, attached to changes nobody can reconstruct the intent of. You have not removed the cost of ambiguity. You have deferred it into a form that is much more expensive to pay.

The teams that get real value out of large windows are the ones that kept writing the specification and now feed it alongside everything else. Window size is an input channel. It is not a decision-making faculty, and it will never tell you what you wanted.

Where this breaks down

The bitter lesson has an excellent track record and I am on the wrong side of it. Repeatedly, over a decade, “throw more capacity at it and stop hand-engineering” has beaten careful structure. If the pattern holds, curated context becomes an artefact of a transitional period and this argument ages badly. I think intent is categorically different from information, but people have said that about other things and been wrong.

For a team with nothing written down, the window is the better investment. If your documentation is three years stale and your tickets say “fix the thing”, a large window plus the raw repository will outperform a specification programme that never finishes. Telling that team to curate first is advice they cannot act on. Breadth genuinely rescues them, and I would give them the same advice.

Cost keeps falling, so the economic half of the argument weakens every year. I have deliberately not leaned on token spend here, because that is the part of the case with a visible expiry date. If you are arguing against large windows on price, expect to lose that argument on a predictable schedule.

“Selection is the work” is a convenient position for someone who writes about specifications. Declare the interest: we sell tooling in this space, so discount accordingly. And sometimes the selection is simply wrong. A human deciding which twelve files matter can exclude the one that mattered, and the wide window would have caught it. That happens, and it is a real cost of curation that advocates tend to skip.

Some intent genuinely is recoverable from the repository. Git history, review comments and test names carry more of the reasoning than my framing admits. An agent with the full history and enough capacity can sometimes reconstruct why a path does not retry. Not reliably, not yet, but the gap is narrower than the clean version of my argument suggests.

The takeaway

A large context window is a good fix for a narrow problem: the agent could not see something that exists. It is not a fix for the problem that dominates real failures, which is that the thing it needed does not exist in written form anywhere, and that your repository is a record of history rather than a statement of intent.

Buy the bigger window. It is useful. Just do not let it become the reason nobody decides anything.

If you take one thing into next week: pick the last change an agent got confidently wrong, and ask whether the information it needed was in your repository at all. If it was not, no window would have saved you, and you now know exactly what to write down.