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: 10 minutes.
The 6-step loop
Every development session follows the same cycle, always in the same order. This discipline 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 pros and cons. You choose. Your domain knowledge makes the difference.
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. 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 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). 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 are 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 takes you from "I tinker with AI" to "I ship professional features at a pace nobody can match". Internalize it, it becomes automatic in 2-3 sessions.
The 4 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. Since 2026, four slash commands cover the full lifecycle of a session, learn them by heart.
/context, know where you stand
Before firing off a big instruction or deciding whether you need to compact, type /context (or /usage depending on your version). Claude shows the percentage of context window used, broken down by system prompt, loaded tools, history, and files read.
Concrete scenario: you just finished a 40-minute feature and hesitate to start the next one, you type /context to see if there's headroom left or if you need to compact first.
The reflex: run /context every 20 minutes or so, and systematically before starting a new phase of the cycle (new feature, new brainstorm).
The 3 thresholds to know: under 40%, you're comfortable. Between 40% and 60%, watch it. Above 60%, compact before attacking a new feature. Above 80%, red zone.
/compact, manage your context
Claude Code has a limited context window. The 2026 models (Opus 4.7, Sonnet 4.6, Haiku 4.5) expose up to 1M tokens in GA, but the longer the conversation, the more Claude "forgets" the early instructions. The "Lost in the Middle" phenomenon.
Concrete scenario: /context shows 62%, you run /compact before starting a new feature, Claude summarizes the history and frees up space.
The reflex: as soon as /context goes past 60%, run /compact. Claude summarizes the conversation, archives the non-essential details, and frees up space while keeping the key decisions.
The danger zone: past 80% context, Claude becomes noticeably worse. It forgets rules, makes inconsistent choices, quality drops. 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.
Concrete scenario: Claude just refactored a component and the page shows 12 console errors, you hit Esc Esc to roll back code + conversation in one move instead of debugging.
The reflex: hit Esc Esc (double Escape) or /rewind. Claude undoes the code changes AND rolls the conversation back to a save point. A giant Ctrl+Z: the code returns to its previous state, and so does the conversation memory.
Why /rewind beats manual fixing: 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. You gain 3x in speed compared to
debugging.
Walkthrough: a feature going off the rails
Picture this: you want to add a filter system to a task list.
- You brainstorm, plan, then run
Execute the plan. - Claude starts well, then decides to refactor your whole
TaskListcomponent to integrate the filters. It breaks pagination in the process. - You test
localhost:3000, the list is empty, the console spits 12 errors. Hot debugging would be a trap. - You hit
Esc Esc. Claude rolls back the code and the conversation, your repo returns to the state before the derailment. - You run
/contextto confirm you have headroom. 45%, clean. - You replan with more precision: "Add filters WITHOUT touching the existing pagination. Create a separate
TaskFilterscomponent that takestasksas props and returnsfilteredTasks." - You re-run execution. This time the scope is clear, Claude ships it cleanly in 15 minutes.
Total: 5 minutes lost on the first attempt, zero technical debt, zero frustrating debug session.
/resume, reconnect to an interrupted session
Your terminal crashed? You closed the window by accident? Your Mac rebooted mid-session? Before 2026, all the context was gone.
Concrete scenario: you reopen your laptop in the morning, you want to pick up last night's Stripe feature, you type claude /resume, pick yesterday's session from the list, Claude reloads everything.
The reflex: in a new terminal, type claude /resume. Claude lists your recent sessions with a summary of the last action. You pick the one you want, it reloads the conversation, the files read, the decisions made.
Bonus workflow: /resume is also perfect for picking up a feature you
started yesterday. You recover the progress state without having to re-explain
everything. Combine with /context right after to confirm the available
headroom.
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.