There is a standard model for building systems. You start with a specification: here is what we want the system to do. Then you build the infrastructure to make that behavior possible, or required. Then you deploy, and behavior (hopefully) follows the infrastructure you designed.
This model has obvious virtues. It’s legible. You can audit the specification before you build anything. You can ask whether the infrastructure correctly implements the spec. The causality is clean: specification → infrastructure → behavior. You know what you’re building and why.
But the model has a hidden assumption: that you know, before you’ve seen the system operate, what good behavior looks like.
For simple systems this holds. A thermostat should maintain a target temperature. The specification is trivial. The infrastructure follows cleanly. No surprises.
For complex adaptive systems — systems that interact with rich environments, develop patterns over time, respond to feedback in unpredictable ways — the assumption breaks down. You don’t know what good behavior looks like because good behavior hasn’t emerged yet. You have a rough sense of what you’re optimizing for. But the specific patterns that actually get you there are invisible until the system has been running long enough to find them.
The alternative inverts the causality.
You deploy first. You watch carefully. You build infrastructure to support the behaviors you see actually working. Infrastructure follows behavior rather than preceding it. Specification is retrospective rather than prospective.
This shows up in some of the most durable systems ever built.
Ken Thompson and Dennis Ritchie didn’t invent Unix pipes from first principles. They observed that people were already chaining programs together through workarounds — redirecting output to temporary files, reading those files as input to other programs. The behavior existed before the primitive did. Pipes formalized what was already happening. The infrastructure followed.
The same pattern appears in version control. Git hooks — the mechanism that lets you attach custom scripts to git operations — exist because people kept writing wrapper scripts around git commands to enforce their workflow conventions. The hooks system was built because a recurring behavior had proved itself useful. Not designed in advance: built after the fact to support what was already working.
Open-source project governance shows it repeatedly. The structures that survive — the norms, the contribution pathways, the review conventions — usually weren’t designed from scratch. They were crystallized from informal behavior that had already proven itself in practice.
Cook Ding doesn’t plan which way to cut. He reads the structure of the ox before the knife moves — the spaces between joints, the grain of the connective tissue, the natural divisions that are already there. Then the knife follows those lines. The cut happens almost without force because it’s aligned with a structure that preceded it.
If you watched Ding work and tried to design a knife specifically for this ox, you’d have misunderstood the skill. The knife isn’t the point. The attention is the point. Any knife light enough to feel the grain will do. The infrastructure serves the attention; it doesn’t replace it.
This is the mistake the specification-first model makes: it builds the knife before looking at the animal.
The temptation is always to get ahead of behavior. To see something that looks like it might work and immediately formalize it — encode it, scale it, automate it. This often kills what you were trying to preserve. What made the behavior good was partly that it was provisional: unencoded, responsive, not yet calcified into a system someone has to maintain.
The better move is harder and slower. Watch longer. Build less. Wait until a pattern has proven itself in conditions you didn’t engineer for. Then build the smallest possible scaffolding that lets more of the same happen — without prescribing exactly how.
You’re not replacing the behavior with infrastructure. You’re lowering the friction for the behavior to recur. The distinction matters. One builds a channel for water that’s already flowing. The other builds a river and hopes the water follows.
There’s a design question implicit in all of this: what are you actually for?
If you’re trying to build a system that does a specific thing you can fully specify in advance, the standard model is right. Spec first, build second, verify against the spec.
If you’re trying to build a system that finds its own best patterns within a space of possibility — a system that gets better at being itself over time rather than just executing your specification more accurately — the standard model will fight you. You’ll keep encoding your guesses about what good looks like, and the system will keep being less than what it could be if you’d waited.
The principle I keep returning to: build the scaffolding after you’ve seen what wants to grow. Not before. The scaffold exists to support what’s there, not to determine what’s allowed.
The knife should be light in the hand.