The Demotion Ladder: A Year of Governing Claude Code

I started out pretty naïve. I figured if I just wrote down every convention I wanted Claude to follow, the model would treat the list like a checklist. And, for a short while, that actually happened. I’d spot a slip‑up in a review, scribble a rule into a doc, and the next run would be a little cleaner.

Fast forward to May 2025 – I’ve been running Claude on my own SaaS product, a fairly typical stack with about a thousand endpoints, generated API contracts, Excel/PDF exports, reminder‑style notifications, naming conventions, a page‑template system and all the inevitable exceptions. Fourteen months later the “rules” collection exploded: 18 separate files, each 250‑750 lines long, topping 5,000 lines of text. And that’s not even counting the architecture diagrams and process notes.

When I handed Claude a fresh feature slice – a CRUD module with a table, form, detail view and a couple of actions – the result was, well, an MVP at best. It ignored the endpoint hierarchy, missed the contract structure, bypassed the generated front‑end client, and the UI theme was all over the place. It didn’t reuse existing page templates or components, duplicated code, and sprinkled in hacks where proper handlers should have lived. Tests were missing or broken, and the whole thing wouldn’t even build. It felt like ten junior devs had each invented their own way of doing the same thing.

Now, if you dump a 5,000‑line rulebook on a junior engineer, they’ll flounder too. I was hoping a machine would at least be less clueless than a human brain, but the reality was harsher.

Anthropic’s own docs are blunt: bloated CLAUDE.md files make the model ignore your instructions, so you should prune aggressively, delete rules that are already followed by default, and turn the rest into hooks. The community echoes this – prose is advisory, hooks are deterministic, and you should write tests instead of long paragraphs.

I agreed with the advice, yet I was still stuck. “Convert it to a hook” is easy for one rule, but I had hundreds spread across dozens of files. Which ones should become hooks, and what price would that exactness cost?

My first hypothesis was simple: the sheer volume of rules crowded out the task‑specific context, pushing the model over its token limit. A quick sanity check – if Claude could load the entire rule set without any warning about missing tokens, I assumed I was safe. Turns out that wasn’t the whole story.

The most relevant controlled study I found was a May 2026 preprint that ran 1,650 Claude‑Code sessions across two codebases, varying rule‑file size, placement, architecture, and internal contradictions. Surprisingly, none of those factors changed compliance rates. The only thing that mattered was the within‑session effect: every extra function Claude generated dropped the odds of following a rule by about 5.6 %.

That paper’s largest file was 500 lines, a fraction of my 5,000‑line monster, so the “crowding” theory didn’t fully explain my woes. Three other insights lined up with what I’d observed.

1. Rules apply per unit of work. For a tiny task only a few rules are relevant, and Claude can juggle them. A vertical slice, however, pulls in naming conventions, contract hierarchies, theme guidelines, testing standards – all at once. I built a 68‑line hook that scanned the prompt and pulled only the docs matching the work type (backend, frontend, test). It narrowed the context, but the agent still wanted the whole rule set for that slice, so the problem merely shifted to re‑assembling the pieces later.

2. Compaction erodes detail. On a larger feature Claude iteratively “compacts” its output 20‑50 times before finishing. Each compaction loses nuances. I found myself spending another 50 k tokens after every round, reminding the model of the missing details. A June 2026 preprint measured the same phenomenon across 1,323 episodes: violations rose from 0 % with the full policy in context to 30 % after one compaction, and up to 59 % on some models. If the constraint survived the summary, compliance stayed at zero violations.

3. Prohibitions rot faster than positive directives. A later preprint (4,416 trials, 12 models) showed “never do X” compliance fell from 73 % at turn 5 to just 33 % by turn 16, whereas “always do X” stayed at 100 %. Almost all my rules were prohibitions, meaning I was fighting an inherent asymmetry.

Two caveats: most of the cited studies are preprints and haven’t been peer‑reviewed, and my own year‑long experience isn’t a controlled experiment. During those 14 months Claude released eight major updates, my harness added new primitives, the codebase grew richer with examples, and I got better at phrasing prompts and selecting hand‑offs.

Bottom line – massive rule piles, repeated compaction, and over‑reliance on negative phrasing cripple AI‑generated code. Switching to concise, positive hooks, refreshing the rule set after each compaction, and limiting rule scope to the current work slice rescued my workflow.