build-dialectical

name

build-dialectical

description

Use when the user doesn't trust their first shape — the design instinct feels default-driven rather than earned, requirements are contested, a project keeps oscillating between two philosophies without committing, or a rewrite debate ("simpler or more powerful?") has stalled in the abstract. Also use whenever the user invokes "dialectical", "build the opposite", "thesis/antithesis", "maximalist vs minimalist", or "steelman both".

Dialectical Build

You don't trust your first shape — good. This method earns a shape by building two committed extremes and letting them collide. The synthesis is not a compromise, not a midpoint, not "a bit of both": it's whatever survives contact between two positions that were each pushed as far as they honestly go. A dialectic where one side is a strawman produces the answer you started with, wearing a costume. The whole value lives in the discipline of building the side you disagree with as if you believed it.

Choosing the axis

The axis is the single dimension along which the two builds oppose. Pick it before building anything; write it as one line in DIALECTIC.md. Good axes are philosophical commitments, not feature lists:

• Maximalist vs brutalist — full-power configurable engine vs the crudest thing that works
• Eager vs lazy — compute everything up front vs compute nothing until demanded
• Framework vs library — it calls you vs you call it
• Rich domain model vs anemic data + functions
• One process vs distributed from day one

One axis only. Two builds differing along three axes teach you nothing attributable. If two axes both feel live, run two dialectics in sequence — the second is cheap once the first synthesis exists.

Workspace layout

project/
├── DIALECTIC.md         # axis, briefs, collision findings, synthesis rationale
├── thesis/              # extreme A
├── antithesis/          # extreme B
└── synthesis/           # created only at SYNTHESIZE

Phases

1. POSITION

In DIALECTIC.md, write a brief for each extreme — one paragraph each, in the voice of a believer. The brief states the position's bet ("complexity spent now buys velocity later" / "every abstraction is a loan against understanding") and what winning looks like on its own terms. If you cannot write the antithesis brief without irony, you haven't understood the position yet — keep going until both briefs read as sincere.

Also write the shared spec: the behavior both builds must exhibit, kept minimal, so collision compares philosophies rather than feature sets.

2. BUILD BOTH

Build each extreme to demonstrable, honoring its brief totally:

• No hedging. The brutalist build gets zero speculative abstraction even where you're sure one will be needed. The maximalist build takes its abstractions all the way even where they feel heavy. Hedged extremes converge toward the middle and the collision produces nothing.
• Build them in sequence or isolated sessions, and switch voices fully. While in antithesis/, its brief is true. (In multi-session Claude Code: one session per side, each session's prompt containing only its own brief.)
• Same effort budget per side. An under-funded side loses the collision by starvation, not by merit.
• Log each build's completion with one line on where honoring the brief hurt — those pain points are collision fuel.

3. COLLIDE

The collision is a structured confrontation, recorded in DIALECTIC.md. Run the same set of trials against both builds:

1. Extension trial: implement the same small new feature in both. Record what each build made easy, hard, ugly.
2. Stress trial: push a realistic load/scale/edge case at both. Record where each bent.
3. Reading trial: explain each build's core path aloud (in writing). Record where explanation required apology.
4. Deletion trial: what could each build remove and still meet the spec? A build that can shed little is either perfectly lean or rigid — determine which.

Then write the findings table: for each trial, which position's bet paid, and why. The unit of finding is a sentence like: "Eagerness paid on read-heavy paths (trial 2) but its warm-up cost dominates at small N (trial 2a) — the bet is scale-conditional." Findings must attribute outcomes to the axis, not to incidental implementation choices; where an outcome is incidental, mark it so.

4. SYNTHESIZE

Now — only now — decide the shape. Three legitimate outcomes:

• Conditional synthesis (most common): each position wins in a region; the synthesis draws the boundary. "Brutalist core, maximalist at the two extension points where trials showed churn." The boundary is the design — state it as a rule future changes can be tested against.
• Clean victory: one extreme simply won across trials. Adopt it — but harvest the loser's trial wins as guardrails ("we go maximalist, but trial 3 showed the config surface must stay under N knobs").
• Axis rejection: the collision reveals the axis was the wrong question and a third shape dissolves it. Rare, valuable; write down what the real axis was.

Build synthesis/ fresh, reusing code from either side freely. In DIALECTIC.md, record the synthesis rationale: which findings drove which choices. Then consolidate to real quality. Keep both extreme builds until synthesis passes the same four trials — they are your regression baseline for the philosophy, not just the code.

Failure modes

• Strawman antithesis: building the opposing side to lose. Detected at POSITION (ironic brief) and at COLLIDE (one side wins every trial suspiciously cleanly — audit whether it was honestly built).
• Premature synthesis: deciding the shape during BUILD because one side "obviously" feels right. The feeling is the prior you distrusted; finish the trials.
• Split-the-difference: a synthesis that averages the extremes instead of drawing a reasoned boundary. If the synthesis rationale doesn't cite specific findings, it's a compromise, not a synthesis.
• Axis sprawl: extremes that differ in many ways. Findings become unattributable.

Claude Code mechanics & siblings

• Voice-switching is by construction: dispatch one blind subagent per side, each prompt containing ONLY the shared spec and its own brief — the thesis builder never sees the antithesis brief, and neither sees which side the user favors. Worktree isolation when the builds would touch overlapping files. "Switch voices fully in sequence" is the single-context fallback, not the default.
• State files: if the project routes working files to a directory (e.g. .ai/), put DIALECTIC.md there (.ai/build/); thesis/, antithesis/, synthesis/ live wherever the project keeps code.
• Routing: shaping and planning stay upstream (intent-shape, mega-brainstorm, mega-plan); the dialectic replaces the execution strategy for the component it governs. Siblings — tournament when the disagreement is measurable; subtractive when more than two shapes deserve a look; annealing for ridged spaces worked across many sessions.

When NOT to use this

When you do trust the shape (build it). When the disagreement is measurable (run a tournament — dialectics settle questions of philosophy, tournaments settle questions of fact). When more than ~2x build cost is unaffordable.