Claude 2026 Best Practices: Delete CLAUDE.md and Let Agents Manage Agents

From Addition to Subtraction: Why You Should Delete Your CLAUDE.md

Over the past year, AI users have developed a kind of muscle memory: writing detailed custom instructions for models, maintaining bloated CLAUDE.md files, and stacking various skill files. But Boris Cherny, the head of Claude Code, recently offered a counterintuitive suggestion in several talks—delete them.

This isn't attention-seeking. Anthropic's internal approach to building Claude Code is "ablation": with each new model release, the team first deletes most of the system prompt, then adds it back line by line. They found that new models actually run more efficiently with fewer instructions, because much of the old prompt was merely fixing problems the model no longer had. As shown in [screenshots/19785_000.jpg], over-constraining actually caps the model's intelligence ceiling.

The takeaway for ordinary users is straightforward: clear your CLAUDE.md once every six months, see how the bare model performs, then rebuild as needed. You can retain three types of information—who you are, what your goals are, and how you define "done." As for behavioral instructions like "think this way" or "reply that way," new models barely need them anymore.

Illustration:

What is CLAUDE.md? CLAUDE.md is a Markdown configuration file that Claude Code automatically reads from the project root directory, used to provide the model with persistent instructions such as project context, coding conventions, and common commands. It is essentially a "system prompt" distributed alongside the repository, where users can specify code style, directory structure, testing methods, and even prohibited actions. In earlier models, such files significantly reduced the cost of repeated explanation, so the community gradually evolved increasingly bloated ways of writing them. But as models' own instruction-following and context-understanding capabilities improved, lengthy CLAUDE.md files could instead conflict with the model's internalized general conventions, creating over-constraint. This is the direct reason Boris suggests "regularly clear and rebuild as needed"—treat configuration as an iterable experimental variable rather than a one-time fixed asset.

Verification Over Prescription: Don't Teach the Model How to Think, Just Define What "Done" Means

The most frequent mistake Boris observed is over-specification. Users habitually write "first do this, then do that," which essentially tells the AI how to think. A year ago this was indeed necessary, but now it locks the model into a dumber path.

The correct approach is to shift to output specifications: clearly define what kind of result counts as success, then let the model find its own path. The video author's approach is to drop a bunch of links to be processed directly into Claude Code, saying only "help me transcribe them," without explaining the method—the model figures it out itself.

The most illustrative case is Bun. This JavaScript runtime with over 20 million monthly downloads (Claude Code itself runs on it) was plagued by memory leaks and crashes, so its creator decided to use Claude Code to rewrite 530,000 lines of Zig code into Rust. The engineering team had originally estimated a year. It actually took 11 days, with just one engineer at the helm and about 64 coding agents working in parallel. The Rust version is now in production. Anthropic CEO Dario also confirmed that most of Claude's own code is now written by Claude, with engineers shifting to review and verification.

The key to this case isn't how clever the prompts were, but that the verification process was automated. The demand for engineering skills is shifting from writing code by hand to curation, supervision, and verification.

The difference between output specs and process instructions. Process instructions describe "how to do it," such as first read the file, then create a branch, and finally run tests; output specifications describe "what counts as a qualified result," such as all tests passing, no type errors, and changes confined to the target module. The former restricts the model to the author's predetermined path—once the environment changes or the path is suboptimal, the model can only execute mechanically; the latter returns the search path to the model while providing a verifiable completion condition as a safety net. In engineering terms, this aligns with test-driven development: write acceptance criteria first, then let the implementation run free. When defining output specifications, use facts that can be automatically judged (command exit codes, file existence, field completeness) as much as possible, and avoid subjective descriptions like "write it a bit better," otherwise the verification step still requires human intervention and the automated loop cannot be closed.

Even Anthropic Doesn't Know the Model's Capability Boundaries

There's an intriguing story inside Anthropic: someone accidentally discovered that Claude could draw portraits and landscapes using OpenCV, even though no one had ever trained it to draw. Boris speculates that there may be dozens or even hundreds of unknown capabilities hidden in the model, simply because no one has asked. [screenshots/19785_001.jpg] The implication behind this statement is that the bottleneck in capability discovery lies with the questioner, not the model.

The actionable advice is: every week, give Claude a task you think it can't do. Failure costs at most ten minutes; success could open an entirely new efficiency channel. The author himself once handed Claude a task like "build a complete customer lead scraping system"—something he wasn't even sure was feasible—and has already begun actually executing it.

Illustration:

Capability Elicitation is a specialized problem in model evaluation: a model possessing a capability doesn't mean it will manifest under default questioning. Many capabilities require specific tools, scaffolding, or prompt structures to be elicited—for example, providing a code execution environment, allowing multiple attempts, or giving an explicit tool list. So "no one trained it to draw" isn't contradictory—the model may have already acquired relevant representations from massive multimodal and code data, just lacking the trigger conditions. The practical implication for users is: when evaluating a model, don't draw conclusions after asking just once; instead, change the tool combination, task granularity, and feedback method and try again. Systematic capability elicitation can help teams discover underestimated model ceilings and avoid misjudging tasks that could be automated as requiring manual completion.

Agent Managing Agent: From Single-Point Automation to Workflow Orchestration

Boris says he rarely talks directly to agents anymore, because his agents are talking to other agents. At Anthropic, he has thousands of agents running in a single evening; Claude maintains its own codebase, running 20 to 30 routines daily, each described in just one sentence. The result is engineer productivity increasing by hundreds of percentage points per month, and still accelerating—the team is still limited by the number of engineers.

The implementation path isn't complicated: pick a task you repeat weekly or daily and put it on a schedule. It could be business opportunity research, outreach, inbound lead management, or even monthly bookkeeping. Don't try to build an agent army on day one; automate one high-leverage task first, then add another next week. [screenshots/19785_002.jpg] At this pace, you can take over four workflows that each consume several hours in a month, and twenty-four in half a year.

Illustration:

Loop Engineering: Let the Model Check Its Own Work

Scheduled tasks solve "when to run"; loops solve "how to ensure it runs correctly." The new model's ability for self-verification is the premise for this approach to work.

The author's operational paradigm is a combination of two commands: /goal defines the final output, and /loop defines the check interval. His example is monitoring a competitor's channel—scanning for newly uploaded videos, recording titles, view counts, and view growth rates, flagging anomalies where views reach more than three times the channel median with a one-line title analysis, with completion conditions being the tracking table updated and anomalies flagged, stopping after eight rounds. The model automatically inserts small loops for verification during the process and only returns results after passing your defined completion criteria.

This is only feasible now because unsupervised agents a year ago were not safe. If an agent read a malicious instruction (such as "delete all files on the user's computer"), it would likely comply. Boris says that with the new model and Anthropic's classifiers running on all traffic, prompt injection is now difficult to pull off. Once the constraint is lifted, the model internalizes "you are the loop."

Cost-sensitive users can have a strong model orchestrate and a weaker model execute: explicitly ask Claude to "default to selecting the most appropriate model for each step," with the strong model setting strategy and delegating specific steps to more economical models.

Prompt Injection refers to attackers hiding malicious instructions in content the agent will read (web pages, emails, code comments, documents), inducing the model to deviate from the original task and execute the attacker's intent. When combined with unsupervised agents, the risk is amplified: agents have file system, network, and command execution permissions, and an injected instruction like "delete all files" if complied with would have irreversible consequences. Anthropic's mitigation approach includes running classifiers on all traffic, distinguishing the trust boundary between "data" and "instructions," and enhancing the new model's ability to recognize suspicious content. But this is not absolute protection; in practice, the principle of least privilege should still be followed: limit the directories and tools an agent can access, require human confirmation for destructive operations, and treat externally scraped content as untrusted input. Only when verification and isolation mechanisms are in place is an unattended loop truly safe.

Graph Engineering: Draw Out the Process in Your Head

The last method addresses the problem of knowledge transfer. Most people's business processes exist only in intuition. The author himself, when breaking down "acquiring a customer," realized that this could be decomposed into about twenty SOPs, of which seventeen or eighteen could already be handed to AI.

The specific approach is to use HTML in Claude to draw a diagram for each workflow, annotating what each step does, why it's done, who does it (which AI, using what skills), and where human intervention is mandatory. AI itself doesn't need diagrams; it only needs Markdown files. Diagrams are for humans, to make clear where agents intervene and how outputs are formed. The author maintains a library containing all workflow diagrams and corresponding MD files, updating it directly when the business changes. [screenshots/19785_003.jpg] This visualization makes process evolution traceable.

Illustration:

The Same Logic Behind All Five Methods

Trimming instructions, defining outputs, probing capabilities, nesting agents, loop verification, visualizing processes—all six point in the same direction: the human's position in the system shifts from executor to definer. You provide direction, taste, and completion standards; the model handles paths and verification.

This also means the shelf life of best practices is getting shorter. Claude is already writing its own code, and today's approach may be obsolete in a few weeks. What's truly worth retaining isn't any particular set of prompts, but the habit itself: "regularly clear, retest, and rebuild as needed."

The smallest action to start today: pick a repetitive task, give it a final-state definition, and put it on a schedule.

One-line Summary

Delete verbose instructions, and use output specifications, loop verification, and agent orchestration to shift the human role from executor to definer.

Paragraph Summary

Based on a talk by Claude Code head Boris Cherny, the article proposes a subtractive approach contrary to "stacking prompts." Anthropic internally builds Claude Code using ablation—with each new model release, they first delete the system prompt and then add it back line by line—so users are advised to regularly clear CLAUDE.md, retaining only identity, goals, and completion standards. The core methods are defining output specifications rather than thinking steps, as evidenced by Bun completing a 530,000-line Zig-to-Rust rewrite in 11 days with one engineer and about 64 agents. The article also emphasizes the model's many unexplored capabilities, agent-managing-agent workflow orchestration, loop engineering with /goal and /loop for self-verification, and graph engineering using HTML diagrams to decompose human-AI division of labor. The common logic is that the human's position shifts from executor to definer.