The Secret Life of Claude Code: Context Is Everything

 

The Secret Life of Claude Code: Context Is Everything

How the right background information transforms Claude output

#ClaudeCode #CodingWithAI #SoftwareDevelopment #Programming




Episode 8

The fog had settled early over the city, pressing against the library windows in soft grey sheets. Timothy arrived with his coat still damp, his notebook tucked under one arm and a look on his face that Margaret had come to recognize — not frustration exactly, but the particular bewilderment of a man who had received two different answers to what he believed was the same question.

Margaret was at her usual table near the far window, a lamp casting a warm circle over a stack of open volumes. She did not look up immediately. She had learned that Timothy's best thinking happened in the moments before she acknowledged him, when he was still sorting through what he actually wanted to say.

He sat across from her, set down his notebook, and opened it to a page crowded with notes.

"I asked Claude Code the same question twice," he said.

Margaret set down her pen. "Did you."

"The same question. Same intent. Entirely different output." He turned the notebook toward her, though she did not reach for it. "The first answer was nearly useless. The second was exactly what I needed. And the only difference was that I included some background the second time — background I didn't think mattered."

"What background?"

"That the function was part of a payment processing pipeline. That it had to be idempotent. That we'd already tried a retry-based approach and moved away from it." He paused. "I didn't mention any of that the first time because I thought the question spoke for itself."

Margaret considered this for a moment. Outside, a cab horse clopped slowly past on the wet cobblestones.

"Tell me something," she said. "If you hired a new engineer today — someone capable, experienced, but who had never set foot in your codebase — and you asked them to improve a function, what would you tell them before they began?"

Timothy thought about it. "The purpose of the function. What it connects to. What constraints we're working under. What we've already tried."

"And if you told them none of that?"

"They'd make something that worked in isolation. Something technically correct that missed the point entirely."

"Yes," Margaret said. "And that is precisely what you handed Claude Code the first time."


A Request Is Not a Briefing

Timothy looked down at his notes. "But I thought — if the code is there, if the question is clear —"

"The code tells Claude Code what the function does," Margaret said. "It tells it nothing about what the function means. Those are not the same thing."

She pulled a fresh sheet of paper toward her and wrote two words at the top: request and briefing.

"Most developers treat a prompt as a request," she said. "A request assumes the other party already knows the situation. You are simply asking for a thing to be done. But Claude Code does not know your situation. It knows only what you have placed in front of it." She tapped the second word. "A briefing assumes the opposite. You are bringing someone fully capable up to speed on a situation they cannot know without you."

Timothy was quiet for a moment. "The difference being that with a briefing, the context is the work."

"Half of it," Margaret said.


The Four Categories

She asked him to describe what he had included in the second prompt — the one that had produced the useful output.

He listed it: the name and purpose of the surrounding system, the specific constraint around idempotency, the reason the previous approach had been discarded, and what a successful solution would need to preserve.

Margaret nodded slowly. "Notice what you have described. Not just what you wanted, but why you wanted it, what existed before, and what boundaries the solution must respect. Four distinct categories of information."

"Constraints, history, intent, and edge cases," Timothy said, reading from where he had already written it down.

"You learn quickly," she said, without irony. "Now tell me — which of those did your first prompt contain?"

He looked at the notebook. "None of them."

"And yet you called it the same question."

He saw it then. It wasn't the same question at all. It had the same words. But a question without context is not a question — it is a shape that looks like a question. The meaning lives in what surrounds it.


The Gap Claude Code Fills

Margaret refilled her tea and set the pot within his reach.

"There is something else worth understanding," she said. "When context is missing, Claude Code does not stop and wait. It fills the gap."

"With assumptions."

"With the most reasonable assumptions available to it, given what you have provided. Which means that if you ask a general question, you will receive a general answer — one optimized for some imagined common case that may have nothing to do with yours." She paused. "The output is only wrong if you expected something else. Claude Code did exactly what it was asked."

Timothy turned this over. "So the error isn't in the output. It's in the briefing."

"Precisely." She looked at him steadily. "And this is why the discipline matters. Not because Claude Code is inadequate, but because it is capable. A capable colleague given incomplete information will produce a complete answer to the wrong problem. The capability makes the gap invisible until you see the result."

This was, Timothy thought, a harder lesson than it first appeared. It was not simply include more context. It was understand your own situation well enough to communicate it. Those were different things.


Negative Context: Describing the Walls

"What about the negative space?" he asked.

Margaret looked up. "Say more."

"What you're not doing. What has already been tried. What the solution must avoid." He had been thinking about his second prompt — the one that worked — and realized that much of its value came not from describing what he wanted but from describing what he didn't want. The failed approach. The constraint that ruled out an entire class of solutions.

"Negative context," Margaret said, as though acknowledging the right name for something she had long thought about. "Yes. It is perhaps the most underused form. Developers speak naturally about what they want. They rarely think to describe the walls."

"Because they assume the walls are obvious."

"The walls are never obvious from the outside." She set her cup down. "When a constraint exists because of a failure that happened six months ago, or a requirement buried in a compliance document, or a lesson learned from a system you once worked on at a previous company — none of that exists in the code. None of it exists in the prompt unless you put it there."

Timothy thought of the retry-based approach his team had abandoned after a painful week of intermittent double-charges. That history was nowhere in the codebase. It lived only in the memory of the people who had been there.

"So the context is institutional knowledge," he said. "The things that live in people's heads and not on the page."

"Among other things, yes. And when you brief Claude Code without it, you are asking it to navigate a landscape without knowing where the cliffs are."


The Running Brief

They sat for a while in the comfortable silence that had become part of their evenings. The fog had thickened outside, muffling the street sounds to almost nothing.

"There is one more dimension to this," Margaret said eventually, "that I suspect you will encounter if you begin using Claude Code in longer automated workflows — in agents, pipelines, anything that runs without a human in the loop."

Timothy looked up.

"In those contexts, context is not something you provide once at the start of a conversation. It is something you maintain. The system needs to know not just what you want but where it is in the process, what has already been decided, what constraints persist across the entire task." She paused. "The briefing, in those cases, is ongoing. A kind of persistent awareness."

"A running brief," Timothy said.

"That is one way to describe it. The discipline is the same — you are simply responsible for it across a longer arc." She glanced at the fog-grey window. "Most of the failures in agentic systems are not failures of capability. They are failures of context. The model reaches a decision point and finds that the information it needed was never provided."

Timothy wrote this down. He had been thinking about context as something you front-load — information given at the start of a prompt. He was beginning to understand it as something more like a relationship. Something tended, not delivered.


The Discipline of Knowing Your Own Problem

"I want to go back to something you said earlier," he said.

Margaret waited.

"You said the discipline of providing context is the discipline of knowing your own problem." He looked at his notebook, then at her. "I didn't fully understand it until just now. When I wrote my second prompt — the useful one — I had to stop and think. Not about Claude Code. About the problem itself. What it actually was. What surrounded it. What had been tried."

"And?"

"I realized I'd been thinking about the wrong thing for two days," he said. "I'd been thinking about the function. The real problem was upstream of the function entirely." He paused. "I found that by writing the briefing, not by staring at the code."

Margaret nodded slowly. "This is perhaps the least expected benefit of the discipline," she said. "The act of preparing a proper context — of articulating constraints, history, intent, what has been tried and discarded — is itself a form of thinking. Not a prerequisite to the thinking. The thinking itself."

She closed the volume she had been consulting.

"Most developers discover they do not fully understand what they need until they try to explain it precisely. Claude Code, in this sense, is not only answering questions. It is teaching you to ask them."


Timothy gathered his coat from the back of the chair. The library was quiet around them, the lamps burning low in their brackets, the fog pressing its soft face against every window.

"Same time Thursday?" he said.

"I'll be here," Margaret said, already returning to her reading. "And Timothy — next time you find yourself staring at a prompt that is not working, do not revise the words. Revise the briefing. The words will follow."

He nodded and walked toward the tall doors, his footsteps quiet on the worn stone floor.

Behind him, Margaret turned a page, the sound like a single note in an otherwise silent room.


Next episode: Margaret and Timothy take up the question of planning — why the most important conversation with Claude Code often happens before a single line of code is written, and what a proper plan actually contains.


Aaron Rose is a software engineer and technology writer at tech-reader.blog. For explainer videos and podcasts, check out Tech-Reader YouTube channel.

Comments

Popular posts from this blog

Insight: The Great Minimal OS Showdown—DietPi vs Raspberry Pi OS Lite

The New ChatGPT Reason Feature: What It Is and Why You Should Use It

Raspberry Pi Connect vs. RealVNC: A Comprehensive Comparison