Here's the payoff for all this planning work: it compounds. Each session builds on the last. The more context you create, the better Claude gets at helping you.
🔄 The Vibe-Coding Problem
Without planning, every session starts from zero:
- Session 1: Build something, hit problems
- Session 2: Try to fix it, forget what you did before
- Session 3: Start over because it's too messy
- Session 4: Repeat...
You're always reacting, never building momentum.
📈 The Compound Alternative
With planning and documentation:
- Session 1: Plan the project, document decisions, build foundation
- Session 2: Review docs, Claude understands context, build feature A
- Session 3: Review docs, build feature B (faster now)
- Session 4: Build feature C (even faster)
Each session is easier than the last because context accumulates.
📊 The Timeline: Session 1 vs Session 5
Here's what the difference looks like in practice:
| Session 1 (No Context) | Session 5 (With Context) |
|---|---|
|
Time to get started: 15-20 minutes Explaining project from scratch |
Time to get started: 2-3 minutes Claude reads Claude.md, immediately oriented |
|
Building a feature: Trial and error "Is this the right approach?" |
Building a feature: Confident progress "Following established patterns" |
|
Decisions: Starting fresh each time "Why did we do it that way before?" |
Decisions: Building on past reasoning "The docs explain our approach" |
|
Session productivity: Low → Medium Every session feels like starting over |
Session productivity: Medium → High Velocity increases over time |
💡 Real Example: Recipe App
Let's see how this plays out in a real project:
You plan the app structure, build the homepage and recipe display. You document: "Using a simple array for recipes. Will move to database later. Each recipe has: title, ingredients, steps, cookTime."
Claude reads your docs, understands the recipe structure, and builds search that works with your existing array. Takes 20 minutes instead of 45.
Claude suggests: "Should I add a 'category' field to the recipe structure we documented?" You say yes. It updates the structure consistently across all files.
Claude: "I see we're still using an array. Based on your Session 1 note about moving to a database, now might be the time—ratings would work better with a database backend." You hadn't even mentioned the database idea this session!
By Session 5, Claude isn't just following instructions—it's actively contributing based on accumulated project knowledge.
✨ The Compounding Effect
When you document what you learn and what you decide, you're not just helping future Claude sessions—you're helping future you. This is the "compound" in "compound engineering."
📝 What to Document
At the end of each session, consider capturing:
- What you built: A brief summary of what changed
- Why you made those choices: The reasoning behind decisions
- What's next: Where you left off, what to do next time
- What you learned: Anything that surprised you or took time to figure out
This can be as simple as a few bullet points in a README or a dedicated notes file.
Session Notes Template
A simple template for documenting each work session
📄 Preview PDF
📝 Quick Documentation Example
Here's what simple, effective documentation looks like:
That's it. Five minutes of writing that saves 30 minutes next session.
⚡ Pro Tip
Ask Claude to help: "Based on what we built today, write a session summary for my project notes." Claude can draft the documentation, then you refine it.
🚀 The Claude.md File
There's a special file called Claude.md (or CLAUDE.md) that Claude Code looks for automatically. If it exists in your project folder, Claude reads it at the start of every session.
This is powerful: you can put project context, preferences, and instructions there, and Claude will remember them every time.
We'll dig deeper into this in Module 3.
💡 Start Simple
You don't need elaborate documentation systems. Even a simple "Notes from last session" section in your README creates compounding value.
🔮 The Long Game
Imagine working on a project for weeks or months. With good documentation:
- You can pick up where you left off, even after a break
- Claude understands your project's history and patterns
- New features build naturally on existing foundations
- Problems are easier to diagnose because context is clear
This is how professional software development works. Planning and documentation aren't bureaucracy—they're infrastructure for building bigger things.
📚 Resources & Further Reading
- Compound Engineering (Every.to) Dan Shipper's original article that defined this approach
- Compound Engineering Plugin (GitHub) Every's open-source tools for this workflow
- Claude Code in Action (Anthropic Academy) Anthropic's official course on Claude Code features
💭 Pause & Reflect
Before moving on to Module 3, take a moment to consider:
- Think of a past project where you kept starting over. How might documentation have helped?
- What's your current approach to documenting personal projects? (Honest answer!)
- What's the smallest documentation habit you could start with?
- How excited are you about the compounding effect? Skeptical? Eager?
🎯 Module Summary
In this module, you learned:
- The difference between planning and building prompts
- How to ask Claude to research before it acts
- How to review and refine plans
- Why this work compounds over time
Next, we'll put this into a concrete workflow: the Compound Engineering Loop.
🎉 Module 2 Complete!
You've got the planning mindset. Now let's turn it into a repeatable process.
Module 2 Complete • Up Next: Module 3 – The Compound Engineering Loop