Why Claude Code's Creator Recommends Deleting Your Config — Four Key Shifts in Context Engineering

Claude Code's creator Boris Cherny sparked heated debate in the developer community with a single piece of advice: every so often, delete your CLAUDE.md file, delete your skills, delete your hooks, and see what the model can do on its own. That sounds pretty radical — are you really supposed to throw away all that hard-won configuration?

Most people discussing this have missed what he was actually trying to say. This article breaks down exactly what Boris said, why he said it, what it means for everyday users, and closes with a set of actionable context-engineering principles you can put to work immediately.

What Boris Actually Said

Boris's original remarks came in response to the question "should people delete everything?" His recommendation has two steps: first delete, then use.

The key is the second half of his explanation of the deletion step: "Because you probably can't accurately predict which instructions the model needs, don't guess. Only when you see the model getting stuck on the same thing repeatedly is it time to add it back."

In other words, what Boris is really conveying isn't "delete blindly" — it's "experiment with your configuration." Start with a clean slate, then gradually add back only what the model's actual behavior shows is necessary. This is an experiment-driven approach to configuration management, not a wholesale purge.

A word of caution, though: if you actually start deleting things blindly, it won't serve you well in the long run. Boris himself doesn't genuinely believe you should delete everything.

CLAUDE.md is Claude Code's core configuration file, stored in the project root and automatically loaded into the context window at the start of every session. It functions as a "permanent system prompt" — the place where developers write project conventions, coding style guidelines, prohibited behaviors, and similar constraints. Skills are reusable task templates; hooks are scripts or actions that execute automatically when specific conditions are triggered. Together these three elements form the "context-engineering infrastructure" of Claude Code. Done well, they dramatically reduce repetitive instructions. Done too granularly, they can lock the model into a narrower behavioral frame than it actually needs, causing it to mechanically follow outdated rules even in situations where it could handle things flexibly.

Why He Wants You to Delete Your Config

Part of why this advice went viral is that Anthropic had just released a new model at the time. Reading deeper into the Anthropic team's writing on how model changes affect real-world use, the picture is considerably more nuanced than "delete everything."

The core of the problem can be distilled to one sentence: Anthropic found they had over-constrained Claude Code — both through system prompts and through CLAUDE.md files and skills.

Deleting does fix the "over-constrained" problem, because no constraints means no over-constraints. But deleting also takes away all your domain knowledge and your documented solutions, and it does nothing to stop the model from making the same mistakes repeatedly.

So a more accurate framing would be: delete all the parts that over-constrain Claude, not delete everything. Once you understand it that way, Boris's advice makes a lot more sense. It's also worth noting the context: Boris was speaking to startup engineers who are highly technical and have time to run experiments. For non-technical users, copying this approach wholesale offers limited benefit.

Four Key Shifts in Context Engineering

Rather than deleting everything, a more reliable approach is to change how you use Claude going forward. Before making any moves, save your existing setup: technical users should push the project to GitHub; non-technical users can prompt Claude Code to copy the entire setup into a dated folder and note how to restore it. Once you've eliminated the "deletion anxiety," you're free to make the following four shifts.

Shift 1: Replace "Rules" with "Judgment Criteria"

A rule says "never do X." A judgment criterion says "match what's around you." Rules constrain Claude in a direction that may not apply to every situation, and they tend to create contradictions.

The example Anthropic gives is: you might write "don't add comments by default, one line max" in one place and "write clear, thorough comments" somewhere else. That contradiction produces inconsistent results and makes Claude work harder than necessary.

The alternative is to give direction rather than mandates: "Write comments that read like the surrounding code — match the density, naming conventions, and style." Similarly, instead of "always output CSV," say "generate reports in the project-approved format."

Shift 2: Replace "Examples" with "Interfaces"

Conventional wisdom was to provide concrete examples for Claude to reference, but this constrains the space the model can think in. If you tell the AI "here are three reports to reference," it gets anchored to that structure.

An interface is just another word for a "specification" — you tell the AI what you need and what the constraints are, without dictating the exact form. For example: "Look at the last month of data and create a report that helps us assess performance."

A good rule of thumb: do you want the AI to be a factory worker or a creative? When it's a creative, examples hurt it — prefer interfaces. When you only need standardized output, examples are still useful.

"Interface" here borrows from software engineering: an interface declares only "what inputs are needed, what output is produced, and what the constraints are," without specifying internal implementation. Translated into prompt engineering, this means describing the task's goal, boundary conditions, and acceptance criteria rather than providing concrete output samples. The reason this works better for creative tasks comes down to the model's anchoring effect: when a specific example exists in the context, the model treats it as a strong prior and subsequent generation gravitates toward the example's structure, style, and length — even when the task actually calls for something different. Interface-style instructions avoid that implicit anchoring and let the model search a larger solution space for the best approach. For scenarios that require strict format consistency (data extraction, form filling, etc.), examples remain the most efficient constraint — the two strategies aren't mutually exclusive.

Shift 3: Move from "Front-Loading" to "Progressive Disclosure"

Progressive disclosure means loading context only when it's genuinely needed. Everything in your CLAUDE.md gets loaded every time, so don't paste large blocks of content directly into it — instead, point to where that context lives and let Claude decide when to load it.

For example, instead of writing "here's my writing style" followed by a wall of text, write "here's my writing style guide" followed by a file path. Skills should work the same way — lightweight context pointers, with detailed content stored in reference files. There's no real subtlety here: just do it.

Progressive Disclosure comes from UX design, where the principle is that interfaces surface more options only when the user needs them, reducing cognitive load. The logic translates directly to context engineering: an LLM's context window is a finite, costly resource. Front-loading everything not only wastes tokens but dilutes the weight of the information that actually matters. Researchers call this context pollution — when irrelevant information occupies the window, the model's attention is scattered when it needs to retrieve key constraints, and output quality drops. Replacing inline content with file paths hands the "retrieval decision" back to the model: it reads a piece of knowledge when it determines it actually needs it, rather than passively absorbing everything preloaded. This is why CLAUDE.md should stay lean — an index, not an encyclopedia.

Shift 4: Leverage Automatic Memory and Default Validation

Newer versions of Claude automatically store information in memory files. You used to have to explicitly remind Claude to save things; now it does so by default — type Memory in the terminal to see the settings and memory folders. You can still ask it explicitly to remember something, of course.

The bigger change is that the model now validates output by default. Previously you'd write "validate your response before sending" in CLAUDE.md, but the model now attempts validation automatically. If you still have validation rules in place, you may be triggering double validation, wasting time and cost. Understanding how validation works is still important — but what you need now is guidance on how to validate specific outputs, not another generic validation instruction.

The Unified Pattern Behind the Four Shifts

Looking across all four shifts, a clear pattern emerges:

• Before each shift, the approach is "you instruct the model because it isn't good enough yet."
• After each shift, the approach is "you share information about your world and your preferences."

That is the real essence of Boris's advice. The goal isn't to delete your skills — it's to delete everything that over-constrains Claude. But intentional boundaries should never be deleted. If your world has hard limits or fixed requirements, those are facts, and you should keep sharing them with Claude.

How to Tell Whether Your Changes Are Working

If you want to test the results, pick one task Claude consistently gets wrong today. Run it in Claude Safe Mode with no context loaded as a baseline (equivalent to Boris's "delete everything" state), then run the same task against both your archived old project and your new, four-shifts-optimized project, and compare results side by side.

For non-technical tasks, though, this comparison is inherently subjective and hard to quantify precisely. The more realistic attitude: these shifts are strategic best practices — getting the direction right is what matters, and there's no need to obsess over measuring every marginal improvement, especially since there's no reliable way to do so. The one core principle: keep everything specific to your situation; remove restrictive rules.

Let Your System Run Alongside AI, Not Against It

As models iterate rapidly, many people worry: does every model update mean I have to revise my entire config? The answer is — set up your system to run alongside AI, not to compete with it.

The context, skills, and guidance you provide shouldn't try to constrain the model. They should give it the hyper-specific knowledge about your particular situation that it could never know on its own — then let it run. If you're unsure where things stand, run Claude Doctor to analyze and clean up your setup.

When Boris says "delete everything," what he really means is: get out of Claude's way, and build with it. Even with the right guidance in place, the burden shifts to the context your system references — and that part never goes away. That, as it happens, is exactly where humans continue to create lasting value.