You've seen this happen: Someone makes a large, complex change involving multiple files, new dependencies, and refactored architecture. They deploy it. Something breaks. Where's the problem? Is it the new library? The refactored code? The interaction between components? They spend hours debugging, eventually reverting everything and starting over.
Now imagine a different approach: The same work is done as ten small changes, each committed separately. Each change is tested before moving to the next. When something breaks, you know exactly which change caused it—you revert that one commit and keep the rest.
The difference is small, reversible decomposition—breaking problems into small, independently verifiable steps that can be easily rolled back. This is the key to managing complexity in agentic workflows.
Human cognition has limits. We can hold about 7±2 items in working memory. When you make a large change:
Exceed these limits, and you make mistakes. You forget to test something. You miss an interaction between components. You create bugs you won't discover until later.
The cost of finding bugs grows exponentially with change size:
With 10 small changes of 10 lines each:
The insight: Ten small, tested changes are faster than one large change even before accounting for debugging—because you catch issues immediately, when context is fresh.
This principle is even more important with AI because:
Small decomposition lets you verify AI work incrementally, catching mistakes before they compound.
Think of it like building with Lego vs sculpting clay:
Small, atomic changes give you Lego-style work: each piece is independent, swappable, and doesn't affect the others when changed.
An atomic change is the smallest unit of work that:
Atomic: One logical change, one commit
Not atomic—too many concerns, hard to verify, hard to revert if partly broken.
Atomic: One concern per commit
Each commit can be tested independently. If JWT has bugs, OAuth still works.
Before accepting a change, ask:
If any answer is "no," decompose further.
Reversibility means you can undo a change without side effects. This is what enables safe experimentation—you can try something knowing you can always go back.
The "Revert, Don't Fix" Mindset: Beginners try to fix broken code by adding more code. Pros revert to the last working state and try a different approach. Reverting isn't failure—it's a strategic retreat that saves hours of debugging.
Git is designed for reversible changes:
Good commit boundaries create natural reversibility points:
If JWT has bugs:
Bad commit boundaries break reversibility:
Reverting d4e5f6g might reintroduce the bug. Reverting a1b2c3d loses authentication, refactor, and database changes together.
1. Feature Branches
2. Frequent Commits
3. Staging for Experimentation
Different problems require different decomposition approaches.
Build one complete feature at a time, across all layers:
When to use: Building features for users, when you need working functionality at each step.
Advantage: Each step produces visible, testable functionality.
Build one layer at a time, across features:
When to use: Building infrastructure, when changes to one layer won't break others.
Advantage: Each layer can be tested independently. Clear separation of concerns.
Build dependencies before dependents:
When to use: When features have clear dependencies.
Advantage: Never work on something that depends on unfinished code.
Write tests before implementation:
When to use: Complex logic with many edge cases.
Advantage: Each change is immediately verified by tests.
The essence of this principle: Many small iterations beat one large batch.
When working with AI systems, you need to guide them toward small, reversible changes.
Before any implementation, make decomposition collaborative:
This simple habit transforms decomposition from something you do alone into something you do with the AI. The AI often spots dependencies and edge cases you'd miss. And now you have a roadmap before writing a single line.
AI generates:
AI generates:
This pattern ensures:
Too fine-grained. Each commit doesn't make sense independently. Clutters history.
Fix: Group related tiny changes into one atomic change.
Two unrelated changes in one commit. Can't revert without losing both.
Fix: One concern per commit, even if it feels inefficient.
Intermediate states don't work. Can't revert to a working state easily.
Fix: Each commit should leave the code in a working state.
Software complexity grows faster than code size. A 1,000-line program isn't 10x more complex than a 100-line program—it's often 100x more complex due to interactions between components.
Small, reversible decomposition manages this complexity by:
Without decomposition, you're constantly fighting complexity. With it, complexity becomes manageable—one small step at a time.
Decomposition applies universally—whether you're building software or producing documents. In Claude Code, each step is one function and one commit. In Cowork, each step is one section or one file. The mechanism differs; the principle is identical.
In Cowork: When creating a long document, don't ask for the entire thing at once. Ask for the outline first (verify it). Then ask for section 1 (verify it). Then section 2. This way, if section 3 goes wrong, you don't lose sections 1-2.
The universal rule: Large tasks fail silently. Small tasks fail loudly. The smaller your steps, the faster you find and fix problems.
For a detailed comparison of how all seven principles map across both interfaces, see Lesson 9: Putting It All Together.
What you're learning: How to decompose complex problems into small, manageable steps. You're developing the skill of breaking work into atomic units that can be independently verified and reverted.
What you're learning: How to design good commit boundaries that create natural reversibility points. You're learning to structure your work so that each commit represents a coherent, revertable unit.
What you're learning: The practical difference between large batch and small iteration approaches. You're experiencing firsthand how small, reversible steps reduce cognitive load and increase confidence.
git reset --hard and git revert are powerful recovery tools—but they can also destroy work if used carelessly. Before running any reset command, always check git status and git stash any uncommitted work you want to keep. The "revert, don't fix" mindset only works if you have clean commits to revert to.