Don't drown: make planning a reflex

1. Plan — not "when things get hard", but always

Opening the task, Tommy habitually thinks out loud:

— The task seems simple enough. We can do without a plan here, just edit it right away. I usually turn the plan on for hard stuff, when I can tell I’m going to get tangled up.

— There, I caught you," Alex replies. — "When I remember," "when it’s hard." And you remember the plan mode — the one from the trust-wheel level?

— Right. That’s when the agent first lays out the intent — what it’ll touch, in what steps — and waits until I approve. And it doesn’t change anything until I say so.

— Exactly. The thing is, when you reach for it matters. You pull it out only occasionally, for scary stuff. But you should use it always.

— For everything? Even for nonsense?

— For any non-trivial task — before the first edit. Not because an incident scared you, but because that’s how a pro works. Today we’re turning plan from "I remember it sometimes" into a reflex.

Tommy snorts — and, in fact, he does know the mode, but on simple tasks he still jumps straight in without a plan. An old swindler’s habit of cutting corners where "it’s obvious anyway".

— What’s the point? — he still resists a bit. — For a trifle, the plan is an extra step. I waste time, and get nothing out of it; I would have fixed it anyway.

— Zero — as long as the trifle really is a trifle, — Alex replies. — But remember how many times a "simple fix" turned out not so simple and dragged the neighboring stuff along. Half of your past incidents started with "it’ll just take a minute." A plan on a trifle costs you thirty seconds. Skipping the plan on a "trifle" that turned out not to be a trifle cost you a whole night. That’s the math.

Tommy can’t find what to object to. Because that night did start with "it’ll just take a minute".

2. Bake the plan in by default: defaultMode: plan

— And so you don’t have to rely on "I’ll remember", you can bake the plan right into the project, — Alex shows the setting. — Put one line in the project settings file, .claude/settings.json, and every session starts in plan mode automatically.

// .claude/settings.json
{
  "permissions": { "defaultMode": "plan" }
}

— It’s the same file where your project rules and permissions live, — Alex explains, spelling it out so Tommy doesn’t drown. — defaultMode means "default mode," the starting point for everything. Set it to plan — and the agent won’t rush in and edit right away; it will first lay out the intent. You didn’t press anything, and it is already in planning mode. Same mechanism you know from the "trust wheel," nothing new there. The new part is that now it is enabled always, on its own.

Tommy gives the agent the final task — as usual, in plain words:

Fix the accrual in reward-flow.

Usually after a phrase like that the agent would have rushed straight into editing the file. But because of defaultMode: plan, the session started in plan mode — so instead of a fix, the terminal first displays the intent:

Plan:
1. Read src/reward-flow.js and src/rules.md — understand the accrual formula.
2. Find where the points are calculated incorrectly.
3. Fix the formula according to rules.md.
4. Run the existing accrual tests.

Proceed with the changes?

Tommy didn’t even press a button to "turn on the plan" — the window stopped itself before the first edit. There it is, defaultMode: plan baked in and working: not "the agent decided to stop on its own," but the setting forced it to show the intent first and ask.

3. You edit the plan, not just nod along

Tommy reads the intent — and doesn’t rubber-stamp it. The old rule still holds: the plan is not for nodding along, but for fixing. And he sees what the plan is missing: the agent was just going to "run the existing tests", but after yesterday Tommy knows the price of blind tests. He adds the boundaries:

Plan is fine, but add a test that truly verifies it (fails on the broken one) and do not touch /legacy.

— That’s what an owner looks like, not a passenger, — Alex notes. — You’re not "agreeing, agreeing" — you’re setting boundaries. A test for a true check — so you can prove it later. /legacy not to be touched — so you don’t blow up neighboring stuff. The agent adjusts the intent to your constraints even before the first edit. It’s cheaper to argue with a plan on paper than to sort out what was done.

Tommy catches himself doing it on autopilot. He doesn’t remember "ah, I need to adjust the plan" — he just reads it and immediately sees where the intent is flimsy. Reflex.

4. Clean window before a new task

Tommy closes the core fix calmly. And then, before even thinking about the live add-on, he himself — already without Alex — commands a clear:

/clear          # core fix is closed; clear the window before the add-on

— And what did you just do, I didn’t even get a chance to say, — Alex writes.

— So obvious, really, — Tommy replies. — I finished the fix, and after an hour of fiddling the agent’s window is packed to the brim. If I start bolting the add-on onto this junk now, it will start dragging the old stuff along and getting confused again. I clear to a clean slate — and enter the add-on with a fresh head.

— You wouldn’t have remembered that before, — Alex writes.

— I wasn’t remembering now either. My hand did it on its own. — Tommy shrugs. Clearing to a clean slate has settled next to the plan as one habit: any non-trivial job — first plan, keep the window clean as you go, don’t pile on extra stuff. Not a procedure you force yourself through, but simply a way not to drown yourself or sink the agent in noise.

5. Task framing has become a habit

"No spec, the result is anyone’s guess" — that’s where it all began. Back then somebody else formulated the task for Tommy, and he wanted to "do it fast, spec later." Then an incident taught him the hard way: without a spec and a plan the agent will let you down, and you’ll be the one to blame.

And now he writes the task framing and starts with the plan because he can and wants to, not because he got burned. No one is standing over his shoulder. That’s the difference between who he was and who he became.

— You know what’s funny, — Tommy writes to Alex. — I used to be "give it to me fast, spec later." And now "first I define the task and the plan" is just my normal way of working. I don’t even think of it as a rule. It just happens.

— That’s how the loop closes, — Alex replies. — Task framing stopped being an outside demand and became your reflex. The spec is written by the pro — not because he was forced to, but because it doesn’t work any other way anymore.