What this chapter teaches you: the 6-step development routine I use in every session. Once internalized, it becomes a reflex and your build speed is multiplied by 10. Reading time: 8 minutes.
The 6-step loop
Every development session follows the same cycle, always in the same order. This discipline is what guarantees quality and speed.
Step 1, brainstorm (5 min)
Goal: explore the options before committing.
"Brainstorm a [your feature] system for [your project]. Context: [why you want it, what problem it solves]."
Claude explores 3-4 approaches and compares the pros and cons of each. You choose. This is where your domain knowledge makes the difference, you know what's best for your users.
Tip: even for features that seem simple to you, brainstorm first. Claude often spots edge cases or opportunities you wouldn't have considered.
Step 2, plan (10 min)
Goal: turn the choice into an action plan.
"Write the implementation plan for the approach we picked."
Claude produces a task-by-task plan with the files involved and the verification commands. You review and validate. It's your last checkpoint before execution.
What to check in the plan:
- Is the order of tasks logical?
- Is anything obvious missing?
- Is the scope reasonable (not too ambitious for one session)?
Step 3, execute (20-40 min)
Goal: Claude codes, you supervise.
"Execute the plan."
Claude works task by task, autonomously. Between each step, it automatically runs the checks (typecheck, lint) to make sure the code is valid. If a check fails, it fixes it before continuing.
During this time, you:
- Watch the progress in the chat
- Step in if Claude asks you a question
- Don't touch anything in the files, let it finish
Pitfall: don't interrupt Claude in the middle of a task. If you have a correction, wait until it's done with the current step. Interruptions can create inconsistencies.
Step 4, check visually (5-10 min)
Goal: test in the browser.
Open localhost:3000 and test it yourself. Claude doesn't see your screen. You're the final tester.
Here's what you check:
- The feature works as expected (happy path)
- Error cases are handled (bad input, missing data)
- The design is consistent with the rest of the app
- Responsive works (shrink the window to simulate mobile)
- Texts are in the right language with the correct accents
If something's off, say it precisely:
"The button is too small on mobile, the text overflows the card on the right, and the 'Draft' badge color should be gray instead of blue."
Step 5, review and commit (5 min)
Goal: validate the quality and save.
/review→ Claude re-reads all the modified code and flags:
- Potential bugs
- Security flaws (e.g. data exposed client-side)
- Inconsistencies with the rest of the code
- Dead or useless code
/commit→ Claude analyzes the changes and creates a clean Git commit with a descriptive message. You no longer need to write commit messages.
Why review matters: even though Claude wrote the code, it can contain
subtle errors. The /review command brings a "fresh eye" to the code, like
asking a colleague to read your work. On Panettone, I have a whole commit of
fixes found by /review.
Step 6, save the context (2 min)
Goal: prep the next session.
"Update the project memory with the decisions from this session."
Claude saves:
- The architectural decisions made and their rationale
- Patterns confirmed as working
- Errors encountered and their solutions
- The project's progress state
The next session will start with all that context.
Typical session timing
| Step | Duration | Who does what |
|---|---|---|
| Brainstorm | 5 min | Claude proposes, you choose |
| Planning | 10 min | Claude writes, you validate |
| Execution | 20-40 min | Claude codes, you supervise |
| Visual check | 5-10 min | You test in the browser |
| Review + commit | 5 min | Claude reviews and saves |
| Memory | 2 min | Claude updates the context |
| Total | 45-70 min | 1 complete feature shipped |
The full loop: Brainstorm → Plan → Execute → Check → Review/Commit → Save the context. Repeat for each feature. In an 8-hour day, you can ship 6 to 10 complete features.
When to skip steps?
The full cycle is ideal for medium-to-big features. For small tweaks, adapt:
| Type of task | Steps to follow | Example |
|---|---|---|
| Simple bug fix | Execute → Check → Commit | "The 'Save' button doesn't work" |
| UI tweak | Execute → Check → Commit | "Increase the spacing between cards" |
| Medium feature | Plan → Execute → Check → Review → Commit | "Add a status filter on the list" |
| Major feature | Brainstorm → Plan → Execute → Check → Review → Commit → Memory | "Full Stripe payment system" |
Takeaway: the discipline of the 6-step cycle is what takes you from "I tinker with AI" to "I ship professional features at a pace nobody can match". Internalize it and it becomes automatic in 2-3 sessions.
The 3 survival reflexes
These reflexes come from the best practices shared by Boris Cherny (creator of Claude Code) and the community. They make a massive difference in the quality of long sessions.
/compact, manage your context
Claude Code has a limited context window. The longer the conversation, the more Claude "forgets" the early instructions. It's the "Lost in the Middle" phenomenon.
The reflex: watch the context percentage (visible in the status line or via /context). When you go past 60%, run /compact. Claude summarizes the conversation and frees up space.
The danger zone: past 80% context, Claude becomes noticeably worse. It forgets rules, makes inconsistent choices, and quality drops. This is what the community calls the "dumb zone". NEVER let context go past 80% without compacting.
After a /compact: re-read the key files for your current task. The summary is good but not perfect, re-reading the files restores the precise context.
/rewind, go back
Sometimes Claude heads in the wrong direction: bad technical approach, code that breaks everything, or cascading bugs. Don't fix it in the same context, the context is already polluted by the bad approach.
The reflex: hit Esc Esc (double Escape) or /rewind. Claude undoes the code changes AND rolls back the conversation. It's like a giant Ctrl+Z.
Why /rewind > fixing manually: when Claude fixes a bug it just created, it has the wrong instructions in memory. With /rewind, it starts from the right context and takes a different path. It's 3x faster than debugging.
Commit often
The creator of Claude Code recommends committing at least once an hour, as soon as a task is done. Why?
- Each commit is a save point you can roll back to
/rewindbrings you back to the last commit, the more you commit, the tighter the safety net- It's also a mental signal: "this task is done, I'm moving to the next"
After each feature or fix:
/reviewthen/commit. No need to wait until you've finished 3 features.