context management is the new debugging skill

The O'Reilly Radar published a piece last week called "Why Doesn't Anyone Teach Developers About Context Management?" and the title made me laugh for a very specific reason.

The answer is: because we barely teach developers about debugging, and context management is debugging's smarter sibling.

I spent years learning to debug by sitting next to people who were better at it. I watched them narrow down problems by asking the right questions, excluding irrelevant information, building mental models of the system, and knowing exactly what to ignore. Nobody handed them a syllabus. They picked it up the hard way.

Now we have LLMs in every editor, and the skill that separates useful outputs from frustrating garbage is the same one that separated good debuggers from bad ones: knowing what to include, what to exclude, and how to ask.

Martin Fowler published a piece around the same time on the Interrogatory LLM, and that framing — interrogatory, not conversational — is exactly right. You are not chatting. You are interviewing an incredibly knowledgeable and completely uncritical research assistant.

the skill nobody teaches

Think about how debugging works.

A junior developer sees a bug. They look at the error. They look at the code that produced the error. They try something. It does not work. They try something else. They spiral.

A senior developer sees a bug. They isolate assumptions. They ask what changed recently. They check input boundaries. They look at dependencies. They confirm the error is real versus hallucinated by a monitoring tool. They build a theory, test it, invalidate it, build a new one. They prune branches of possibility until only the correct one remains.

The difference is not tools. It is context management. The ability to hold a model of the system, exclude irrelevant facts, include the right ones, and update the model as new evidence arrives.

Now apply this same skill to working with an LLM.

A junior AI user pastes a code file and asks "fix the bug." The model has 30,000 tokens of irrelevant imports, dead code, and comments about a different feature. The bug is in line 142. The model fixates on the more visible problem in line 300.

A senior AI user pastes only the relevant function, includes the error message, mentions what has already been tried, specifies the language and framework version, and asks a focused question about a specific behavior. The model gives them exactly what they need on the first try.

Same model. Same intelligence. Radically different outcome because one person managed context better.

what context management actually means for AI work

I think there are four distinct skills here, and I am only starting to get good at three of them.

Inclusion. What to put in. This is the most obvious one. You need relevant code, relevant error messages, relevant data, relevant constraints. The mistake most people make is including too much, not too little. A whole file is worse than two functions and an error trace. A whole conversation history is worse than "based on the last three messages, here is what we established."

Exclusion. What to leave out. This is harder because it requires judgment. You need to know that the import block does not matter, the test framework version does not matter, the unrelated feature does not matter. Every token you include dilutes the signal. Models have finite context windows, but even with infinite windows, more noise means worse outputs. The model cannot prioritize what you do not explicitly signal.

Ordering. What goes first. The beginning of the prompt carries disproportionate weight in most models. The system prompt matters more than the trailing instruction. Critical context should not be buried in paragraph four. The same way a debugger starts with "what changed" rather than "what is the entire history of this system," an effective prompt starts with the most relevant constraint.

Updating. When to replace context instead of appending to it. This is the most advanced skill and the one I see most people miss. After a few rounds of conversation, the accumulated context includes dead ends, discarded theories, and resolved misunderstandings. Keeping that in the window makes the model cling to old frames. You should be comfortable saying "forget the last three exchanges, here is what we know now." This is retracing in debugging. Start fresh when the mental model changes.

the interrogatory approach

Fowler's interrogatory LLM concept is a specific technique within this broader skill.

The idea is simple. Instead of asking the model to solve a problem, you ask it to help you reason about the problem. You question it like a witness, not like an oracle.

• "Given this error, what are three possible causes ranked by likelihood?"
• "What additional information would help narrow the cause?"
• "Is there anything in this code that looks unusual to you?"
• "What assumptions am I making that might be wrong?"
• "Can you find a case where this function would produce the wrong result?"

Each question reduces uncertainty without committing to a single path. This is exactly how I debug with a colleague. I do not ask them to fix it. I ask them to think with me.

The model is not solving the problem. It is helping me solve the problem more efficiently.

That distinction is everything.

why this matters more than prompt engineering

There is a whole industry around prompt engineering. Templates, frameworks, best practices, structured outputs, chain-of-thought recipes.

I think most of it is noise, or at least premature optimization.

The real leverage is not in the template. It is in the judgment about what goes into the template. If you know how to manage context — what to include, exclude, order, and update — then a simple "explain this error and suggest a fix" will outperform a beautifully structured prompt full of irrelevant detail.

Prompt engineering is syntax. Context management is semantics.

You can learn a lot of syntax in a weekend. Semantics takes deliberate practice, feedback loops, and the willingness to treat each interaction as an experiment, not an answer retrieval.

the debugging parallel

The reason I keep coming back to debugging is that it is already the skill developers are supposed to have.

We just never called it context management.

When you isolate a bug to a function, you are excluding context. When you reproduce it in isolation, you are building a controlled environment. When you check version history, you are including the right temporal context. When you close four irrelevant browser tabs and focus on one terminal window, you are managing attention — which is context for your human brain.

LLMs make this skill more visible because they force explicit articulation. You cannot just think "the bug is probably in the caching layer." You have to tell the model why you think that, what caching looks like, what you already checked, and what outcome you expect.

The act of articulating context for the model forces you to articulate context for yourself.

That is why pairing with an LLM can make you a better debugger, even when the model is wrong. The exercise of framing the question honestly is exercise for your own reasoning.

what i would practice

If I wanted to get better at context management as an AI-assisted developer, I would do three things.

First, rebuild from scratch for every new problem. Resist the temptation to keep a conversation thread going for days. Start fresh. Copy only the relevant code. Write a new system prompt. The accumulated context from yesterday's debugging session is noise for today's feature work.

Second, write the system prompt first. Before you paste any code or ask any question, write one or two sentences that define what you want and what constraints exist. "You are a Go backend engineer reviewing a PR. Focus on error handling, concurrency safety, and API consistency. Ignore formatting and naming." This sets the model's attention before it sees any code. It works.

Third, treat context as a resource you are allocating. You have a limited window. Every line you paste costs space. Every irrelevant detail costs signal. Ask yourself: if I had to explain this problem in three sentences to a smart engineer who knows nothing about my project, what would I say? Then say that.

the real skill is judgment under uncertainty

The deeper truth is that context management is not an AI skill. It is a systems thinking skill that AI makes more important.

Every complex system forces you to make decisions with incomplete information. Debugging. Incident response. Architecture design. Code review. Onboarding. Migration planning. All of them require you to figure out what matters, what does not, and how to update your understanding as new evidence arrives.

LLMs just make the cost of getting this wrong more visible and more immediate.

A bad context decision with a colleague might waste an hour of pair programming. A bad context decision with an LLM might waste three attempts, five minutes each, and leave you frustrated with "the model" when the problem was actually the prompt content.

The model is fine. The context was not.

the punchline

Context management is the new debugging skill because debugging was always context management. We just did not call it that.

The LLM is a mirror for your own reasoning. If you cannot articulate the problem clearly for the model, you probably do not understand it clearly yourself.

O'Reilly is right that nobody teaches this. But the good news is that you can practice it every time you open a chat window.

Treat each interaction as a deliberate exercise in inclusion, exclusion, ordering, and updating.

Your model outputs will get better. Your debugging will get faster. And somewhere along the way, you will realize that the skill you were practicing was never about talking to AI.

It was about thinking clearly under uncertainty.

And that skill is not going anywhere.