Course-correcting

Claude will go off track. This is not a failure of the tool. It's a normal part of working with any system that makes autonomous decisions. The question isn't whether it happens — it's how fast you catch it and how cleanly you recover.

I've had sessions where Claude nailed a 20-file refactor on the first try. I've had sessions where it started rewriting my auth middleware after I asked for a CSS change. Both are part of the deal. What matters is your recovery speed.

The escape hatch

Press Escape. That's your emergency brake.

Claude stops after the current tool call completes. It won't finish mid-file — it completes the action it's on (a file write, a command) and then stops. You get control back immediately.

This is the most important muscle memory in agentic coding. The moment you see Claude heading in the wrong direction — wrong file, wrong approach, unexpected refactor — hit Escape. Don't wait to see if it self-corrects. It won't.

Git as your checkpoint system

Before any major change, commit. This isn't optional — it's your safety net.

If you committed before the task started, recovery is trivial. git diff shows you exactly what Claude changed. git stash sets aside the changes for later review. git checkout . reverts everything. You're back to a known-good state in seconds.

# See what changed
git diff

# Option 1: Keep partial work, fix the rest
git add src/components/login.tsx    # keep the good parts
git checkout src/middleware.ts      # revert the bad parts

# Option 2: Revert everything
git checkout .

# Option 3: Stash for later review
git stash

This is why I commit frequently when working with Claude. Not because I'm worried about losing code — because I want clean restore points. Every commit is a checkpoint I can return to.

The two corrections rule

Here's a pattern I've learned the hard way.

If you've corrected Claude twice on the same issue and it keeps doing it, stop. The problem isn't in the conversation. The problem is upstream — in the spec, or in CLAUDE.md.

Claude doesn't have a grudge. It's not ignoring you. It's following the patterns it sees in the context. If it keeps making the same mistake, it's because something in the context is telling it to. Maybe the codebase has conflicting patterns. Maybe your CLAUDE.md is ambiguous on this point. Maybe the spec didn't constrain this behavior.

Correction 1: "Don't import from @jd/db/server in client
components — use @jd/db/browser instead."

Correction 2: "I told you — use @jd/db/browser here,
not @jd/db/server. This is a client component."

Correction 3: STOP. The problem is upstream.

Fix: Add to CLAUDE.md:
  "Never import @jd/db/server in client components —
   it uses next/headers and will break."

After two corrections, close the conversation. Fix the upstream instruction — the CLAUDE.md rule, the anti-pattern list, the spec constraint. Then start fresh. A new session with a corrected instruction is faster than fighting a confused context.

When to abandon a session

Sometimes the context is too polluted to recover. Claude has been generating bad patterns for several turns, your corrections have muddied the conversation, and the agent keeps oscillating between approaches.

This is when you use /clear and start fresh. Or close the terminal and open a new session.

A new session with a better spec takes 30 seconds to set up. Debugging a confused session takes 15 minutes and usually fails anyway. I abandon sessions without guilt. The work isn't lost — it's in git.

The de-sloppify pattern

This is an ECC concept that changed how I handle quality issues.

Negative instructions — "don't do X," "never use Y" — are unreliable. Claude processes them, but they have diminishing returns as context grows. The more "don'ts" you stack, the more likely some get dropped.

The better approach: instead of telling Claude what NOT to do, run a separate cleanup pass. A second agent (or a second prompt in the same session) that reviews the output specifically for quality issues.

# Phase 1: Implementation
> "Build the user profile page. Follow the spec."
[Claude builds the page]

# Phase 2: Cleanup pass
> "Review the code you just wrote. Check for:
   - Any direct imports from @jd/db/server (should be @jd/db/browser)
   - Missing error boundaries
   - Console.log statements
   - Components missing loading states
   Fix anything you find."

The implementation agent focuses on building. The review agent focuses on quality. This separation is more reliable than hoping a single agent remembers every constraint while also solving the implementation problem.

The recovery workflow

When things go wrong, follow this sequence every time:

1. Escape — stop Claude immediately
2. Check the diff — git diff to see what changed
3. Decide — keep partial work, or revert to the last checkpoint
4. Refine — update the spec or instruction based on what went wrong
5. Continue or restart — resume with refined direction, or /clear for a fresh session

This takes about 60 seconds once you've done it a few times. It becomes automatic — like hitting Ctrl+Z. You don't think about it. You just recover and keep moving.

The developers who struggle with agentic coding aren't the ones whose agents make mistakes. Everyone's agents make mistakes. It's the developers who don't have a recovery workflow — who sit there watching Claude go off the rails for five minutes before deciding to act. Build the reflex. Press Escape early. Recover fast.