I spent my Sunday watching a coding agent produce something almost right, three times in a row. Not exactly wrong, just not what I would have done. Then it clicked: the model wasn't the problem. I'd lazily handed it a thin brief (I may or may not have been hungover) and expected it to fill the gaps with judgment it didn't have. The gap was context, not capability.

That's the shift worth internalizing, so here it is up front.

The models already cleared the bar

The frontier models have crossed a quality threshold. Argue all you want about which one designs a cleaner UI or writes tighter backend code — the practical reality is they're all exceptionally capable now, even with true AGI still nowhere in sight. Raw capability is, for most working purposes, solved.

Which means the variable that actually decides whether you get sharp output or slop is no longer the model. It's context — the information the model assembles before it acts. You're the one steering, and the steering wheel is context management. (The uncomfortable part: that makes the output quality your responsibility, not the model's.)

What "context" actually is

Context is just the model gathering everything it needs to execute an action. In a coding agent — or any agent — that context window fills from several sources stacked on top of each other.

At the bottom sits the system prompt, usually written by the model provider, governing how the model behaves and what it steers clear of. On top of that go your own instruction files, any skills, the agent's built-in tools, the codebase itself, and finally the running conversation. All of it lands in one window.

Here's the mechanical detail that matters: it accumulates. A session might open around 20,000 tokens and climb as the conversation runs, eventually pressing against a ceiling — say 250,000 tokens — at which point tools like coding agents "compact" the window to keep going. Every token you spend on standing instructions is a token you're not spending on the actual work.

You probably don't need a claude.md file

Here's the contrarian position, stated plainly: roughly 95% of people don't need an agent.md or claude.md file at all.

The logic falls straight out of the premise. If the models are already good, telling a coding agent "this codebase uses React" is redundant — the agent has the code in context and can just look. It's like reminding a seasoned professional to bring a microphone to a job they've done a few hundred times.

The real cost is that these files get injected into context on every single turn. A thousand-line file might run 7,000 tokens, and you pay that toll on every run whether it's relevant or not. So the move is to go minimal — actively stripping instructions out rather than piling them on.

The narrow 5% exception is genuinely proprietary information: something specific to your company, or a methodology unique to you, that truly has to be referenced in every conversation. Most people don't have that. And when they think they do, it usually belongs in a skill instead.

Skills, and the mechanism that makes them cheap

Skills are the better tool, and the reason is progressive disclosure. A skill file carries a name, a description, and a body of detailed instructions. Only the name and description load into context by default — the body stays out. The agent sees just enough to recognize when the skill is relevant, and only then reads the full document.

The cost difference isn't marginal.

Take a concrete case: a 116-line code-structure skill totals 944 tokens. As an instruction file, you'd pay all 944 on every chat. As a skill, you carry only the ~53-token name and description until the moment the agent actually needs it — a user asks for a report in a specific format, the agent recognizes the match, and then it reads the body.

The rule that falls out of this: anything with a specific way of generating a report or structuring code belongs in a skill the agent calls progressively — not an instruction file that loads unconditionally. You get the guidance exactly when it's relevant and pay nothing for it the rest of the time.

Why you have to walk the model through the work

Underneath all of this is one mechanical truth, and it explains most of the frustration people feel when an agent "doesn't get it." Models don't think — they predict tokens. Your input gets mapped onto a vector space, and the model returns the nearest resemblance. Ask for the capital of Somalia and "Mogadishu" sits close by, so out it comes (bet you didn’t know the capital before this article). It reads as understanding, reasoning, even emotion, because it's trained on a staggering amount of data. But there's no comprehension under the hood.

So when an agent produces something almost-but-not-quite right, this is usually why: an agent will mimic you perfectly, but if you've handed it nothing to mimic, it has nothing to work from. My three near-misses weren't a reasoning failure. They were an empty template.

The fix is to run the workflow yourself first, alongside the agent — generating the context of one successful run, which then becomes the raw material for a skill you can trust.

That loop is the whole discipline in miniature. You do the work once, deliberately, so the model has a genuine example to pattern-match against — and everything after that gets cheaper and more reliable.

None of this is about coaxing more intelligence out of the model. The intelligence is already there. What's left is the far more mundane, far more consequential job of deciding what the model gets to see, and when. Strip the standing instructions down to almost nothing. Push the specialized knowledge into skills that load only when they're earned. And when you want the model to do something the way you'd do it, show it one good run first — because it can only ever be as good as the example you gave it.

Still early days on where these conventions settle, and I'm holding the specifics loosely. But the direction feels right: the leverage moved from the model to the context, and that's the part you actually control.