I Set Up My AI Wrong for 6 Months. Here’s How I Fixed It.

My manager asked me how I configured Claude Code. I said, “I just write more Skills.” She didn’t fire me, but she should have. Because I was doing it exactly backward.

For half a year, I treated my AI coding assistant like a magic genie. I stuffed every instruction into a single massive prompt file. I assumed more context meant better results. I was wrong. So wrong that my AI started ignoring critical instructions, wasting tokens, and gradually becoming useless in long sessions.

Then Anthropic’s official team published a guide on how to actually configure Claude Code. It was like reading the answer key to a test I’d been failing. The whole system clicked. And I realized: most people are configuring their AI like it’s 2023, when the real frontier is learning to architect context like a distributed system.

Here’s what I learned. And why it matters more than any prompt trick you’ve seen.

The Hierarchy of AI Configuration

There are seven ways to configure Claude Code. But the mistake everyone makes is treating them as interchangeable. They’re not. They form a hierarchy—a memory system, a skill set, and a safety net—and putting the wrong thing in the wrong place breaks everything.

The seven levers are: CLAUDE.md, Rules, Skills, Subagents, Hooks, Output Styles, and Append System Prompt. Each one differs in three critical dimensions: when it loads, whether it survives context compression, and how many tokens it costs.

If you get those dimensions wrong, your AI won’t just be inefficient. It will silently ignore you.

CLAUDE.md: The Project Memory, Not the Encyclopedia

CLAUDE.md is a file in your project root that loads at session start and stays forever. It’s invincible. It never gets compressed away. But here’s the trap: every line in CLAUDE.md costs tokens on every single task, even when it’s irrelevant.

I stuffed mine with deployment runbooks, code review checklists, and security audits. Then I wondered why my AI’s instruction-following degraded in long sessions. The answer was obvious: I was forcing it to carry a 500-line encyclopedia for every trivial frontend tweak.

The fix is simple. CLAUDE.md is for facts, not processes. Build commands, tech stack, directory structure, naming conventions—those are facts. Deployment workflows, code review steps, release procedures—those are processes. They belong elsewhere.

Rules: The Targeted Constraint

Rules live in .claude/rules/ and they’re the scalpel to CLAUDE.md’s hammer. The killer feature is path scoping: you can say “this rule only applies when Claude reads src/api/**.”

This is where you put your database conventions, your Zod validation requirements, your testing standards. But only for the files that actually need them. Context is a budget, not a library. Spend it where it works.

When should you use a Rule instead of a subdirectory CLAUDE.md? When a constraint needs to cross directory boundaries. If every .test.ts file needs a specific testing convention, a Rule with a path pattern is cleaner than scattering CLAUDE.md files everywhere.

Skills: The On-Demand Workflow

Skills are the most underrated feature. They live in .claude/skills/ and they load only when triggered. At session start, Claude reads just the name and a one-line description. The full content only loads when you type /code-review or the AI detects it needs that skill.

This is where your deployment runbooks, security checklists, and component creation templates belong. They take zero tokens until they’re needed. You can define fifty skills. They’ll cost you nothing until you call one.

The trade-off: during context compression, triggered skills are re-injected based on a budget. The earliest triggered skill gets dropped first. So don’t trigger five skills in one session. Pick the one that matters.

Subagents: The Isolation Chambers

Subagents run in their own context window. Completely separate. The main session never sees their intermediate work—only the final result. This is a superpower.

Use Subagents for tasks that generate massive intermediate output: deep codebase searches, log analysis, dependency audits, large-scale refactoring. These tasks can produce tens of thousands of tokens of noise. Let them burn their own context budget, not yours.

Subagents can also nest up to five levels deep. You can orchestrate hundreds of parallel agents for complex migrations. The /batch command in Claude Code is essentially a Subagent factory.

The choice between a Skill and a Subagent is simple: if you want to watch and intervene, use a Skill. If you only care about the result, use a Subagent.

Hooks: The Deterministic Guardrails

Everything above is a suggestion. The AI might follow it. It might not. Especially in long sessions, after compression, or when faced with prompt injection. You cannot trust a probabilistic model with deterministic safety requirements.

Hooks are different. They’re not instructions. They’re automation code. They fire on specific lifecycle events—before a tool call, after a tool call, before context compression—and they always execute. The AI doesn’t decide whether to obey. It’s not asked.

The canonical example: running Prettier after every file edit. If you put that in CLAUDE.md, the AI might do it. If you put it in a Hook, it always does it. No memory, no decision, no failure mode.

But the real power is in safety. “Never delete database migration files” is a promise you cannot trust a language model to keep. A Hook that checks every tool call and exits with code 2 if it detects a migration deletion is a promise you can trust. Pair it with organizational permissions, and you have real security.

This is the same principle as fail-closed design. Claude Code’s internal tool system treats every tool as dangerous by default, unless it explicitly declares itself read-only. Safety shouldn’t depend on the AI’s mood.

The Twist: Less Configuration Is More

Here’s what I didn’t expect: after learning all seven levers, my Claude Code setup actually got smaller. My CLAUDE.md went from 400 lines to 40. My Skills folder grew, but most of them sit idle. My Hooks handle the critical guardrails. And my AI actually works better.

The mistake I made—and the mistake I see everywhere—is treating AI configuration as a writing exercise. You write better prompts, you add more instructions, you assume more context equals more reliability. The opposite is true. AI configuration is an architecture exercise. You’re designing a memory hierarchy, a context budget, and a safety system. The best prompt is the one that doesn’t need to exist.

So stop asking “What should I write?” Start asking “What should my AI remember, what should it learn on demand, and what should never be left to its discretion?”

That’s the difference between using an AI tool and building an AI system. And it’s the difference between getting fired and getting promoted.