DevOps Peach

Claude Code in Practice · Long projects – Context, progress and shipping · Lesson 1 of 3

Context and plan mode: keeping quality high in long sessions

After an hour, Claude starts forgetting early decisions. That is the context window filling up, not the model getting worse. What we watch, when we clear, how we compact, and why we plan before every big change.

Practice interactively →

Have you noticed that after 40 minutes of good work Claude starts contradicting a decision you made at the start? Imagine a meeting where your colleague suddenly forgets the first hour but remembers the last ten minutes. That is a full context window.

What the context is

Everything in the conversation (CLAUDE.md, your messages, files Claude read, command output, its own replies) is sent to the model on every turn. The window has a fixed size; /context shows how full it is and what is taking space. As it fills up, the earliest details get less attention, and when it is full Claude Code compacts the conversation into a summary.

This course was written in one very long session. It ran out of context more than once and continued from a summary. What survived each time were the standing rules written explicitly in the summary (reply in Vietnamese, placeholders only, never commit unless asked). Details that were never written down had to be found again.

Habits that keep it under control

Plan mode: three rounds before building

Press Shift+Tab until you see plan mode. Claude can read and think but cannot edit. We use three rounds for anything bigger than a small fix:

  1. Describe the goal and constraints. "Make the Claude course bilingual with a language switch; only this track; keep the other tracks as they are."
  2. Read the plan and push back at least once. Which files will change? What happens to existing progress? What will you check at the end?
  3. Approve and build. The plan is now in the context and the edits follow it.

Five minutes of plan review regularly saves an hour of undoing a wrong approach. It also gives the next session something concrete to read if this one runs out of context.

When to stop and restart

If Claude keeps making the same mistake after you corrected it twice, the context is probably working against you. Write down what you learned (in CLAUDE.md or the work log), /clear, and start again with a better first message. A fresh session with a good brief beats a tired session with a long history.

Use case: Surviving a context reset mid-task

The situation

The task: give every case study's "How it works" section a full architecture diagram like the module maps. Twenty-two diagrams, a shared renderer, Playwright checks. The session had already done the Argo CD track, ten new case studies and a roadmap redesign. The context ran out just after the renderer had been read and before any diagram existed.

What the summary contained

The automatic summary kept, in order:

Section What it said
Standing rules Placeholders only, never copy source/raw, reply in Vietnamese, commit only when asked
Key technical concepts The map format: zones, nodes, edges, steps on a 1000×560 canvas
Files and functions renderMap, mdBar, mdGo and their line numbers
Pending work "22 maps; generalise the renderer; verify light, dark, mobile"
Next step "Refactor renderMap into a reusable mount, then write the data"

What happened next

The new context started from that summary. Claude read the renderer again (it was not in the summary in full), wrote site/casemaps.js with 22 maps, wrote a small validator that flagged overlapping nodes and lines crossing other nodes, fixed the five problems it found, and checked every case in a headless browser.

What we would have lost without it

What we took away

Practice interactively →