Context Window Management for AI Coding Agents

The context window is not free storage. It is working memory, and it degrades as you fill it. The single biggest lever on AI coding quality is not the model, it is what you put in front of the model and what you leave out. Feed it the three files that matter and it writes the right change. Dump the whole repo in and it drowns, averages across noise, and hands you something plausible and wrong.

Most people manage context by accident. They paste more when things go badly, which is exactly backward. When an agent is confused, the fix is usually less context, sharper, not more context, blurrier. Managing the window on purpose is a learnable skill, and it pays off on every single task.

Why more context makes results worse

A model attends across everything in the window. Every irrelevant file, every stale comment, every dead code path is a distraction competing for attention with the parts that matter. Past a point, adding context lowers signal instead of raising it. The agent starts pattern-matching on things you did not mean.

There is also a recency and position effect. Instructions buried in the middle of a huge dump get less weight than the same instructions in a tight window. So a bloated context does not just slow the agent, it can make it ignore the very constraint you cared about. The context-switching tax I pay as a solo operator has a machine equivalent: an overloaded window switches focus badly, same as an overloaded human.

What actually belongs in the window

Start with the task. A tight spec and acceptance criteria first, because those steer everything else. If you have not written those, do that before you touch context at all; planning first beats prompting faster every time.

Then the minimum code the agent must see to make the change: the file being edited, the interface it calls, the test file. Add the one or two conventions the change must respect. Stop there. Resist the urge to include a file "just in case." If it turns out the agent needs it, you will find out fast and add it then. Under-feeding is cheap to fix. Over-feeding is invisible until quality drops.

For anything larger than a single file, lean on retrieval instead of dumping. Let the tool pull the relevant slices on demand rather than pre-loading the world. This is why repo intelligence before you refactor matters: a system that understands the codebase can hand the agent the right slice without you curating it by hand.

Manage the window across a long task

Long tasks fill the window with their own history: old attempts, tool output, back-and-forth. That accumulated exhaust is as distracting as any irrelevant file. When a session goes long, the useful move is to compact. Summarize what has been decided, drop the transcript, and restart the agent with a clean window holding only the summary and the current state.

I treat this like clearing a workbench. You do not keep every offcut on the table while you work; you sweep. Same with context. The decisions matter. The path you took to reach them usually does not, and keeping it around just crowds the space the next step needs.

Watch for the signal that the window has gone stale: the agent starts repeating itself, reintroducing bugs you already fixed, or contradicting an earlier decision. That is not the model failing. That is the window telling you it is full of noise. Reset it.

Make context management a habit, not a rescue

The teams that get consistent output do not think about context only when things break. They structure work so the window stays clean by default: small tasks, tight specs, retrieval over dumping, regular compaction. It becomes invisible, the way good filing is invisible.

This is also why task size matters so much. A change scoped to touch two files needs a small window. A change scoped to touch twenty needs a huge one, and quality falls accordingly. Smaller tasks are not just easier to review, they are easier to feed. That connection between scope and context is one of the things a real build platform should handle for you; it is core to how we think about the workflow at Bootspring, and to why demo-to-shippable is the real gap that context discipline closes.

Manage the window like the scarce resource it is. Feed the agent what the task needs, sweep what it does not, and reset when the signal drops. Do that and the same model that gave you garbage yesterday gives you a clean diff today.