Brick for Stone: The Limits of Specifying Everything Up Front

There is a useful distinction between stone and brick. Stone is what you find. It is particular, irregular, and given, and you shape what you are building around what it is. Brick is what you manufacture. It is uniform, made to a single specification, and you shape it to fit your plan rather than letting it shape your plan. Both have their place. The trouble comes when you forget which one you are working with. We have been thinking about that while using spec-driven development on a real project.

Spec-driven development works, and that is where the trouble starts

Let us concede the real thing up front. Spec-driven development works. Sharp engineers pair it with generated test suites and one-shot whole features. Using it ourselves, we have surfaced decisions up front that we would otherwise have found in the middle or at the end. It is also extremely verbose. To ship one feature, you walk through ten deliberate steps that our usual assisted workflow would collapse into a tight loop of do, validate, correct. Sometimes that is worth it. And then, almost on cue, you take the careful plan into the first implementation step, immediately discover you missed something, and the spec has to be reworked. That is fine. That is the seam worth talking about.

The synoptic conceit

Years ago, before spec-driven development was a phrase, we integrated a client system with SAP during a HANA migration run by a large consulting group. There was a tremendous amount of paper before anything got built, and the people writing the specifications did not fully understand the technology. They named the entities up front and modeled the whole shape of the thing. Then we started building, and reality talked back. The spec described one entity as two separate things, so we designed two APIs. In the build we realized they were one transactional relationship, and managing them separately would have produced stale data almost immediately. When everyone has invested months in a specification, every change is laborious, and once change is laborious it suddenly matters whose fault it is. The people were smart. The process was organized. It still failed.

Knowledge is dispersed by design

The knowledge you need to build a system for people is dispersed across those people. It has to be, because that dispersal is the same specialization that makes us productive. You cannot gather all of it into one head, or into one document. People keep telling us the answer is to interview everyone first and then write the spec, but much of what people know is implicit in their process. They cannot fully articulate it without doing it.

We once worked with someone who was slower on our new data entry form than the old one. We sat and watched her work, and she was pulling every value out of another system and retyping it by hand. She never thought to mention it, because nobody had asked her to describe her job from the outside. She was describing the form, because we were asking about the form. So we deleted the form and built an integration between the two systems instead. 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 spec-driven development is that capable AI agents finally make comprehensive specs viable, because the agent will fill in the gaps plausibly. That is the part that makes us uneasy. It is the monkey's paw problem. You make a wish, it gets perverted because it could not anticipate everything, so you make a more sophisticated wish to close the gaps, and the gaps just get bigger. There is always another gap.

A capable agent removes the friction that used to expose this. The old failure mode of an under-specified system was that it visibly broke, and you saw it. Now the agent satisfies the spec plausibly, producing something that looks right and runs. The blind spots are still there, just hidden behind work that compiles. And here is the part nobody wants to hear: someone, at some level, has to review the output. Push the review up to the specs, and someone still has to review the specs. If the specs are generated, someone has to review the thing generating them. The review does not go away. It moves.

Why firms survive by refusing the master plan

Real organizations do not run on one master plan that coordinates everything, even the ones that produce org charts and strategy decks. They survive because their internal planning is heterogeneous and adaptive. Different teams know different things, decisions get pushed close to where the knowledge lives, and the plan is a sketch that gets redrawn constantly. The sin of spec-driven development is not specification. The sin is importing 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.

So the shape we want for specification is bounded, humble, and plural. Specs that live close to the work, that know what they do not know, and that expect to be revised when reality talks back. Use brick where uniformity actually serves the work. Stay close to stone where the material has something to teach you. The error is never specification. The error is totalization, the belief that you can write the one plan that handles every edge case. Do not mistake the brick for the building.