Settle design arguments with three PRs, not a whiteboard

Two engineers disagree about how a change should be structured. One wants an event bus, the other wants direct calls, and a third thinks both are premature. The default move is a doc: someone writes up the options, people comment for a week, and the decision gets made on prose about code that does not exist yet.

Build all three instead. Then read the diffs.

The mechanic

Give each candidate its own worktree so the branches never touch each other's files:

claude --worktree proto-event-bus
claude --worktree proto-direct-calls
claude --worktree proto-inline

Each session gets the same spec and a different constraint:

Implement notification fan-out for order state changes, using an internal
event bus. Keep the change inside src/notifications/ and its tests. Do not
refactor callers beyond what the approach requires. Open a PR when the
existing test suite passes.

Then stop reading the arguments and read the shape:

git diff --stat main...worktree-proto-event-bus
git diff --stat main...worktree-proto-direct-calls
git diff --stat main...worktree-proto-inline

The interesting number is usually not lines added. It is how many files outside the feature directory each option had to touch, and how many test files it broke.

What actually changes

The last row cuts both ways. A rejected PR is a much better record of why than a paragraph in a doc — but only if you write down the reason before deleting the branch.

The bottleneck moves, it does not disappear

Producing three implementations does not make the decision free — it converts a writing problem into a reading problem. If your team cannot review three prototypes faster than it can argue for a week, you have not saved anything. Budget the review the way you would budget the doc:

• Cap it. Two or three candidates, one feature directory, one shared test suite. Not /batch-scale fan-out.
• Give every prototype the same acceptance criterion, so "it passes" means the same thing in each branch.
• Timebox the prototypes so a candidate that is not working in an hour loses on that basis.
• Have Claude summarize the three diffs against each other before humans open any of them, in one session that can read all three worktrees.

What the docs do and don't back

Every mechanism here is documented. Worktrees isolate parallel sessions so the edits never collide. A forked subagent exists specifically for when you "want to try several approaches in parallel from the same starting point." Checkpointing lists "exploring alternatives" as a use case. /batch already spawns worktree-isolated subagents that each open a pull request. Artifacts even offer to "lay out several design or implementation options side by side."

What the docs never say is that you should use any of this to resolve a disagreement between people. That step is a team norm, not a product feature, and nothing in the documentation claims prototypes should displace design docs.

What is unverified

The claim comes from a talk by an Anthropic engineering lead describing how one team — the Claude Code team — works. It is a report of a norm, not a measured result. Nobody has shown that teams which prototype decide better, or faster, or that the reviewers stay willing to read three PRs after the tenth time you do this. The transcript backing it is a community machine transcription, so treat the exact wording as approximate even where the substance holds.

What would settle it, on your own team: pick the next three design arguments, run one as a doc and two as competing branches, and record the wall-clock time from "we disagree" to "we merged something" plus whether the decision got reopened within a month. That is a measurement your team can make and the docs cannot.