Playbook
Ask ten people how to get better output from a coding agent and nine will talk about the prompt — the wording, the role, the clever phrasing. They're optimizing the smallest lever. The thing that actually decides whether an agent succeeds is what's in its context window when it reads your request: which files, which docs, which prior decisions, which map of the codebase. Perfect wording over the wrong files loses to plain wording over the right ones, every single time. That's context engineering, and once you see it you can't unsee it.
We learned this the slow way — pouring effort into prompts while the real problem was that the agent was reasoning about code it had never been shown. Fix what the model can see and the wording almost stops mattering. Here's how.
The window is a budget, not a bucket
Every agent has a context window, and it's tempting to treat a big one as a place to dump everything — the whole repo, all the docs, the entire chat history, just in case. This is the most common and most expensive mistake. A context window is a budget you spend, not a bucket you fill. Every irrelevant file you stuff in is signal you've diluted. The agent doesn't reward you for thoroughness; it drowns in it. The goal is not "give it everything." It's "give it exactly what this task needs and nothing that competes with it."
"Lost in the middle" is real, and it's why stuffing fails
Long-context models don't attend to their whole window evenly. Information at the very start and the very end gets used reliably; information buried in the middle of a huge context gets glossed over — the well-documented "lost in the middle" degradation. So when you paste 40 files and the one that matters is file 23, the model may functionally not see it even though it's technically "in context." Bigger windows make this worse, not better, because they give you more room to bury the important thing. We go deeper on how far these windows really stretch in our look at million-token context models — the short version is that capacity is not the same as attention.
Retrieval beats stuffing
The winning move is almost always to retrieve the right files, not dump all the files. Concretely, that means: before a task, figure out which handful of files this change actually touches, and load those — plus one or two neighbors to imitate for style. A four-file context that contains the exact code paths involved outperforms a hundred-file context that happens to include them somewhere. This is why a good repo map matters more than raw window size: it lets you (or the agent) find the four files instead of pasting the hundred.
A practical retrieval routine:
- Locate before you build. First ask the agent (read-only) to find where the feature lives and cite files in
path:lineform. Now you know the real scope. - Load the cited files, plus a pattern to copy. The code paths that change, and one nearby example of "how we do things here."
- Leave the rest out. If a file isn't in the change's blast radius or a style reference, it's noise. Omit it.
A repo map beats a wall of files
An agent that has a compact map of your project — the directory structure, what each area does, where the key entry points are — can navigate to the right code on its own. That map is a few hundred tokens; the alternative is pasting thousands of tokens of files hoping the right one's in there. Invest in the map. Many tools build one automatically; if yours doesn't, a short "here's how this repo is laid out" note at the top of context earns its keep on every task.
Durable memory belongs in the repo, not the chat
Here's the shift that changes everything: chat context is disposable. Every new session starts blank, and anything the agent "learned" last time is gone. The fix is to write the durable stuff into files that live in the repo — a CLAUDE.md or AGENTS.md at the project root that every agent reads at the start of every session.
What goes in it:
- Conventions — how this project structures things, what patterns to follow, what to avoid.
- Commands that matter — how to run the tests, the build, the linter. So "definition of done" is always available.
- Decisions and gotchas — "we use X not Y because Z," "don't touch the legacy module," the traps a newcomer would fall into.
This file is your project's long-term memory. Written once, it saves you re-explaining the same context in every session, and — because it's at the top of the window, not buried in the middle — the agent actually uses it. When a new agent makes a mistake you've seen before, the fix isn't a better prompt; it's a line in this file so no future agent makes it again.
Curate as you go
Context isn't set-and-forget within a session either. As a long task runs, the window fills with old file dumps, dead ends, and stale command output — and that clutter starts crowding out the current task. When an agent gets confused late in a long session, the cause is usually a polluted context, not a dumb model. The cure is to reset: start a fresh session, state the current state cleanly in a few lines, load only the files that still matter, and go. A clean context routinely solves what ten follow-up messages couldn't. Knowing when to do this — and how to survive long jobs that outrun a single window — is its own skill, covered in the session limit survival guide.
The whole method, in one breath
Load the right files, not all the files. Keep a compact repo map so you can find "the right files" fast. Put durable knowledge in CLAUDE.md / AGENTS.md so it survives every session and sits where the model actually reads it. Remember that big windows bury the middle, so retrieval beats stuffing. And curate mid-session — a fresh, clean context is a tool, not an admission of failure.
None of this is about clever wording, and that's the point. Wording is the part everyone obsesses over because it's visible; context is the part that decides the outcome because it's what the model actually reasons over. Get the context right and your prompts can be plain — the agent already knows enough to do the job. Get it wrong and no prompt on earth will save you.