Claude Code context discipline in 2026 – CLAUDE.md, memory, MCPs, and subagents without wasting tokens

Posted on by

As of April 21, 2026, the most useful Claude Code discussions on Reddit are not about one more prompt trick.

They are about context discipline.

That is a good sign.

It means people have moved past the first phase.

The first phase was simple.

Install the tool.

Ask it to write code.

Get excited.

Then get annoyed.

The second phase is more interesting.

Why does Claude Code feel sharp in one session and sloppy in another?

Why does it reread the same files?

Why does it spend tokens on exploration instead of edits?

Why do MCP servers sometimes help and sometimes make the setup feel heavier?

Why do subagents feel brilliant for research but wasteful for small code intelligence tasks?

Those are not prompt questions.

Those are operating-system questions.

I use that phrase intentionally.

Claude Code is not just a chat box for code.

Once you use it every day, your repo needs a small operating system around it.

Not a giant agent platform.

Not a 40-tool maze.

A simple set of rules that tells Claude what to remember, what to inspect, what not to touch, how to verify work, and when to isolate context.

That is context discipline.

Why this topic is showing up on Reddit

A recent r/ClaudeAI thread about a full Claude Code setup got traction because it hit a nerve.

The core claim was blunt.

Many people are blaming Claude when their harness is the real problem.

That is an uncomfortable claim, but it is directionally right.

The comments were even more useful than the original claim.

Some people pushed back on MCP overhead.

Some asked how persistent memory avoids becoming too large.

Some wanted a demo repo.

Some argued that subagents burn too many tokens for file intelligence and are better used for independent review.

That mix is exactly what makes the topic worth writing about.

The winning answer is not “install every MCP server.”

It is also not “never use MCP.”

The practical answer is narrower.

Use persistent rules for things that should be true every session.

Use memory for things Claude learns over time.

Use subagents when the side task would flood the main context.

Use MCP when an external system is truly part of the workflow.

Use plain CLI commands when they are cheaper and more deterministic.

That is the whole game.

The rest is taste, repo size, team size, and tolerance for ceremony.

The short answer

Claude Code context discipline is the practice of keeping the main conversation small, the project rules explicit, the memory scoped, the tool layer intentional, and the verification step non-negotiable.

If Claude keeps getting “worse” inside your project, the first thing to check is not the model.

Check your context shape.

Check your CLAUDE.md.

Check whether memory is helping or just accumulating noise.

Check whether MCP servers are replacing deterministic commands that would be cheaper.

Check whether subagents are isolating exploration or creating parallel confusion.

Check whether Claude is allowed to say “done” without proof.

That last one matters more than people admit.

An AI coding assistant without verification discipline is a confident intern with admin access.

Useful, fast, and occasionally terrifying.

The minimum useful stack

Here is the smallest stack I would start with.

Layer Purpose Keep it small by
CLAUDE.md Project-level operating rules Writing stable rules only
.claude/rules/ Scoped behavior by task or file type Splitting rules instead of one giant file
Memory Things learned across sessions Keeping indexed, typed notes
Subagents Isolated research or review Using them for side tasks, not every small lookup
MCP Real external systems Connecting only systems that change the work
CLI scripts Deterministic local actions Preferring them when the command is simpler than a tool server
Verification Evidence before completion Requiring commands, diffs, screenshots, or tests

Notice what is not in this table.

There is no “install ten servers first” step.

There is no “write a 2,000-line system prompt” step.

There is no “spawn agents for every action” step.

The base layer is boring.

That is why it works.

CLAUDE.md should be a contract, not a diary

Claude Code official memory docs describe CLAUDE.md as persistent instructions loaded into each session.

That sounds simple.

The mistake is treating it like a dumping ground.

A good CLAUDE.md should not contain every preference you have ever had.

It should contain the rules that must survive across sessions.

For a software project, that usually means:

  • what the project is
  • how to run tests
  • which files are sensitive
  • what style the repo already uses
  • what commands verify work
  • what must never be changed without approval
  • how to handle user edits
  • how to report failures

That is enough.

If your CLAUDE.md becomes a journal, Claude reads a journal.

If it becomes a contract, Claude reads a contract.

The difference shows up in diffs.

Contracts produce smaller changes.

Journals produce vibes.

Vibes are lovely in music.

They are less lovely in auth middleware.

The rule I would put near the top

If I had to add one rule to every Claude Code project, it would be this:

Claude cannot claim work is complete until it has shown verification evidence.

That evidence can be a test command.

It can be a type check.

It can be a screenshot.

It can be a lint result.

It can be a curl response.

It can be a manual inspection note when automation is not possible.

But it must exist.

This single rule prevents a surprising amount of fake progress.

Without it, Claude may summarize the intended fix instead of the verified fix.

With it, the session has a finish line.

The finish line is not “the code looks right.”

The finish line is “the code was checked in a way that matches the risk.”

That is a much better habit.

Memory is useful, but only if it has boundaries

Claude Code official docs separate two kinds of memory.

There are instructions you write, such as CLAUDE.md.

And there is auto memory, where Claude accumulates learnings from corrections and preferences.

This distinction matters.

Human-written instructions should be stable.

Auto memory should be discovered.

If you mix them together, memory becomes mushy.

I like typed memory files for this reason.

For example:

  • project_architecture.md
  • build_commands.md
  • debugging_notes.md
  • user_preferences.md
  • release_gotchas.md
  • known_bad_paths.md

The names matter.

They tell both the human and the model what kind of knowledge belongs there.

The Reddit pushback about memory getting too big is fair.

Memory is not free.

Old memory can become stale.

Contradictory memory can become dangerous.

So memory needs maintenance.

The simple rule is:

Every memory note should either help the next session act faster, or it should be removed.

If a memory note only records that something once happened, it probably belongs in a retrospective, not in active memory.

Retrospectives are different from memory

This distinction saves a lot of clutter.

Memory is for reusable knowledge.

A retrospective is for what happened in one session.

Those are not the same thing.

A session retrospective might say:

  • what task was attempted
  • what changed
  • what failed
  • what command verified it
  • what should be tried next

That is great.

But it does not all need to be loaded every session.

The useful parts can be promoted into memory later.

Think of retrospectives as raw logs.

Think of memory as distilled rules.

If everything becomes memory, nothing is memory.

Subagents are for context isolation, not status signaling

Claude Code official subagent docs frame subagents as specialized assistants with their own context window.

That is the key.

The separate context window is the product.

Not the agent name.

Not the ceremony.

Not the feeling of having a team.

Use a subagent when the task would pollute your main conversation.

Good examples:

  • searching a large codebase
  • comparing several files
  • reviewing a diff independently
  • investigating a flaky error
  • gathering documentation
  • checking migration impact
  • running a focused QA pass

Weak examples:

  • reading one nearby function
  • checking one file name
  • making a tiny edit
  • answering a question already in the main context

This is where some Reddit commenters were right to push back.

Subagents can save context, but they can also burn tokens.

If the task is small, do it inline.

If the task is wide, isolate it.

That one sentence is better than most subagent advice.

MCP servers are not automatically better than CLI commands

MCP is powerful.

It lets Claude interact with external systems in structured ways.

That can be excellent for:

  • browser inspection
  • database schema reads
  • issue trackers
  • logs
  • documentation lookup
  • design systems
  • hosted observability tools

But MCP is not a badge of maturity.

Sometimes a CLI command is better.

If gh pr view gives you exactly what you need, you may not need a GitHub MCP server for that action.

If npm test is the verification command, you do not need a fancy wrapper.

If rg finds the symbol in 0.2 seconds, do not turn symbol search into architecture theater.

The decision should be based on friction.

Use MCP when it reduces friction or adds capabilities Claude cannot get cleanly through shell commands.

Use CLI when the command is deterministic, cheap, and already part of your workflow.

This is not anti-MCP.

It is anti-tool-hoarding.

Tool-hoarding is how a simple workflow becomes a haunted closet.

No one wants to debug a haunted closet at 11 PM.

A practical MCP decision table

Need Prefer CLI/script when Prefer MCP when
GitHub You need one PR, issue, or diff command Claude needs structured repeated interaction
Browser QA One static screenshot is enough Claude needs to inspect DOM, console, network, screenshots
Database You can run one read-only query safely Claude needs schema-aware exploration with guardrails
Docs Local docs are pinned Current external docs change often
Error tracking Logs are exported locally Claude needs live issue context and traces
Files rg, find, and tests are enough Files live in another app or service

The table is intentionally boring.

Good operations are usually boring.

If your tool choice feels exciting, ask whether it is actually removing work.

Excitement is not a metric.

Verification is.

The 50-line rule is not about line count

Some Claude Code users set hard limits, such as one fix per commit or small diff sizes.

The exact number is less important than the constraint.

Small diffs force the model to scope its work.

They force the human to review faster.

They make rollback easier.

They reduce the chance that Claude “helpfully” rewrites adjacent code.

I do not think every bugfix must be under a specific line count.

But I do think every AI-generated change should have a size expectation.

For example:

  • “Touch only the parser and its tests.”
  • “Do not refactor adjacent components.”
  • “Keep the change under one small PR.”
  • “No dependency changes.”
  • “Do not modify auth, billing, or migrations.”

These constraints are context discipline.

They are also kindness to your future reviewer.

Future reviewer is often you.

Be kind to that person.

They have already suffered enough.

Verification should match risk

Not every change needs the same proof.

A typo fix does not need a full integration suite.

A payment change does.

A CSS tweak might need a screenshot.

A database migration needs rollback thinking.

An auth change needs adversarial review.

The problem is not that people skip verification.

The problem is that they use the same verification shape for every task.

That is how small tasks become slow and risky tasks become under-checked.

Use a risk-based verification ladder:

Risk Minimum evidence
Copy or typo Diff inspection
Small UI Screenshot or browser check
Local logic Unit test or focused script
Shared module Unit test plus dependent usage check
API behavior Request/response check plus regression test
Data migration Dry run, backup, rollback path
Auth, billing, privacy Human review plus tests plus logs

This is where Claude Code becomes genuinely useful.

It can help run the ladder.

But you have to define the ladder first.

The main conversation should stay boringly focused

The main Claude Code conversation should not become a junk drawer.

Keep it focused on:

  • the goal
  • the current plan
  • the files being changed
  • the verification evidence
  • the remaining risk

Send noisy exploration elsewhere.

Use subagents for wide search.

Use files for persistent notes.

Use retrospectives for session history.

Use memory for distilled lessons.

Use CLAUDE.md for stable rules.

The main context is where decisions happen.

Do not fill it with every breadcrumb.

Breadcrumbs are useful when you are lost.

They are less useful when they cover the entire kitchen.

What I would not copy from Reddit setups

Reddit is a great signal source.

It is not a truth source.

A setup can sound impressive and still be wrong for your repo.

I would not blindly copy:

  • every MCP server someone lists
  • every memory pattern
  • every subagent workflow
  • every hook
  • every token-saving claim
  • every tool stack built for a different codebase

Instead, copy the questions.

That is the useful part.

Ask:

  • What is repeatedly wasting context?
  • What does Claude keep asking again?
  • What work is deterministic enough for a script?
  • What work is wide enough for a subagent?
  • What decisions need human approval?
  • What proof should be required before “done”?
  • What memory should be promoted?
  • What memory should expire?

Those questions travel well.

Specific stacks travel poorly.

My preferred starting template

If I were setting up a new Claude Code project today, I would start with this structure:

repo/
β”œβ”€β”€ CLAUDE.md
β”œβ”€β”€ .claude/
β”‚   β”œβ”€β”€ rules/
β”‚   β”‚   β”œβ”€β”€ testing.md
β”‚   β”‚   β”œβ”€β”€ security.md
β”‚   β”‚   └── frontend.md
β”‚   β”œβ”€β”€ agents/
β”‚   β”‚   β”œβ”€β”€ code-reviewer.md
β”‚   β”‚   └── explorer.md
β”‚   └── commands/
β”‚       β”œβ”€β”€ verify.md
β”‚       └── retro.md
β”œβ”€β”€ docs/
β”‚   β”œβ”€β”€ decisions/
β”‚   └── retros/
└── scripts/
    └── verify.sh

This is enough.

You can add MCP later.

You can add more agents later.

You can add hooks later.

But if the base rules are vague, adding tools just makes vague work faster.

Fast vague work is not a win.

It is a beautifully paved road to confusion.

A sample CLAUDE.md outline

Here is the kind of outline I would use.

# Project Instructions

## Project Shape
- What this app does
- Main frameworks
- Important directories

## Hard Rules
- Do not touch auth, billing, or migrations without explicit approval
- Prefer minimal diffs
- Do not add dependencies without explaining why
- Preserve user edits

## Verification
- Run `npm test` for logic changes
- Run `npm run typecheck` before completion
- Use Playwright screenshot checks for UI changes
- Report commands that could not be run

## Code Style
- Follow existing patterns
- Prefer local helpers
- No broad refactors during bugfixes

## Reporting
- Summarize changed files
- Include verification evidence
- List residual risk

The details will vary.

The structure is the point.

A model cannot respect boundaries you never wrote down.

When memory should be promoted

Promote something to memory when it has repeated value.

Good memory:

  • “This repo uses pnpm, not npm.”
  • “The checkout flow must not be modified without approval.”
  • “Playwright screenshots should use the mobile and desktop viewports.”
  • “The staging API returns 403 unless the test header is present.”
  • “This package fails tests unless Redis is running.”

Bad memory:

  • “We fixed a bug yesterday.”
  • “The user seemed annoyed once.”
  • “A branch was created for a temporary experiment.”
  • “A test failed because of a typo that no longer exists.”

Memory should reduce future confusion.

It should not preserve every emotion from the past.

Software already has enough feelings.

We do not need to serialize all of them.

When to use subagents

Use subagents when you need separation.

For example:

Ask an explorer subagent to map the files involved in a feature.

Ask a reviewer subagent to inspect a diff without being biased by the implementation path.

Ask a documentation subagent to summarize official docs.

Ask a QA subagent to list edge cases while you keep implementing.

That is useful.

Do not spawn a subagent just because the task sounds important.

Importance is not the trigger.

Context isolation is the trigger.

This distinction prevents agent theater.

Agent theater is when the workflow looks advanced, but the output is slower than doing the work directly.

Every agent should earn its context.

When to use hooks

Hooks are good for deterministic cleanup.

Examples:

  • run formatting after edits
  • save a session note before compaction
  • remind Claude to verify before stopping
  • record a command result
  • prevent forbidden file edits

Hooks are bad when they hide too much.

If a hook does something important, the human should know it exists.

Invisible automation can be worse than no automation.

Claude thinks the task is done.

The hook fails silently.

The human trusts the summary.

Now everyone is sad.

Use hooks for boring work.

Keep critical decisions visible.

A small checklist before adding another tool

Before you add another MCP server, subagent, plugin, or hook, ask:

  • What repeated pain does this remove?
  • Can a CLI command solve it more simply?
  • Will this reduce or increase context load?
  • Does it need live external state?
  • Does it introduce new permissions?
  • How will I know it worked?
  • How will I disable it?

If you cannot answer those questions, wait.

Waiting is underrated.

Especially in AI tooling, where every shiny thing promises to save time and then quietly asks for a weekend.

The Reddit signal I would actually act on

The r/ClaudeAI thread shows a cluster of demand:

  • people want memory that does not rot
  • people want MCPs that justify their overhead
  • people want subagents that save context instead of burning it
  • people want verification rules that stop fake completion
  • people want demo repos and concrete examples
  • people want fewer mystical claims and more operating discipline

That is the market signal.

Not “Claude Code is solved.”

Not “install this exact stack.”

The signal is:

People are now using Claude Code enough to feel the operational pain.

That is when better workflows matter.

Early users ask, “Can it write code?”

Daily users ask, “Can I trust this loop tomorrow morning?”

That second question is the real one.

Final take

Claude Code context discipline is not about making your setup look advanced.

It is about making your setup boring enough to trust.

Write stable rules.

Keep memory scoped.

Use subagents for wide side work.

Use MCP when external state matters.

Use CLI when determinism is cheaper.

Keep diffs small.

Require verification evidence.

Promote only useful lessons into memory.

Let retrospectives hold the messy history.

This does not make Claude magical.

It makes Claude less wasteful.

That is a better goal.

Magic is hard to debug.

Discipline is easier to repeat.

FAQ

Is CLAUDE.md still worth using in 2026?

Yes.

It is still the simplest way to give Claude Code stable project-level instructions.

The trick is keeping it concise and contractual.

Do not turn it into a pile of every preference you have ever had.

Should I use MCP servers for everything?

No.

Use MCP when Claude needs structured access to an external system.

Use CLI commands when the job is deterministic and already easy to run.

The best setup often mixes both.

Do subagents really save tokens?

They can.

They help most when a side task would flood the main context with search results, logs, or file contents.

They can waste tokens when used for tiny lookups or work that already fits in the main thread.

How do I stop memory from becoming too large?

Separate retrospectives from memory.

Retrospectives can be messy session logs.

Memory should be distilled, typed, and useful across future sessions.

If a memory note does not help future work, archive it.

What is the first rule I should add?

Require verification before completion.

Claude should not say a task is done until it shows the command, test, screenshot, diff, or inspection evidence that proves the work.

κ΄€λ ¨ κΈ€

μ°Έκ³  자료/곡식 좜처

Publishing Notes

  • Reddit was used as a demand signal, not as the sole factual basis.
  • Official Claude Code docs were used for memory and subagent behavior.
  • The article avoids copying the Reddit setup and instead converts the discussion into an operating checklist.
  • This is an English experiment for the Claude Code operations hub.