Spec-first is anxiety management

You’re in unknown territory. Your instinct says: “We need a detailed spec because this is unfamiliar.”

You’ve got it exactly backwards.
You’re reaching for a concrete mixer when all you have is mud.

I see this pattern everywhere in AI-assisted development:
Team enters unfamiliar domain
→ Anxiety spikes
→ “Let’s generate a comprehensive spec!”
→ Burn thousands of tokens
→ Build elaborate documentation
→ Discover it was completely wrong
→ Start over

The spec wasn’t risk reduction. It was anxiety management, and false confidence.

Here’s what you actually have in unknown territory:

• Mud state: unclear constraints, uncertain user needs, unknown technical feasibility
• What you need: mudbricks (small tests, quick learning, rapid iteration)
• What spec-first gives you: a concrete mixer (expensive, permanent, requires certainty)

The mudbrick approach

1. Build the smallest thing that tests your riskiest assumption
2. Does this API even work? Can users articulate this need? Is this constraint real?
3. Document what you learned, not what you guessed
4. Use that learning to inform the next small build

The concrete mixer / spec-driven approach

• Generate ungodly amounts of detailed requirements
• Build based on assumptions
• Discover assumptions were wrong
  Now you have expensive documentation of your mistake

Why this matters in AI

When you prompt an AI to “generate a comprehensive spec” for something you don’t understand yet, you’re not getting clarity. You’re getting confident-sounding hallucination.

The AI doesn’t know your domain either. It’s just very good at producing text that looks like expertise.

Token economics make this brutal:

• Generating elaborate spec: 5,000+ tokens
• Implementing the actual feature: 200 tokens
  You just spent 25x more tokens documenting assumptions than building reality.

The real question: In unknown territory, what should you optimize for?

Wrong answer:
Comprehensive documentation that makes you feel certain

Right answer:

• Cheap context re-entry (because your mental model is changing fast)
• Low-friction iteration (because most attempts will be wrong)
• Preserved reasoning (so you remember why you tried X when you pivot to Y)

The architect’s move

When Louis Kahn didn’t understand a material, he didn’t draft elaborate plans. He built small studies. He tested forms. He asked the material what it could do.

Then, and only then, did he design the building.

You can’t ask a brick what it wants to be through a spec. You have to build something and see what happens.

Next: Why the builder vs. architect distinction explains everything wrong with current AI workflows.