Deep dive · Jump here anytime when you want more on this idea
Compounding Engineering Patterns
How your workflow gets faster every week
After this, you'll be able to run the four-step codify-loop (plan, delegate, assess, codify) and write rules with provenance that make every next session start ahead of the last one.
Before you start
Before diving in, complete Scaling Context Across Projects so you understand the retrieval and structured-output patterns this lesson turns into compounding habits.
The idea
Your AI does not remember anything between sessions. None of it. Every new chat starts from zero. Level 6 is about accepting that and building around it, so the sessions you have already done make the next one better instead of you re-explaining your preferences forever.
- NoticeFind the moment where this lesson applies.
- Compounding Engineering PatternsApply the lesson move to one real task.
- ProveMove on only when the check passes.
The loop is four steps: plan the task, hand it to the agent, evaluate the output, then write what you learned in a place the model reads next time. That last step is codification. If you skip it, you restart from the same baseline every session. If you do it, your rules file after 30 sessions looks nothing like it did after 3.
A mature CLAUDE.md has provenance. Every rule traces back to a real session failure or success, not a speculative best practice you wrote in one sitting. 'Prefer functional style' is weak. 'Never import moment.js, we removed it in PR 438 and the agent keeps re-adding it' is strong. The difference is whether the rule came from something that actually happened.
Three numbers tell you if your system is compounding or just habitual: acceptance rate (how often you use AI output without rewriting it), iteration count (exchanges to get usable output), and codification rate (session learnings that make it into your rules file). If acceptance rate is not trending up after 10 sessions, you are accumulating rules, not compounding.
Here is the before and after: Session 1 CLAUDE.md: 4 lines, generic style preferences. Session 32 CLAUDE.md: 28 lines, every rule sourced from a real mistake. 'Never suggest moment.js (removed PR 438).' 'All API responses wrap in ApiResponse<T> (see src/types/api.ts).' 'useQuery not useState for server data (3 bugs traced to this).' Acceptance rate climbed from 51% at session 5 to 84% at session 32. The model did not improve. The rules file did.
Try it (5 min)
Watch out for
- Skipping the codify step when the session went well. Smooth sessions produce the most durable rules because you are encoding what already works.
- Writing the rule the next day. The 90-second window is before you close the editor. After that, the specifics fade and rules become vague.
- Codifying observations as journal entries instead of instructions. 'The model tends to re-introduce deprecated packages' is a note. 'Never use aws-sdk v2, use @aws-sdk/client-* v3 modules only' is a rule.
- Treating speculative best practices as if they were rules. Anything you wrote without a real session behind it is filler taking up tokens.
Paste this into Claude
I just finished an AI-assisted session where I worked on [describe the task: what you asked for, what the model produced, what you accepted or rewrote]. Walk me through the codify-loop on this session. (1) What was the plan I started with? (2) How did I delegate it (prompt structure, files I pasted, instructions I gave)? (3) Assess the output: where did it land between unusable and accepted-as-is? (4) Codify: write one rule for my CLAUDE.md based on this session. The rule must be a direct instruction (not a description), specific enough to apply without follow-up questions, and traceable to a real moment in this session. Show the rule as a single line I can paste in.
What good looks like
- Each of the four loop steps has a concrete answer tied to this specific session, not a generic checklist
- The codified rule is a direct instruction (imperative voice), not a description of what happened
- You can name the exact moment in the session that generated the rule (provenance test)
- The rule is in your CLAUDE.md before you close the editor today
When this breaks
- Breaks when you treat CLAUDE.md as documentation instead of standing instructions, because the model reads it as context every session and acts on it literally, so a stale or speculative rule fires on tasks it was never meant to apply to.
- Breaks when codification rate stays high (above 50%) for more than a month, because rules accumulate faster than they can settle into model behavior, and conflicts between newer and older rules turn the file into noise.
AI can help with this
Use AI to apply this lesson to your current work. Share your situation, ask for one concrete next step, and check the answer against this test: Write one CLAUDE.md rule from your most recent session that names a specific package, pattern, or behavior, traces to an exact moment in that session, and is a direct instruction the model could follow without clarification.
You can now
Write one CLAUDE.md rule from your most recent session that names a specific package, pattern, or behavior, traces to an exact moment in that session, and is a direct instruction the model could follow without clarification.
Key takeaways
The model forgets everything between sessions. Codification is the only mechanism that makes prior sessions improve the next one, and rules with real provenance are the only kind that compound.
- Codification is the habit: write one rule after every significant session, before you close the editor
- Rules with provenance (from real failures) compound. Speculative rules written in one sitting do not
- Track acceptance rate over 10 sessions. Flat rate means accumulating rules, not compounding
- Prune stale rules periodically. A CLAUDE.md that has not been audited becomes context poisoning.