2026-05-28

Claude Code as a System, Not a Prompt Box

Arpan Patel’s piece is interesting because it treats Claude Code the way serious developers eventually do: as infrastructure, not as a chat toy. The article’s real argument is that the quality jump comes from compounding setup — project memory, local memory, skills, subagents, MCPs, and tight feedback loops — not from better prompting in isolation.

Key Points

Claude Code is framed as an autonomous agent that needs guardrails, verification, and a project-specific operating system.
The biggest workflow shift is to explore, plan, then code:
- use plan mode for read-only investigation,
- get a plan,
- then execute,
- and re-plan if implementation drifts.
The author emphasizes verification loops: Claude should be able to check its own work, and Boris Cherny says that can yield a large quality improvement.
A strong pattern is to reference exact files or pipe exact data instead of vaguely describing problems.
The article argues for delegation over pair-programming: give Claude a crisp brief and let it work.
One especially practical habit is to tell Claude to update CLAUDE.md after mistakes, so the system learns from its own failures.
The .claude directory is presented as a layered configuration system, with:
- project scope in the repo,
- global scope in ~/.claude/,
- shared vs private files,
- and different mechanisms for commands, agents, skills, and rules.
CLAUDE.md should be short and high-signal:
- only rules that prevent real mistakes,
- no tutorials,
- no broad documentation,
- no style fluff.
The article highlights the Claude Code team’s own CLAUDE.md, which is extremely minimal:
- use bun,
- run typecheck,
- run tests,
- lint before commit,
- follow a pre-PR ritual.
The author calls this compounding engineering: PR feedback should feed back into CLAUDE.md, so the project gets better at avoiding repeated mistakes.
CLAUDE.local.md is pitched as a private daily driver:
- store recurring review feedback,
- store personal habits to correct,
- prune it once habits become automatic.
Skills are described as a way to turn Claude from a general agent into a specialized project assistant:
- they live in folders,
- can have helper files,
- load progressively,
- and are better for new work than ad hoc commands.
Custom subagents and plugins expand the system further, with examples like review and workflow automation.
The article also points to underused commands like /goal, plus MCPs as power tools for real workflows.
A recurring theme is that Claude Code gets better when you design for:
- memory,
- separation of concerns,
- reusable expertise,
- and explicit verification.

My Take

What strikes me is how unglamorous the winning advice is. There’s no magic prompt here — just careful system design, and honestly, that’s exactly why it feels credible. I think a lot of people overestimate “prompting skill” and underestimate the value of having Claude repeatedly see the same narrow, correct rules in CLAUDE.md or a well-shaped skill.

The CLAUDE.local.md idea is the most immediately useful thing in the article, at least to me. I’d actually try that right away: collect the comments reviewers keep making, separate them from my own habits, and prune aggressively once they become muscle memory. That sounds far more effective than trying to remember every bit of feedback manually.

I’m also intrigued by the “let Claude write rules for itself” idea. That might sound a little too self-referential at first, but it makes sense: if the model keeps making the same mistake, you want the corrective rule captured at the system level, not buried in your memory. I’d be curious whether this works best in smaller, fast-moving codebases or in huge monorepos where the rules can easily sprawl.

The one thing I’d watch carefully is complexity creep. Skills, agents, rules, local overrides, MCPs, slash commands — that’s a lot of moving parts. I think the article is right that they compound, but only if you stay disciplined about keeping CLAUDE.md short and pushing detail into the right layer. Otherwise the whole setup might become its own maintenance burden.

Still, the core takeaway is strong: Claude Code becomes much more powerful when you treat it like a system that learns your project, not a chatbot that answers your prompts.