Conceptual Integrity

The Revival

Something good is happening. As AI takes over more of the actual typing, engineers are shifting their attention up the stack. Two things are rising at once: a revolution of intentions (more on that in a future post) and a revival of interest in system design.

The revival makes sense. When code gets cheap, design gets valuable. If an agent can produce a working service in an afternoon, the differentiating skill is no longer producing the service. It is knowing what to build, how the pieces should relate, and why. So everyone is sharpening their "system design" skills, and I am genuinely glad they are.

But let's not confuse what system design is.

The Mirage

Here is what gets labeled system design today: load balancers, message queues, cache invalidation, database sharding, consistent hashing, five nines of availability. Master that material and, by the current curriculum, you have learned system design.

That material is software architecture, infrastructure engineering, and high availability. All three are real disciplines. All three are worth learning deeply, and I mean that without a hint of irony. If you are early in your career and grinding through multi-AZ layouts and region balancing, keep going. You are building muscles you will use for decades.

Just know what the label on the box should say. The software and infrastructure are components of a system design. They are not the thing itself. Calling them system design is a mirage: it looks complete zoomed in, and when you step back to the big picture, more is missing, or worse: overlapping.

Systems Include People

A system is not the set of services in your diagram. A system is the services plus the people entangled with them, and the influence runs in both directions. Users shape the system as much as it shapes them; their habits and workarounds become tomorrow's requirements. The engineers who build the product leave their fingerprints on every corner of it, and it leaves a few on them. The product manager negotiates what it becomes next. The data scientist lives downstream of whatever it decides to log. The team's structure seeps into the architecture, and the architecture seeps back into the team. Operators configure it in ways nobody anticipated, and the organization funding it will someday ask why it costs so much.

You have not designed a system until you have designed for those people. The database platform selection is the easy part. The hard parts are questions like: who owns this boundary? What will a new engineer assume this does, and will they be right? What behavior does this incentivize in the team next door? How does it evaluate its success and self-improve?

And then there is the part almost nobody diagrams: change management. A system spends most of its life mid-change. Migrations, deprecations, version upgrades, the slow negotiation of getting people to actually adopt the new thing and let go of the old one. How a change is proposed, approved, rolled out, and absorbed by the people who operate and use the system is not overhead around the design. It is part of the design, and it is where a lot of technically sound systems go to die.

If your design process has no answers for people, you are doing architecture. Which is fine. Just don't call it system design.

The Design of Design

Fred Brooks made this argument better than I ever will. You may know him from The Mythical Man-Month, but the book I keep coming back to is The Design of Design (2010), a collection of essays on the process of design itself. Brooks draws from computer architecture, software, and even designing his own beach house to make a point I agree with: design is a cross-discipline skill.

His central claim: conceptual integrity is the most important consideration in system design. A system has conceptual integrity when it reflects one coherent set of ideas, when a user who understands part of it can correctly predict the rest. Complex systems are designed and built by many hands, and Brooks knew that as well as anyone, being a designer of IBM OS/360. His argument is about where coherence comes from: a chief designer, or a small group so aligned it speaks with one voice, with the standing to say no to features that are individually good but collectively incoherent. A committee voting on good ideas produces a pile of good ideas. A team resonating around one concept produces a system design.

That is a claim about people. The chief designer, the negotiation with stakeholders, the discipline to reject good ideas: none of it appears in a boxes-and-arrows diagram. Brooks understood that designing the system and designing the human context that produces and operates the system are the same activity.

Welcome to the Party

If you have been working more than fifteen years, you designed systems where the hardware had to be provisioned, purchased, shipped, racked, and installed before anyone configured anything. Capacity planning meant a purchase order and a lead time measured in weeks or months. You got one shot at sizing the thing, and it still had to scale, because "just add more servers" was a capital expense.

Under those constraints you could not pretend the system was only software. The system was budgets, vendors, facilities, the ops team, the upgrade window negotiated with the business, and the intern who was going to trip over the cable. People and process were in the design because they physically had to be.

Cloud computing is great. I would not go back. But it made infrastructure so easy to summon that a generation learned to design as if the system were only the software, and the current "system design" curriculum reflects that. So to everyone rediscovering these skills: sincerely, welcome to the party. It's a good party. It has just been running longer than the cloud has.

Why This Matters Now

Here is the AI-era punchline. Agents can now generate architectures, infrastructure-as-code, and plausible design docs faster than you can read them. Every one of those artifacts is locally reasonable. None of them carries intent.

Conceptual integrity is exactly the property that does not emerge from sampling good ideas, which means it is exactly the property an agent swarm will not stumble into.

Brooks was designing for the party we are all just now arriving at, and it is why those systems are still around some sixty years later.