The second terminal

I usually work with two Claude Code sessions open at the same time. The first one implements the task. The second receives the finished diff and looks for what the first one missed.

I separate them because an agent can produce code that looks right, with green tests and a convincing summary, and still be wrong. The session that wrote the solution also has less distance from its own decisions.

Separate roles#

The first terminal is the builder. It takes the task, writes the code, and runs its own tests. The second is the verifier. It doesn't change production code; it starts from the diff and reviews the result independently.

That distance changes the review. The verifier didn't follow every choice the builder made and doesn't need to defend the chosen approach. It follows a short checklist:

• run typecheck, lint, tests, and build again;
• read every changed line instead of treating the summary as proof;
• repeat Lighthouse, contrast, and link audits when they are part of the task;
• check that every changed file belongs to the request.

After that review, I decide whether the work can become a commit or needs to go back to the builder.

Shared rules#

Both terminals receive the same project rules. AGENTS.md is the canonical file, mirrored in CLAUDE.md for tools that use it. The base has four principles:

## Base layer
 
1. Think before coding: don't assume, surface tradeoffs, ask
2. Simplicity first: the minimum that solves it, nothing speculative
3. Surgical changes: touch only what the request requires
4. Goal-driven: define the success criterion, loop until verified

Then come the rules specific to this site: settled decisions, anti-patterns, symmetric i18n, a preference for Server Components, design-system tokens, and the hot files that require confirmation before an edit.

Keeping these rules in the repository avoids relying on session memory. Every agent starts with the same constraints and the same definition of done.

Decide before implementing#

When a choice would materially change the result, I settle it before opening the diff. The builder asks one question at a time, explains its recommendation, and waits for a decision. Anything it can discover in the repository gets investigated first.

This reduces the chance of implementing one interpretation in full and learning at the end that the request meant something else.

What becomes an automatic safeguard#

Mechanical rules live in hooks and permissions, not reminders:

// .claude/settings.json
"deny": [
  "Bash(rm -rf *)",
  "Bash(git push --force*)",
  "Bash(git reset --hard*)"
]

The hooks confirm hot files before an edit and run lint and formatting after every write. The safeguard still works even when nobody remembers to mention it in the prompt.

One case that justified the workflow#

During a Lighthouse audit, every page cleared the 95-point threshold in every category. The verifier still opened the individual results and found two accessibility problems that the aggregate score did not make obvious. A code comment had a 3.74:1 contrast ratio, below the 4.5:1 required by WCAG AA. Three controls had visible text that differed from their accessible name.

One issue had zero weight in the score. The other only brought one page down to 96. Both passed the builder and the score, but showed up when the second session read the checks more carefully.

That is why I kept the second terminal. I read the agent's summary to understand what it tried to do, but I make the decision from the diff and the repeated checks.