Brick for Stone

Genesis 11:3 has a detail that's easy to skim past. The builders at Babel "had brick for stone, and bitumen for mortar." Brick instead of stone. The whole story turns on that substitution.

Stone is what you find. It's particular, irregular, given. You pick it up and you shape what you're building around what it is. Brick is what you manufacture. It's uniform, interchangeable, made to a single specification, and you shape it to fit your plan rather than letting it shape the plan. The builders at Babel decided they were done with stone. They had a tower to build, and stone wouldn't cooperate fast enough.

I've been thinking about this story while building a marketing site for my company using spec-driven development.

SDD Is Genuinely Useful, and That's Where the Trouble Starts

Let me concede the real thing up front. Spec-driven development works. I have a friend who's a sharp developer, recently promoted into an architecture role at another company, and he has gone full-throated on this. He pairs SDD with BDD test suites he's built himself, generates the tests from the spec, and one-shots whole features. I can't argue with him on the terms he's describing. On those terms he's right.

I have a mid-level developer on my team who's been using SDD inside his coding environment and loving it. He's already growing into a senior-level engineer faster than most people I've watched grow, and the tooling is helping.

And I'm using spec kit myself right now, for the first time, on this marketing site. It's been useful. I am figuring out things up front that I would otherwise have found in the middle or on the back end. It's also extremely verbose. To get one feature out the door I'm walking through ten steps that, in my usual AI-assisted workflow, I would have collapsed into a tight loop: do something, validate, correct, do something, validate, correct. The SDD version asks me to think through every detail before I write code. Sometimes that's worth it.

And then, exactly as I'd suspected, I take the careful plan into the first implementation step and immediately discover we missed something, and the spec has to be reworked. Which is fine. That's how it should work.

But that's also the seam I want to talk about.

The Synoptic Conceit

The first time I watched this style of problem-solving really go sideways was years ago, before "spec-driven development" was a phrase anyone used. I was integrating a client system with SAP during a migration to HANA. The integration was being run by Accenture. As you might expect with a huge consulting group, there was a tremendous amount of paper before anything was actually created.

The problem was that the people writing the specifications didn't really understand the technology. They named all the entities up front, defined how they'd flow across the integration, modeled the whole shape of the thing. Then we started building, and reality talked back.

There was one entity in particular. We had designed two separate APIs because the spec described two separate things. When we started building, we realized they weren't two things. They were one transactional relationship, and managing them separately would create stale data and mismatches almost immediately. The whole approach had to be reworked, on their side too. The conversation when we figured this out was tense in a way agile teams don't usually have to deal with. When everyone has invested months in a specification, every change is laborious, and once changes are laborious it suddenly matters whose fault the change is. On an iterative team the question is usually "who's going to solve this." On a heavily specified project the question shifts to "whose fault is it that we're in this position." Not always. But often enough to notice.

People were smart. The process was organized. It still failed.

Knowledge Is Dispersed by Design

Here's the part where I sound a little like Hayek, though I came to it through the work rather than through the books.

The knowledge you need to build a system for people is dispersed across those people. It has to be. It's the same thing that makes us productive in the first place: specialization. Different people have different expertise, different skills, different aptitudes, different judgment built up through years of doing the specific thing they do. You can't gather all of that into one head, and you can't gather it into one document either.

People keep telling me the answer is just to interview everybody first and then write the spec. The problem is that a lot of what people know is implicit in their process. They can't fully articulate it without doing it. Sometimes it takes someone outside the work, watching them do the work, asking questions, to tease out the judgment calls that are happening so fast and so habitually that the person making them doesn't register them as decisions anymore.

There was a user we worked with once on a data entry workflow. She was fast on the old form, slower on our first version of the new form, and we were trying to figure out how to make our form faster. We sat with her. We watched her work. And we noticed she was pulling every value out of another system and typing it into ours, verbatim. She had never thought to mention that, because nobody had asked her to describe her job from the outside. She was describing the form, because we were asking about the form.

We deleted the form. We built an integration between the two systems instead. She loved it.

The point isn't that we had a bad spec. With enough up-front rigor we could have written a great spec for that form. We would have built the wrong thing very efficiently.

A Capable Agent Makes the Overreach Easier

The current excitement around SDD is that capable AI agents finally make comprehensive specs viable, because the agent will fill in the gaps plausibly. This is the part that makes me uneasy.

It reminds me of the monkey's paw. You make a wish, and the wish is perverted because the wish couldn't possibly anticipate everything, so you make a more sophisticated wish to close the gaps, and the gaps just get bigger. There's always another gap, because the gaps are infinite. That's what gaps are.

A capable agent removes the friction that used to expose this. The old failure mode of an under-specified system was that it would visibly break. You'd see it. Now the agent satisfies the spec plausibly. It produces something that looks right and runs. The blind spots are still there. They're just hidden behind work that compiles.

And here's the thing nobody wants to hear. Someone, at some level, has to review the output. If you push the review up a level and say "we'll just review the specs," fine. Someone has to review the specs. And if the specs are being generated, someone has to review the thing generating them. The review doesn't go away. It moves.

The Firm Survives by Refusing the Synoptic View

Here's the thing I keep circling. The firm I work for doesn't have one master plan that coordinates everything. Real organizations don't, even the ones that produce org charts and strategic documents. They survive because their internal planning is heterogeneous and adaptive. Different teams know different things. Decisions are pushed close to where the knowledge lives. The plan is a sketch, and the sketch gets redrawn constantly.

SDD's sin isn't specification. Specs are good. Being systematic is good. The sin is importing the synoptic conceit, the belief that we can write the all-encompassing plan, into the one place inside the firm that has always lived by refusing it: the working software, where reality has the most direct vote.

You can see the same pattern at larger scales. Whole national systems have exhausted themselves trying to plan for a world that had already moved by the time the plan was approved. I won't belabor that. The diagnosis is the same one.

Babel, and the Tower That Won't Flood

Back to Genesis 11.

The first time I really noticed the bitumen detail I was in my second year at SEQTEK, doing a "read the Bible in a year" plan with some coworkers on a Slack clone called Ryver. We'd post in a channel each day about what we'd read. When I got to Babel I looked up bitumen because I didn't know what it was, and I realized it was waterproof. That mattered, because Babel comes right after the flood. So the builders aren't only reaching for the heavens. They're also waterproofing. They are building a tower that can withstand the next flood. They are building the all-encompassing structure that no future event can disrupt.

That's the move. A technique, a process, a framework, a specification that handles every edge case. If we just follow the pattern, we'll always come to the right answer. We will not be scattered, we will not be flooded, we will not be surprised. We will make a name for ourselves.

And what happens? Their language is confused. The single uniform tongue, the one specification, fractures into many. The unity of purpose disintegrates into the inability to communicate toward the goal. The very thing they were building to prevent, scattering, is what they get. Not as punishment exactly. More like the restoration of the dispersal that human knowledge actually depends on.

The brick was the giveaway. They had already substituted the uniform manufactured unit for the particular found one. They had already decided that the world wouldn't get a vote in the shape of the tower. The confusion of tongues just made visible what was already true about the project: the knowledge required to build it that way doesn't gather in one place. It's dispersed by design.

Pentecost as the Proper Place

The answering move in the Christian story is Pentecost. The disciples are gathered, the Spirit comes, and they speak, and people from every nation hear them in their own language. Not one language. Many. Made comprehensible to one another without being collapsed into one.

Pentecost is not a tower. It's reception. The disciples aren't building anything upward. They're receiving something that comes down, the gift of flesh raised and ascended, and in receiving it they find that the many tongues can communicate without being unified into one tongue. The unity is in what is received, not in what is constructed. The plurality is preserved.

That's the shape I want for specification. Bounded, humble, plural. Specs that live close to the work, that know what they don't know, that expect to be revised when reality talks back, that don't pretend to gather all the dispersed knowledge into one frozen plan. Specs that look like Pentecost. Many tongues, mutually intelligible, no tower.

The all-encompassing system, the one spec that handles every edge case, the framework that promises to make every future change cheap if you'll just plan hard enough up front, is the other shape. That one looks like Babel. It can't deliver what it promises, because the friction that used to make the gap visible is precisely what a capable agent now smooths over.

Where That Leaves Me, Building This Site

I'm still building the marketing site with spec kit. I haven't finished. My impression of SDD here is real but partial. I'm writing about it in the middle of using it, not from the other side.

What I notice is that some of the things I'm thinking through up front aren't problems that actually need solving, and some of the problems that need solving aren't being surfaced by the up-front thinking. The shape of what I'm doing isn't quite "receiving" versus "building toward." It's more like receiving the path upward rather than trying to manufacture the path upward. Letting the next step show itself when I'm in a position to see it, instead of pretending I can see all of them now.

Specs are good. Being systematic is good. Brick has a place, especially when you're building something where uniformity actually serves the work. The error isn't specification. The error is totalization, the belief that we can write the one spec that reaches the heavens and the one mortar that holds against every flood.

Stay close to stone where you can. Use brick where it serves. Don't mistake the brick for the building.