Four Hats Before the First Line of Code
Claude Code will now produce a plan good enough to argue with. The practice that changed my results was reviewing that plan from several roles before letting anything be built.
My working pattern with Claude Code has changed over the past few months, and the change is not that it writes better code. It does, but that is not the interesting part.
The change is that I no longer describe implementation. I describe an outcome, and what comes back is a plan detailed enough to disagree with.
That sounds like a small difference. In practice it moves the entire center of gravity of the work.
Describe the expectation, not the steps
I used to write instructions: build this component, change that function, structure the module this way. That was a reasonable way to work with a tool that needed direction at every step, and it meant my thinking arrived pre-flattened into tasks.
Now I describe what I expect to be true when the work is done (the behavior, the constraints, what must not break) and let the plan come back to me. The plans are good. Not always right, but coherent, complete enough to evaluate, and specific enough that when I disagree, I am disagreeing with something real.
The value of that is easy to miss. A plan is an artifact you can hold in your head all at once. A ten-thousand-line diff is not. Moving the decision point earlier is what makes the rest of the work reviewable at all. It is the same shift I found when rewriting a system I had been avoiding, and it has held up as a general practice rather than a one-off.
The four hats
The step that changed my results most is what happens after the plan exists and before anything is built.
I ask for the plan to be reviewed again from a different role, one at a time.
As a CTO. Does this hold up operationally? What breaks under load, what does it cost to run, what does it commit us to, and what will be expensive to reverse in a year?
As a product lead. Does this actually serve the outcome? Is anything in here scope that nobody asked for? Is anything missing that a user would immediately expect?
As a creative. Is there a fundamentally simpler shape for this? Not a smaller version of the same plan, but a different approach that makes half the plan unnecessary.
As an engineer. Where is this plan vague in a way that will be resolved badly during implementation? Which steps are hiding a decision?
Two questions do most of the work: what are we missing, and could this be substantially simpler. The second one has changed more plans than the first. Left alone, plans tend to grow: every consideration adds a step, and nothing removes one. Explicitly asking for the simpler shape is the only reliable counterweight I have found.
Only when those passes stop producing changes do I ask for implementation to start. And that part now works well enough that the plan review is where the effort belongs.
Why the hats work at all
It is worth being precise about the mechanism, because the obvious explanation is wrong.
These are not four independent opinions. It is one model prompted four ways. There is no committee, and no genuine diversity of judgment.
What the roles actually do is change what gets attended to. A general request to review a plan produces general observations. A request to review it as someone accountable for operating the system for two years produces a different set of observations, because it changes which properties of the plan are salient. The technique works for the same reason a checklist works, not by adding intelligence but by directing attention to categories you would otherwise skim.
That distinction matters for the obvious reason: shared blind spots stay shared. If the plan and every reviewer have the same misunderstanding of the domain, four hats will confirm it four times, with increasing confidence. Agreement across roles is not evidence of correctness. It only means no role found an objection in the category it was looking at.
Which is why the last review is still mine, and why it is the one I do slowest.
What this changes about the work
The obvious reading is that this makes development faster. It does, but that undersells it.
What it really changes is which decisions get made deliberately. In a normal implementation, dozens of small choices are settled silently at the keyboard: this belongs here, that gets its own module, this case can be handled later. Those choices accumulate into the architecture whether or not anyone decided them.
Working this way, most of those choices surface in a document while they are still cheap to change, and get examined from several angles before anything depends on them. That is the part I would not give up. The speed is a side effect.
I have also noticed it changes how carefully I specify things, because vague expectations now produce a visibly vague plan rather than plausible code that quietly guessed. That feedback arrives in seconds instead of at review, and it has made me better at stating what I actually want.