Context is the Core Constraint

The Tool That Forgets

Every Claude Code session starts fresh. There is no persistent state between sessions — no memory of last week's build, no awareness of the files you edited two hours ago in a different terminal, no knowledge of the conversation you had yesterday. Each session begins with a blank context window and builds from there.

This is not a limitation to work around. It is the design constraint that shapes everything about how Claude Code works. Every technique in this track — how you write CLAUDE.md files, how you structure your prompts, how you manage session context — exists because of this one fact: the context window is the fundamental resource.

It holds your entire conversation. Every message, every file Claude reads, every command output, every tool result. It fills up fast. A single debugging session can consume tens of thousands of tokens from file reads and command outputs alone, before any productive coding begins. And as it fills, performance degrades.

What Lives in the Context Window

Most developers think of the context window as the conversation history. That is the visible part. The invisible part is larger.

When Claude reads a file, the entire file content enters the context window. When a Bash command runs, the full output enters. When Claude searches across ten files, every search result enters. None of this gets summarized or compressed in real time — it accumulates. An average file read costs thousands of tokens. A codebase exploration that reads thirty files can fill most of the available space before any coding begins.

At session start, the context window already contains a system prompt, all your loaded CLAUDE.md files, and auto memory. These load before you type anything. This is why CLAUDE.md length matters so much: a 400-line CLAUDE.md is not a style choice, it is a context commitment that leaves less space for the actual work you are trying to do.

How Performance Degrades

LLM performance is not uniform across the context window. Claude attends well to content near the beginning and the end of the window. Content buried in the middle — added thousands of tokens ago, now covered by subsequent messages — receives less reliable attention.

This has real consequences. A coding standard defined early in a long session competes with everything that came after it. A correction you made fifty turns ago may not carry forward to turn eighty. The performance you see in the first twenty turns of a session is not the performance you get on turn seventy.

This is why the most important best practice in Claude Code is not any particular prompting technique — it is context hygiene. The techniques in this track (writing tight CLAUDE.md files, using path-scoped rules, clearing between tasks, compacting with intent) are all context management strategies in disguise.

The Mindset Shift: From Chatbot to Coding Agent

Working with Claude Code requires a different mental model than working with a chatbot. A chatbot responds to questions. A coding agent executes on goals. The difference is not just philosophical — it changes what you should write in your prompts and what you should put in your CLAUDE.md.

With a chatbot, you describe how to do something and evaluate the response. With Claude Code, you describe what you want and Claude figures out how to build it. Claude explores the codebase, reads files, runs commands, makes changes, checks results, and iterates — often for dozens of steps without asking for input. Your job is to provide the right starting conditions, the right constraints, and the right verification criteria.

This means the most valuable things you write are not the prompts themselves, but the persistent context around them: the CLAUDE.md file that tells Claude how this project works, the rules files that scope specific conventions to specific file types, the auto memory that carries forward what Claude learned in past sessions. The prompt is the task. The context is the operating environment.

What This Means in Practice

Understanding context as a resource changes three specific things about how you work.

CLAUDE.md is a context budget. Every line you put in CLAUDE.md costs tokens in every session. That budget should produce real compliance improvements. Instructions Claude already follows correctly on its own are noise. Instructions about behavior that never comes up in this project are noise. Only include what Claude would get wrong without the instruction.

Session structure matters. Starting an unrelated task in the middle of a long coding session mixes concerns in the context window. The active session contains information about the previous task — file reads, command outputs, corrections — that is irrelevant to the new task and takes up space the new task needs. Running /clear between unrelated tasks is not a preference; it is a performance decision.

Prompts should specify, not explain. When Claude has the context it needs from CLAUDE.md and auto memory, prompts can be shorter and more precise. You are not re-explaining the codebase in each prompt — you are assigning the task. The difference between a vague prompt and a specific one is rarely more than twenty words, but the difference in output quality is substantial.

The Road Ahead

The remaining eleven lessons in this track address every layer of the context management problem. Lessons 2 through 5 cover the CLAUDE.md file hierarchy — the four scopes, path-scoped rules, @ imports, and the three-tier loading architecture. Lesson 6 covers auto memory. Lessons 7 through 9 cover prompting technique and the four-phase workflow. Lesson 10 covers context management commands. Lesson 11 covers structured outputs. Lesson 12 covers scaling across parallel sessions and teams.

Each technique answers the same question: what should be in the context window, when should it be there, and what should be kept out?