Raising Claude Code - Part 1: Concepts

It’s a long holiday in Japan, so I had time to write up how to actually “raise” Claude Code in a real environment. Since it’s long for one blog post, I’m splitting it into six.

Across these six parts, I’ll lay out the concrete methods for raising Claude Code in a real working environment. This is Part 1: Concepts.

Claude Code is not a junior engineer

Claude Code is smart. But not perfect.

Correct it verbally, and by the next session it remembers nothing.

A junior engineer learns from experience and internalizes it. Claude Code doesn’t.

👉 A different MIT student intern arriving every morning, with no memory of yesterday.

That’s the closest analogy.

In other words: teach it once, and it’s gone by the next session. So “raising it = writing it down.”

A one-shot verbal correction isn’t training — it’s venting. If you actually want it fixed, you have to convert that correction into one of three things on the spot: a rule, an automation, or an enforcement.

Four mechanisms for giving Claude Code persistent knowledge

There are four ways to carry knowledge across sessions:

• CLAUDE.md — a policy document injected into every turn
• Skills — procedure docs invoked via slash commands
• Hooks — scripts auto-executed on events
• settings.json permissions — allow/deny rules

Each plays a different role. The most important distinction is enforcement strength.

Strictly speaking there’s a fifth mechanism — auto memory, which lets Claude quietly save things it learns from conversation into files. But it sits on a different axis: the user doesn’t design it; Claude curates it on its own. For what you actively design, the four above are enough. Auto memory’s place is covered in Part 6.

”Persuasion” and “enforcement” are not the same thing

The four mechanisms split like this:

Persuasion (depends on whether Claude follows it)

• CLAUDE.md
• Skills

Enforcement (executed by the harness regardless of Claude’s judgment)

• settings.json permissions
• Hooks

This is the single most important point in the entire series.

“Enforcement” here doesn’t mean “stops dangerous things.” It means “runs regardless of what Claude decides.” It splits into two roles:

• Prohibition — permissions.deny physically blocks dangerous operations
• Automation — Hooks auto-run things like lint/format

If you write “rm -rf is forbidden” in CLAUDE.md, Claude will still change its judgment depending on the situation. If you really want something stopped, you have to physically block it with permissions.deny.

👉 Confuse persuasion and enforcement, and accidents happen.

Series overview

Here’s the order:

• Part 1 (this post): Concepts — the four mechanisms, persuasion vs. enforcement
• Part 2: Enforcement — permissions.deny for accident prevention; Hooks for automating quality checks
• Part 3: Persuasion — how to write CLAUDE.md, rule granularity
• Part 4: Extension — when to use Skills and Subagents
• Part 5: Subagent implementation — how to actually write a Subagent: role design, multi-agent coordination
• Part 6: Operations — the incident-driven improvement loop + where auto memory fits (final post)

This is also the order in which you actually introduce them in your own dev environment.

Wrap-up

Claude Code is not magic, but it’s not a junior engineer either. It’s a different MIT student intern arriving every morning, with no memory of yesterday.

That’s why “raising it = writing it down” works.

And the place you write things down has two layers: persuasion and enforcement. Get this distinction into your head first, and everything from Part 2 onward will land much more cleanly.

Next up: enforcement. We’ll start with using permissions.deny to physically block dangerous operations.