Knowing when to stop

Build sessions drift. You ask for a fix, then another, then a refactor on top of that, then a different approach to the refactor — and an hour later you don’t know if you’ve made forward progress or you’re walking in circles.

The skill is reading the signal early.

If you can’t say what’s still wrong in one sentence, you’re either done or stuck. Both have the same next move: stop.

Two flavors of “done”

Shipped done. It works. You can read the code. You can explain in one sentence why this change exists. The diff is no bigger than the task required. Tests (if there are any) pass. You’re confident enough to commit.

Stuck done. It works — technically. You’re not sure why. The diff is twice as big as you expected. There’s a piece you can’t quite explain. You’ve stopped really reading the diffs. You’re going to commit anyway because you don’t want to start over.

Stuck done ships bugs. Stuck done is how a 10-line fix turns into a 200-line surprise next month. The fix is recognizing it: when you’re tempted to ship something you can’t explain, that’s the signal to start fresh, not push through.

Signs you’re thrashing

In rough order of reliability:

• Each new prompt is shorter and vaguer than the last. (“just make it work”)
• You’re re-asking the same thing in different words.
• You’ve reverted the same change two or three times.
• You’ve forgotten what the original task was — you’d have to scroll up to check.
• The diff is growing in directions you don’t remember asking for.

Any one of these alone is fine. Two together is a strong signal to stop. Three is the alarm.

The reset move

The reset isn’t quitting. It’s:

1. Decide what the actual goal was. Write it down somewhere — even just out loud.
2. Note where the current state is (commit it, or note which file is in what shape).
3. Start a new chat. Bring just the file and the goal. Drop everything else.

This is a gift, not a failure. A fresh chat with a clean prompt often resolves in three turns what fifteen turns of drift couldn’t.

The three-question check, before you commit

Before you call the change done, ask yourself three things:

1. Does it actually work? Run it. Don’t trust “the diff looks fine.”
2. Can I read it? Open the file. Read the whole edited region.
3. Can I explain why this change, in one sentence? If you can’t, the change might be doing things you didn’t intend.

Yes to all three: ship it. No to any: not done.

What’s next

That’s the level. You can ask Claude to change real code, read the diff, push back when it’s almost right, show evidence instead of describing it, do cross-file work that would’ve taken hours, back out cleanly, and recognize when to stop.

But you’ve been doing all this in default permission mode — clicking allow once every time. That works while you’re learning. It won’t scale. Level 6 — Trust & safety is the next door: when to widen the gate, when to keep it narrow, and what Claude should never touch without thinking first.